XSS For Managers

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is a type of vulnerability which is very widespread and allows an attacker to insert malicious code (JavaScript) into your web browser via the use of a vulnerable web application. The attacker can deliver their malicious code in a number of different ways.

They can trick you into clicking on a link (Reflected XSS), or wait for you to visit a page which already has the malicious code embedded into it (Stored or Persistent XSS).

That annoying pop-up box with the number 1 in it? That's just a way that some people visually prove that their JavaScript (XSS) has been run. But don't let that lousy pop-up box fool you, there is a lot more to XSS than that!

What can hackers do with XSS?

• A hacker may be able to steal your 'cookies' and login to the application as if they were you!
• They may be able to redirect you to a malicious web site without you knowing in an attempt to trick you into giving away sensitive information such as your bank details.
• They could add fake login pages to the vulnerable application to trick you into giving them your username and password.
• They could even use XSS to bypass other security measures which are built into the application and your web browser to protect you.
• The possibilities are almost limitless. Take over your webcam? Yep! Listen in on your computer's microphone?

For advanced attacks see the The Browser Exploitation Framework (BeEF) tool.

Who's been hacked using XSS?

• The Apache Foundation, the creators and maintainers of one of the most popular web server software on the Internet had their servers compromised by an initial XSS attack.
• An XSS attack on the official forum of the popular Linux Operating System, Ubuntu, allowed the attackers to download the usernames, email addresses and passwords for 1.82 million of their users.
• XSS attacks typically target the application's users and their local networks; however, as seen in the examples above, when those users are administrative users the application's web servers are also at risk.
• XSS vulnerabilities are discovered within Facebook, Yahoo, Google, Twitter and other high profile websites on a daily basis by independent security researchers participating in bug bounties.

Here is a list of other hacks using XSS -https://www.google.com/fusiontables/DataSource?snapid=S1158702BBoV

What can I do to protect myself against XSS?

• Make sure that your web browser is kept up to date and that it has all of its security features enabled, such as Cross-Site Scripting (XSS) filtering. If your particular browser does not have an XSS filter, like Firefox, then you can download an XSS filter add-on called NoScript.
• Be careful about what links you click on. A link may look harmless enough, but may contain malicious XSS payloads.
• Log out of web sites when you are finished with them, this makes it harder for hackers to steal your 'cookies'.

The technical bit! What can I do to protect my web application against XSS?

• Cross-Site Scripting occurs when untrusted input is output to a page without first being sanitised and/or properly encoded. For example, if a user supplies their username to login and then you display that username without sanitising and/or encoding it, what happens if the username contains HTML characters?
  
  The web browser will not be able to tell the difference between the user's username and what is the page's valid HTML. Data (the username) is being mixed with code (the HTML)! This could allow a user to login with a username that contains malicious JavaScript and have it execute in the browser within the context of your web application.
  
• Make sure that you sanitise the username before using it, for example, if users should only have alpha numeric characters in their usernames then enforce this with input sanitisation. Use a whitelist! Compare the username against known goods instead of known bads.
  
• Use the right encoding! If the username is going to be used within HTML, then HTML encode all of the username's characters.
  
  This way the browser will know what is meant to be rendered as HTML and what is not. It's not all about HTML encoding though! You must encode for the right output 'context'. See the links below for further information.
  
• Scan your applications for XSS issues. There are many automated web application security scanners which can detect XSS issues in web applications. You could try giving the Open Source OWASP ZAP a go.
  
• Set your session cookies with the HttpOnly flag. This tells the browser that the cookie should not be accessed by JavaScript, helping protect your users from having their sessions stolen.
  
• A HTTP header called Content Security Policy (CSP) can be set by the web server to tell the web browser what and where JavaScript is allowed to be executed from. It uses a whitelist!
  
• Finally, why not install a Web Application Firewall (WAF) such as the Open Source mod_security! A WAF will give your application that extra layer of defence to defend against those attackers but should be used in a defense in depth scenario and not as the only solution as bypasses are found often.

Where can I find further information?

The two types of XSS mentioned on this page (Reflected and Stored) are not the only two! We have only touched upon the subject here. Want to find out more?

