<

Cross-Site Exploitation

Published on
17,669 Points
7,769 Views
4 Endorsements
Last Modified:
Awarded
Community Pick
Kevin Cross
Father, husband and general problem solver who loves coding SQL, C#, Salesforce Apex or whatever.
This article is about Cross-Site Scripting, Request Forgery and other same origin policy based attacks which are very much still prevalent or at least should still be in our minds as developers. As one of the great webmasters said: "...with great power, comes great responsibility!"

Therefore, this is intended to be an informational resource for those new to web development to ensure that these important web security vulnerabilities are known and considered when developing new web applications/sites. Furthermore, the focus will be on two of the most common, being Cross-Site Scripting and Cross-Site Request Forgery to be explained later.

Please note that this information is from my original presentation on the topic at a security forum (http://ohioinfosec.org/) in August of 2007; therefore, as with any thing in the technology world, ensure to check for updated information.

Let's begin …
 

1. Same-Origin/Site Policy

What Is Same-Origin Policy?
The same-origin policy was originally released with Netscape Navigator 2.0 to specify how browsers and associated programming languages like JavaScript handled security. The gist of the policy is to restrict one web-site from accessing programmatic functions on another site, while allowing a site free reign to code resources on that same Uniform Resource Identifier (URI). In other words, scripts are supposed only be able to manipulate other scripts on the same unique domain name (e.g., any.plain-old.com), port (e.g., 80) and protocol (e.g., http) combination, so in our example the only valid URI that would be allowed is http://any.plain-old.com.

To help with this concept, please see this illustration of how the same-origin policy would handle document manipulation by a script originating from http://store.company.com/dir/page.html per the original Netscape documentation.
1.1 Netscape Same-Origin Policy Documentation --source: http://taossa.com/index.php/2007/02/08/same-origin-policy/

It is good to note at this point that this concept can be found in the design of pretty much every major browser today, so don't be fooled into thinking since Netscape 2.0 is deprecated that this concept and the security concerns associated died along with it.

Same-Origin Attacks
Here is a summary of some of the different types of attacks that abuse the same-origin policy in some fashion, keeping in mind that we will discuss more deeply the first two only. Please use this article as a starting point for your research on these others and how they may impact or are mitigated within your systems.

Cross-Site Scripting (XSS -- CSS less used due to Cascading Style Sheets)

Cross-Site Request Forgery (XSRF or CSRF)

Cross-Site Tracing – XSS variant

- Uses HTTP TRACE to echo back attacker content

Web Cache Poisoning

-The attacks target the local browser cache or (more often) a remote caching proxy

HTTP Response Splitting – XSS variant

HTTP Request Smuggling – XSS or Cache Poisoning

HTML and JavaScript Network Scanning
Okay, so let's get digging ...
 

2. Cross-Site Scripting


¿What is [it] ?

Cross-site scripting is a security vulnerability which allows code injection, malicious or otherwise, into web-pages. Attacks of this nature are typically aimed at one of the following:

phishing/cookie theft in an effort to gain access to restricted information;

defacing of web-sites and/or social engineering others with a specific point to make or goal in mind or merely for the fun of watching the uninitiated squirm about in a chaotic frenzy;

executing of malicious code on the web-site's client machine.
Here is a brief evolution of XSS:

Feb/2000 – Cert Advisory released

CERT® Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests
http://www.cert.org/advisories/CA-2000-02.html

Apr/2000 – Steve Champeon coins the acronym XSS in an article to make a distinction from Cascading Style Sheets (CSS).

 

¡The ‘Evil’ Purple Dinosaur!

According to Champeon, early attacks of this nature manifested itself as defacement of guest books through submission of HTML exploits of the IMG tag. The attackers, the evil genii they are, utilized the most annoying thing they could think of: a source picture of Barney, the big purple dinosaur.

This same attack in present day could grow from this simple annoyance to a much more malicious attack:
Just think how awful it would be to load a guestbook and have the browser window close and then reopen without menus or toolbars, regaling you with a Flash presentation involving the Purple One, a MIDI file of "I Love You, You Love Me," a WAV file of that horrible "ha-HUH, HA-huh!" And what if, after 10 seconds of this torture, a JavaScript confirm() dialog box popped up, asking you if you hated purple dinosaurs? How about if a "Yes!" response just happened to email the reprobates responsible, giving them your email address so they could send you a virus that renamed every file on your hard drive Barney? --Steve Champeon
 

¡How It Works!

1. Reflected attacks
Like a carnival mirror, XSS causes you to get all distorted by simply looking at your own reflection. Take a site that tracks authentication via cookies that also has a nice search feature, which isn't that secure and so is vulnerable to XSS. Using social engineering like click here because you won a million dollars, users of the targeted, insecure site are enticed to click on a link containing malicious code injected into the standard HTML which gains the attacker access to secured data such as your user cookie with session and authentication information and all.

2. Stored attacks
Similar to the above, imagine our same site utilizes a backend datastore, which is the source of this search page and, instead of attacking the page, the attacker cleverly injects SQL code for example into this database. Now, every time results are queried from this backend storage, it will contain the attacker's malicious code. Yes, you got it, instead of having to one at a time target each client, the attacker can simply infect the whole forum and reach the millions of unsuspecting victims all happy to have won a million dollars.
 

¿Now what ?

Protect Your Code
Limit the display of user inputs, filtering down to those bits of information that are absolutely required. Hence, don't just display data all the data because I told you to. Plus, what are all these weird characters I am sending you? Why is there textual data in this value that should be a number?

Simple questions like these in the design of your systems will help tremendously in determining which pieces of data to clean as I would recommend you validating and cleansing data coming from all forms, data sources, and/or URL parameters that are not under your direct control that will also end up displayed or stored somewhere.

One key trick to this you will see is the replacement of special characters with HTML entities like &amp; instead of the ampersand itself.

To help you reduce the amount of special HTML characters that have to mitigated out of inputs, you should these inputs to only allow code snippets valid for use on your site. For example, most forums will let you bold text by wrapping it in a {b} tag, but typically these same sites don't allow you to add your own form so {form} should not be allowed, right? Right! Additionally, if these tags take a specific syntax and set of values, then only allow values consistent with that syntax (e.g.,  font color is a three or six character value containing only A-F and 0-9, so if you let me put an entire SQL statement in there then shame on you).

As an aside, most cleansing routines will replace carriage return and line feed characters with <br/> tags and harmful words such as "script", although depending on the application there may be valid reasons for this word to exist in the content so it is tough to generalize.

One rule of thumb that should be good across the board is be explicit, don't assume. For example, yes, the content-type of most pages and correct character set will occur by default, but to be safe always specify this explicitly.

Insecure Examples
Python
 
print "<script>alert('xss');</script>"

Open in new window


ASP
 
<%= "<script>alert('xss');</script>" %>

Open in new window


Writing such text directly to HTML will result in this:
 
<script>alert('xss');</script>

Open in new window

Which as you can see is valid HTML and so will be processed.

More Secure Examples
Python
 
print cgi.escape("<script>alert('xss');</script>")

Open in new window


ASP
 
<%= HTMLEncode(“<script>alert('xss');</script>”) %>

Open in new window


PERL
 
$text =~ s/[^A-Za-z0-9 ]*/ /g;
HTML::Entities::encode($text);
Apache::Util::html_encode($text));

