Google Web Toolkit

Google Web Toolkit (GWT) is a unique sort of proxy framework. Instead of acting as a
proxy between an existing application and the client, GWT compiles an existing Java
application into JavaScript. It is because of this compilation process that method discovery
in GWT applications is uniquely difficult. Methods are sent to the client with a filename
in this format: 32 letters/numbers.cache.html. Here’s an example filename:
9B5996A7A61FA7AB0B780C54253DE830.cache.html.
This file is composed entirely of JavaScript that GWT compiled from the Java application.
Methods are often named a series of two- to three-character obfuscated names
such as qe, xrb, and the like. Methods can thus be discovered by analyzing the data
contained in a .cache.htm; however, method discovery against an application using GWT
remains significantly more challenging than discovery against any other framework.
The client will be served gwt.js. This file will contain required GWT methods and
generally begins with the following JavaScript:
function DynamicResources() {
this.pendingElemsBySrc_ = {};
this.pendingScriptElems_ = new Array();
}
DynamicResources.prototype = {};
GWT is available at http://code.google.com/webtoolkit/.

read more "Google Web Toolkit"

Client-Server Proxy

Client-server proxy is sometimes also known as client/SOA. Client-server proxy
applications have two main determining factors: they rarely require a full page reload
during usage, and session state is mostly handled by the client. Due to the lack of full
page reloads, the client-server proxy style of AJAX applications is often described as
“wrapping an AJAX GUI around a web service.”
In the proxy style of AJAX application, the JavaScript that will be executed in a client’s
web browser can be generated in two ways. The first way is for the JavaScript
methods to be prerendered on the server and then sent down to the client. These methods
are generally named the same or quite similar to methods on the server. When the
client receives the JavaScript methods from the server, the methods are simply plugged
into an eval() and executed. The other style generating the JavaScript is for the server
to send down a chunk of JavaScript to the client, which, once executed, is able to generate
new JavaScript methods on the fly. This JavaScript generates methods on the fly by
reading a list of methods defined by the server in a file such as a Web Services Description
Language (WSDL) file. In practice, the prerendered style of generating JavaScript is
more commonly seen in real-world AJAX applications, while on-the-fly generation is
usually seen only with web applications that use Simple Object Access Protocol
(SOAP).
Despite the number of different client-server proxy frameworks in existence, the steps
involved with creating a proxy style AJAX web application are generally the same:
1. The framework looks at server-side code, such as a Java web application, where
certain methods are tagged as public.
2. The framework is told which of these functions are to be exposed to clients
3. Framework code then automatically goes through and tags these methods and
generates a JavaScript proxy that puts methods, often of the same name, into
the web browser.
4. Then, whenever the client makes a method call in JavaScript, the call is passed
on to the JavaScript proxy and then on to the actual method being called.
This allows for easy abstraction, for example, if one development team is working on
the actual application and another team is working on web design. The web design team
can simply be handed a file of JavaScript methods that can be called to perform work
when needed, without having to interact with the behind-the-scenes Java application. A
client-server proxy style application such as this requires the client to contain all of the
available methods, because, due to the asynchronous nature of AJAX, any method can be
called at any time. For this reason, a client-server proxy style AJAX implementation is
quite interesting and useful from an attacker’s perspective.

read more "Client-Server Proxy"

Preventing Cross-Site Scripting

