XSS: Cross Site Scripting attack

9:30 AM Xun 1 Comments

XSS (Cross Site Scripting), now and then

In Nov., users of Facebook were "offered an opportunity for something (a shocking must-see video? a free iphone?)" if they could copy and paste a line into their address bar. A number of them did, they were then bombarded with explicit and violent content. For 24 hours, the content spread throughout the site and forced Facebook shut down malicious pages, and roll back any infected user accounts.

Facebook is a fertile ground for XSS infestation. It is only a surprise how blatant and "old timer" the manner of the attack (Yes, free iPhone!). Only in May, Facebook rolled out a "Self-XSS protection" security feature to protect users from such spam and scam, on the wake of three consecutive XSS attacks.

The first was passed as stories posted on users' wall, with a bit of iframe code embeded.



The second one affected a Facebook "channel" page used for session management, also a bit of JavaScript is injected into the url.


The third one involves a video posted through a Facebook app. To unsuspecting eyes, the video is nothing unusual. However, launch of the video also quietly unleashed the coded attack behind. Code screenshot shown below:



Source: Recent Facebook XSS Attacks Show Increasing Sophistication

As a matter of fact, Facebook is faced with clickjacking and scam campaign on a daily basis.

More and more, with ever faster pace, we are willingly / unwillingly make ourselves part of corporate data, for better or for worse. Every tidbit information about ourselves, significant or trivial, name, addresses, phone number, social security numbers, credit card, our friends' names, are fed, mined, aggregated into advertisers' database. Anything we do not directly type into some websites are inferred, stored and updated in the corporate databases too. The explosion of online activities and information means many things. It makes Facebook the crown jewel of social networks, it also subjects Facebook to intense scrutiny and daily attack. It crowns JavaScript the language of the web, it also turns JavaScript into the most widespead tool of malicious scripting.

In 2005, MySpace was about as popular as Facebook is today, and XSS attacks were as little known as it is widespread today. Then in Dec 2005, the security world is awoken to worm named "Samy". The samy worm was designed to spread from one user profile to another, and it infected more than a million users in 24 hours. As potent as it was, the Samy worm was set out to make a name. So it did. It made a lasting impact, the reasearch into xss attacks exploded, unfortunately so did the effort in exploit web vulnerability in the form of XSS attacks.

In 2006, XSS attacks got inventive. Intranat hacks, keystroke tracks, JavaScript port scanners, traojan horses, etc. were disguised in every form that contains some html / javascript code, emails, websites, chat rooms, message board. Security holes were discovered in more than 70% of web sites.

Fast forward to today. In early 2011, IMB published a white paper reporting on their research of XSS attacks. The research used a sample group of about 675 websites, most of them Fortune 500 companies. The method used is a non-intrusive, shallow crawling of the sites involved. Therefore no logins, no deep digging into sites.

The result is disturbing: 14 percent of the sites, through their own or third part JavaScript vulnerabilities, could Infect with Malware and viruses, Perform Phishing attacks on users of these sites, spoof web contents, hijack users' web sessions and perform action on their behalf. The likelihood that a random page on the internet contains a client-side JavaScript vulnerability is approximately one in 55.



(Source: Close encounters of the third kind).


The route of XSS attack

Attacks may come blantantly or stealthily. If your browser is popping up blinking ads saying you are a jackpot winner;if you were unexpectedly led to violent, sextual content while browsing news, you can correctly assume that you are XSS'd; Or you could be completely blindsided until one day your bank told me that your information may have been stolen (this has happened to me).

How did these attacks happen? You may come up with a list of maybe answers. Maybe one day you opened up an email, which led to a suspicious website; or maybe you opened an attachment you thought it was sent from your friend; or maybe you followed the link in the posts on your friend's wall, through your smart phone, your mobile tablet ... One way or another, it is either that: a) you were led to visit a malicious website; or b) you visited a trusted site yet the site was hijacked and was planted a seed of malicious attack; or c) you clicked a link that is crafted with malicious script; d) a security hole of your browser was exploited and javascript was injected.

Elementary XSS details

The chase never ends. You plug one hole, more comes up. XSS is filled with new ways of vulnerability exploitation and code injection. However, something fundamental remains.

There are two major flavors of XSS: non-persistent and persistent. Non-persistent attack happens when a url or form is injected with malicious code, however it is not persistent, it is click-based/event based; Persistent attacks are conceivebally more dangerous, they can cause lasting damage because the code is stored as a cookie or in database by the website, and affect all users who visit the site. In this case, users are defenseless. Outside of the persistent/non persistent categorization, domain-based attacks, which can be both persistent and nonpersistent, are also prevalent. Domain-based attacks are exclusively on the client side and are engineered to exploit vulnerabilities in the html document (script, DOM handling). The vulnerability could be both from the javascript implementation or browser interpretation.

XSS through urls

Script injection frequently happens on the url level. It is first made well known by the security expert Amit Kleint in DOM Based Cross Site Scripting or XSS of the Third Kind


It is a common pratice that we embed bits and pieces of information in the querystirng of an url then parse it in the JavaScript and do something accordingly. As in the example listed by Amit Kleint.




However this serves an opening for code injection for hackers. They can simply call a url as such:



As now most developers are aware of danger of this, hackers are also more skillful disguising their intent. So the above url will be more likely look like below:





(Notes: To my great surprise and annoyance, both of the above url calls execute immediately in blogger. I had to take screenshot of the code. Below is the screenshot of the script gets executed in blogger:)



XSS through input forms

Data can be passed through urls. It also frequently passed through input forms, through input textboxes, textareas. Search boxes were and still are hackers' first bait. They often execute scripts that automatically submit a form and test for opportunities. If a search for "blah" returns a page that says "Sorry, a search for blah is not found", they could then subsitute the "blah" with a test script:
<script>alert('XSS')</script>
; if the page excuted with a alert box, bingo, they can plan their atrack right now; if no, they can inspect the JavaScript cleansing machanism, then circumvent it.

As a matter of fact, because of the danger of inputting malicious code, many websites use stricter user input validation and output sanitation, encoding and escaping special characters. As a result, hackers also have camouflaged their scripts by playing with quotes, different encoding method.

The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws


XSS through images, flash, pdf, videos. You name it.

On the internet, every object can become a source of script embedding, images, flash objects, pdfs, videos, you name it! And unless you disable JavaScript, script can be excuted upon the event of loading, unloading, or when you thought you were merely watching an harmless video, as in the case of Facebook users in April.

Modern email programs, such as GMail, outlook, normally do not block images from displaying unless your explicitly set permission. Why? Because, the src property of images can either be direct injected with script, or indirectly linked to a malicious site.

Flash object too. Adobe just released a Flash Player update in response to reports that a cross-site scripting vulnerability is being exploited in the wild in active targeted attacks. (Source: Hackers exploiting Flash Player XSS vulnerability


Parting words

There is more, so much more, to talk about XSS, even just to scratch the surface. Blunt forced XSS, XSS filter and evasion, XSS detection and prevention, etc. And it is constantly evolving, the attacking and defending side of XSS. We can say nothing for sure, other than that, XSS is a clear and present and ever-escalating danger, just look at Facebook today.


Source:
XSS Attacks: Cross Site Scripting Exploits and Defense

1 comment:

  1. Nice blog... This blog very nicely written and easy to understand. I want more information on javascript vulnerability protection. Please share. Thanks

    ReplyDelete