Open in new window


Contrary to previous examples will result in this being written to the HTML document:
 
&lt;script&gt;alert('xss');&lt;/script&gt;

Open in new window

Which HTML still processes but now as text to display on the page's content.

Browse Wisely
Just use common sense here. There are techniques like disabling scripting languages in your browser or using add-ins that block scripts, but note that not all scripts are of the malicious nature and so this also limits the functionality of some trusted dynamic web-sites.

The bigger thing is to browse discerningly. Have you ever heard the advice to NEVER click on links directly? It all sounds like paranoia, but examine some of the suspect e-mails you get by hovering over the links and you will see that the displaying domain name and purpose of the link doesn't match the actual URL actually in the background. You should copy the link's address and if this is a site you trust visit the site directly.
 
Example: instead of following a link to CNN to view article {1234}, open CNN.com and search for the content referenced by {1234} yourself.
Continuing on this thought, ensure that you answer prompt boxes VERY carefully.
 
You can always hit the “X” or use Alt+F4 to close a window without responding – yes/ok or no/cancel are NOT the only options.
¿What Else ?
 

3. Cross-Site Request Forgery


¡I Didn’t Shoot The Deputy!

Cross-site request forgery is another of the same-origin policy attacks and it deals with tricking a web victim into loading a page that contains a malicious request to page which trusts this same user's credentials. Again, as you can see, this involves sites that rely on a user's identity and as such exploits the site's trust in that identity. The user typically thinks they are performing a different task but using HTTP requests that have side effects the attacks use the user's own browser to send HTTP attacks to the target site.

Here is a brief evolution of XSRF:

1988 – Norm Hardy released “The Confused Deputy”


2000 – Zope.org is hit with a confused deputy attack

ClientSideTrojan: Client side trojan issue
http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan

2001 – Peter Watkins coins the term CSRF (per CGI Security)

The Cross-Site Request Forgery (CSRF/XSRF) FAQ
http://www.cgisecurity.com/csrf-faq.html
 

¡How It Works!

A link to the malicious site is posted to a targeted site, then any trusting user of the site will browse to the malicious, linked web-site, thus becoming the victim or more appropriately an accomplice. The user is an aid in the attack as s/he is enticed to submit a form that points back to the original target site where the link was originally planted. Since the user was already authenticated, the form submission is accepted on the target site and has permissions to modify sensitive data such as the user's own password or harvest confidential information from the site.
 

¿Now what ?

Protect Your Code
Limit access to POST or logic pages for the web application by inspecting the REQUEST referrer (origin).
 
