Under certain circumstances there is
a vulnerability, when a web server creates responses in JSON format or as JavaScript, which
is quite usual in AJAX applications.
Scenario:
There is a web application, which uses
XMLHttpRequest aka AJAX to get confidential data. The response is generated
in JSON format or pure JavaScript. The application is usable after a user
authentication only (or at least the data returned depends on user credentials).
Furthermore there is a malicious web
site on a different server, whos creator wants to spy out some secret data.
Therefore the page contains a <script>
tag with a src arttribute pointing to a URL to the above web application,
returning data as JSON or JavaScript. Different from XMLHttpRequest, which
can only point to the same origin, <script>
tags allow to get JavaScript from any server.
At the top of the same page there is
a extension of the JavaScript Object oder Array object, which is called,
whenever a new Object or Array is created.
Thus by executing the mentioned <script>
tag, for each new object or array the extension is called and has access
to the confidential data, which it can send (using another AJAX call) to
the malicious web server.
But there are a lot of preconditions
to be met:
- There is a web application, which returns confidential data in JSON format or as JavaScript.
- The returned data is directly executable JavaScript. In case of JSON this is only true for JavaScript arrays, not objects.
- A GET request must be possible, since
<script>tags always create GET requests. - The user must call the malicious web page.
- There must be an open session or the user has to log in (we all know, some users will do this).
- The attacker must know the URL to call. This is the case for public services (like GMail), for applications, which always exists on certain web servers (like names.nsf), for known, commonly installed applications (like some widespread CRM products) or if the attacker has insider knowledge.
The new parameter OutputFormat=JSON
of the ReadViewEntries URL command, which
was introduced in Domino 7.0.2, is not affected, since it always returns
a JavaScript object (not an array) on the top level.
But for self created JSON - perhaps
in agents or HTML views - you should check, if you have to prevent this
vulnerability.
There are (at least) 2 methods to protect
your application:
- The server-side code expects some kind of information as parameter, which the server has sent to the browser. This could be a randomly created number, which is sent in form of a cookie. After the call, the server checks, if this information is part of the call's parameter (and if it is equal to the sent information). If not, no content is returned. Since the same origin policy prevents access to this cookie for JavaScript code not originating from the same server, the malicius web page cannot access it.
- You can create a JavaScript
response, which cannot be executed directly. For example, you prepend
while(true);to the answer. In your client-side application you could easily modifiy the response before evaluating it. You could cut out the first line or just prepend//, thus making the first line a comment.
For a detailled inspection please read
the analysis of Fortify Software.
Source: http://www.fortifysoftware.com/advisory.jsp