To prevent XSS, developers must be very careful of user-supplied data that is served
back to users. We define user-supplied data as any data that comes from an outside network
connection to some web application. It could be a username submitted in an HTML form
at login, a backend AJAX request that was supposed to come from the JavaScript code
the developer programmed, an e-mail, or even HTTP headers. Treat all data entering a
web application from an outside network connection as potentially harmful.
For all user-supplied data that is later redisplayed back to users in all HTTP responses
such as web pages and AJAX responses (HTTP response code 200), page not found errors
(HTTP response code 404), server errors (like HTTP response code 502), redirects (like
HTTP response code 302), and so on, the developer must do one of the following:
• Escape the data properly so it is not interpreted as HTML (to browsers) or XML
(to Flash).
• Remove characters or strings that can be used maliciously.
Removing characters generally affects user experience. For instance, if the developer
removed apostrophes (’), some people with the last name O’Reilly, or the like, would be
frustrated that their last name is not displayed properly.
We highly discourage developers to remove strings, because strings can be represented
in many ways. The strings are also interpreted differently by applications and browsers. For example, the SAMY worm took advantage of the fact that IE does not consider
new lines as word delimiters. Thus, IE interprets javascript and jav%0dascr%0dipt
as the same. Unfortunately, MySpace interpreted new lines as delimiting words and allowed
the following to be placed on Samy’s (and others’) MySpace pages:
(div id="mycode" expr="alert('1')" style="background:url('java
script:eval(document.all.mycode.expr)')")(/div)
The parenthesis are intensionally replaced by HTML tags.
We recommend escaping all user-supplied data that is sent back to a web browser within
AJAX calls, mobile applications, web pages, redirects, and so on. However, escaping
strings is not simple; you must escape with URL encoding, HTML entity encoding, or JavaScript
encoding depending on where the user-supplied data is placed in the HTTP responses.

read more "Preventing Cross-Site Scripting"

HTML Injection Using MIME Type Mismatch

IE has many surprising and undocumented behaviors. For example, if IE 7 and earlier tries to load an image or other non-HTML responses and fails to do so, it treats the response as HTML. To see this, create a text file containing this: (script)alert(1)(/script) Then save it as alert.jpg. Loading this “image” in IE from the URL address bar or an iframe will result in the JavaScript being executed. Note that this does not work if the file is loaded from an image tag. Generally, if you attempt to upload such a file to an image hosting service, it will reject the file because it is not an image. Image hosting services usually disregard the file extension and look only at the magic number (the first few bytes) of the file to determine the file type. Thus, an attacker can get around this by creating a GIF image with HTML in the GIF comment and save the GIF with the .jpg file extension. A single-pixel GIF is shown here: 00000000 47 49 46 38 39 61 01 00 01 00 80 00 00 ff ff ff |GIF89a..........| 00000010 ff ff ff 21 fe 19 3c 73 63 72 69 70 74 3e 61 6c |...!..(script)al| 00000020 65 72 74 28 31 29 3c 2f 73 63 72 69 70 74 3e 00 |ert(1)(/script).| 00000030 2c 00 00 00 00 01 00 01 00 00 02 02 44 01 00 3b |,...........D..;| Naming this file test.jpg and loading it in IE will result in executing the JavaScript. This is also a great way to attempt to inject Flash cross-domain policies. Simply place the Flash security policy XML content in the GIF comment and ensure that the GIF file does not contain extended ASCII characters or NULL bytes. You can also inject HTML in the image data section, rather than the comment, of uncompressed image files such as XPM and BMP files.

read more "HTML Injection Using MIME Type Mismatch"

HTML Injection Using UTF-7 Encodings

HTML Injection Using UTF-7 Encodings
If a user has Auto-Select encoding set (by choosing View | Encoding | Auto-Select) in IE,
an attacker can circumvent most HTML injection preventions. As mentioned earlier,
HTML injection prevention generally relies upon escaping potentially harmful characters.
However, UTF-7 encoding uses common characters that are not normally escaped,
or depending on the web application, may not be possible to escape. The UTF-7 escaped
version of (script)alert(1)(/script) is this:
+ADw-script+AD4-alert(1)+ADw-/script+AD4-
The parenthesis are intentionally applied instead of HTML tags.
Note that this is an uncommon attack because users generally do not have Auto-
Select encoding turned on. There exists other UTF encoding attacks that leverage the
variable length of character encodings, but this requires extensive knowledge of UTF
and is out of scope for this book. However, this issue introduces how neglecting other
encodings like MIME types can lead to HTML injection.

read more "HTML Injection Using UTF-7 Encodings"