Note: Some browsers or valid scenarios may have a blank referrer which would get blocked as well.
Therefore, a means of mutual authentication typically used is tokenized requests that are only accepted to post data if it contains a proper secret value, token. Furthermore, this is usually made more secure by the practice of the multi-step write process or confirmation pages.
 

4. Summary

Same-origin policy is a concept implemented in some manner in most if not all browsers and can be abused by such attacks as XSS, which exploits the trust a user has for a web-site or application, and XSRF, which exploits the trust that a web-site or application has for a user.

Therefore, simply put: trust no one!  

Consider, trust to be more than a two-way street: you never know where traffic is coming from. Anyone can insinuate themselves into the middle of a trusted relationship and abuse each partner of the relationship suspecting they are communicating with the other and so leave of the formalities of security.

With that being said, let me leave you with these points:
protect your code / clients: Validate and/or filter display of all remote data inputs;

don’t browse promiscuously: Know for sure where you are being navigated to;

Cross-Site Scripting (XSS) and Cross-Site Request Forgery (XSRF) are considered significant threats, so protect yourself with knowledge;

lastly, always remember:

<?php $live = "secure"; /* or */ die("pwned"); ?>

Open in new window


Thanks for reading !

Best regards and happy coding,

Kevin C. Cross, Sr. (mwvisa1)

 

References:

Here are some additional links to good resources that have stayed valid over the years. Some of these were sources used in resource for my presentation, so there are some good references to keep handy.

(source reference for presentation)
Same-Origin Policy Part 1: Why we’re stuck with things like XSS and XSRF/CSRF
http://taossa.com/index.php/2007/02/08/same-origin-policy/

Community Creators, Secure Your Code!
http://www.alistapart.com/articles/secureyourcode

Cross-site scripting Wiki
http://en.wikipedia.org/wiki/Cross-site_scripting

XSS (Cross Site Scripting) Cheat Sheet
http://ha.ckers.org/xss.html

PHP XSS exploit in phpinfo()
http://seclists.org/bugtraq/2003/Jun/0047.html

Preventing Cross-site Scripting Attacks
http://www.perl.com/pub/2002/02/20/css.html

Related EE Articles

5 Steps to Securing Your Web Application
http://www.experts-exchange.com/A_1263.html

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If you found this article helpful, please click the Yes button after the question just below. This will give me (the author) a few points and might encourage me to write more articles.

If you didn't or otherwise feel the need to vote No, please first leave a comment to give me a chance to answer and perhaps to improve this article.

Thank you!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
4
Comment
Author:Kevin Cross
  • 2
3 Comments
LVL 15

Expert Comment

by:Eric AKA Netminder
mwvisa1,

Congratulations on your article being published, and being awarded both Community Pick and EE-Approved designation.

You have provided an informative and entertaining overview of an important subject, and I truly do appreciate it.

Regards,

ericpete
Page Editor
0
LVL 61

Author Comment

by:Kevin Cross
Thanks, ericpete, for the kind words and accolades!

I definitely appreciated your guidance and am thankful you have a knack for finding lost publications!

Thanks again and happy reading to all.

Regards,
Kevin
0
LVL 61

Author Comment

by:Kevin Cross

Addendum

To bring this more to the modern day, there have been some very intriguing discussions on how HTML5 may actually put us "backwards" in this regards, at least on initial implementation, until everyone becomes re-familiar with the security concerns and update their old code accordingly.

For example, some of the above was highly predicated on Same-Origin Policy enforcing certain restrictions on JavaScript. With the new Cross-Origin Resource Sharing (CORS), w3.org/TR/access-control/, it is now possible for cross-site XMLHttpRequests for example:
http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/

A Note on Security

In general, data requested from a remote site should be treated as untrusted. Executing JavaScript code retrieved from a third-party site without first determining its validity is NOT recommended. Server administrators should be careful about leaking private data, and should judiciously determine that resources can be called in a cross-site manner. --Arun Ranganathan

The word judiciously is key here. Like anything, when used in moderation, good things are possible. The basis of CORS and Uniform Messaging Policy (UMP - w3.org/TR/UMP/), as another example, is to allow for the scaling capabilities of the web. Specifically, the end goal from the documentation is to enable richer capabilities for web applications as demonstrated by Arun's article involving XMLHttpRequest, w3.org/TR/XMLHttpRequest2/, and push notification technologies like discussed in Server-Sent Events (SSE), w3.org/TR/eventsource/.

So simply disabling the technology as some do with scripting languages isn't my point. Educate yourself and ensure that you understand the ramifications as new browsers like Firefox 3.5, Safari 4, Chrome 2 and Internet Explorer 8 come equipped with some form of HTML5 support.

In parting, research some more for yourself and post back any thoughts on new security threats to be aware of and even good news facts like how HTML5 error handling and other nice features may aid us in the fight to keep our applications and clients secure.

Regards,

Kevin
0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Join & Write a Comment

The viewer will learn how to look for a specific file type in a local or remote server directory using PHP.
Any person in technology especially those working for big companies should at least know about the basics of web accessibility. Believe it or not there are even laws in place that require businesses to provide such means for the disabled and aging p…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month