The Open Web Application Security Project (OWASP) is a great resource for all things related to the security of web applications. Check out their wiki article on XSS or their XSS Prevention Cheat Sheet. For information on other types of web application vulnerabilities take a look at the OWASP Top 10.

Massive SQL injection attack

Mass Injection hits over 694,000 URLs

Hundreds of thousands of URLs have been compromised—at the time of writing, 694,000—in an enormous and indiscriminate SQL injection attack. The attack has modified text stored in databases, with the result that pages served up by the attacked systems include within each page one or more references to a particular JavaScript file.

The attack appears to be indiscriminate in its targets, with compromised machines running ASP, ASP.NET, ColdFusion, JSP, and PHP, and no doubt others. SQL injection attacks, which exploit badly-written Web applications to directly perform actions against databases, are largely independent of the technology used to develop the applications themselves: the programming errors that allow SQL injection can be made in virtually any language.

The underlying cause is a programmer trusting input that comes from a Web page—either a value from a form, or a parameter in a URL—and passing this input directly into the database. If the input is malformed in a particular way, the result is that the database will run code of the attacker's choosing. In this case, the injected SQL is simply updating text fields within the database, to make them include an extra fragment of HTML. This HTML in turn loads a JavaScript from a remote server, typically "http://lizamoon.com/ur.php" or more recently, "http://alisa-carter.com/ur.php." Both domain names resolve to the same IP address, and presently that server is not functional, leaving browsers unable to load the malicious script when they visit infected pages. Previously, it contained a simple script to redirect users to a fake anti-virus site.

The massive scale of these attacks (and the rapidly growing number of affected URLs) was first noticed by Websense Security Labs. On Tuesday, around 28,000 URLs were compromised; now more than 20 times more URLs are infected, and the numbers are still growing. The injected code is also found on a number of product pages on Apple's iTunes Store. Apple fetches RSS feeds from podcasters that broadcast using iTunes, and in a number of cases these broadcasters have been compromised by the SQL injection attack. As a result, the malicious code has made its way into Apple's system.

However, due to the way Apple processes the RSS feeds, there appears to be no exploitation vector; the injected HTML is safely nullified. SQL injections following this pattern appear to have been happening off and on for six or more months now. The domain name hosting the JavaScript changes each time, but the file name—ur.php—and the style of injection remain consistent. The actions of the scripts have been similar too; pop-up windows and malware downloads. Previous efforts were on a much smaller scale, however: hundreds of compromised URLs instead of hundreds of thousands.

In these earlier cases, the attacks originated from IP addresses in eastern Europe and Russia. It's been a busy week for SQL injection; at the weekend, MySQL.com, the website of Oracle-owned open source database MySQL, was hacked, again using SQL injection. A little embarrassing for a database vendor to be unable to use its own database securely.

XSS - Cross-site scripting

A Real-World Example

The term XSS gets thrown around a lot. Lot's of people don't quite know what it is though. Basically an XSS attack is a client-side vulnerability where a server does not properly sanitize data inputted to readily accessible forms.

In layman's terms, this generally means that a website will display any information given to it, regardless of its malicious content. This is important because it can be used to fool people into clicking on links to (otherwise) trustworthy sites which will, instead, cause malicious code to be loaded.

For this example, we are going to look at a government website which is vulnerable to XSS in two sites using the input from only one form. This is the website for the New York State Assembly. They have a convenient little page to help search for your representative.

Our target for today is the little box I have highlighted in yellow. Now, zip codes are normally numbers, let's see what happens if we give it deliberately false information. In this case, we tell it our "zip code" is "word"

This is the first sign that there might be an XSS vulnerability. The server is readily displaying our input.

Now, what we want to do is see if we can pass code to it. I generally test this by seeing if I can get it to display

In place of a plaintext output. To do this, we are going to take our previous link (http://assembly.state.ny.us/mem/?zip=word) and change it to our potential XSS link [instead of word we can put script alert('hi') ] please put script between <> and see what that gives us.

Here are some key things to remember about forming a sucessful XSS attack:

1. Forms can often be escaped with a ">
2. Some forms of sanitation can be escaped! Of course, this is often hard to do, it is definitely possible
3. Don't be modest. In a case like this, the form could have been pushed to the point of loading iframes with malicious code and all other kinds of fun stuff