5

My application has a user management module which uses fields like username, first name, email-id, password,.. . I tried scanning these fields and filling in malicious JavaScript to test for cross site scripting like anil<script>alert(1);</alert>. The modified data is stored in the database, but when I refresh the page, I do not see any popup message. How can I make sure I'm not vulnerable for Cross Site Scripting?

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
lakshmi Prudhvi
  • 213
  • 1
  • 2
  • 7
  • 2
    You need to hire an expert to perform VA/PT for your applications. – Shurmajee Jul 01 '13 at 12:27
  • It seems that you don't use any scriptable tags/attributes in your input. Try something like ``. Burp Suite Pro also has an excellent automated XSS scanner. – buherator Jul 01 '13 at 12:53

4 Answers4

10

Testing for Cross-Site Scripting is unfortunately not completely straightforward . Depending on where your input is returned, you might need to use a number of different vectors to test it completely.

If you want to use an automated tool to review your site, something like arachni might be a good idea, or burp pro's scanner if you have access to that.

From a manual perspective, you can get an idea of the range of possible vectors from the list at html5sec

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
8

What you're doing depends on two things happening

  1. You are able to upload javascript into the datastore where that javascript will be rendered by a user.
  2. When that JavaScript is rendered by the user's browser it actually runs.

Developers are supposed to check input for bad stuff, make sure the input is html encoded and reject the bad stuff like markup. On the other side the developer should make sure that anything that did make it into the database gets rendered harmlessly.

The fact you're able to get javascript into the database tells me the developer(s) didn't do a good job of checking for input and they need to fix that. I've never met someone who has html tags in their name :)

The fact that it doesn't run on the other side tells me that the framework they use probably encodes the output so it renders harmlessly in most cases. I'm willing to bet if you really try hard you can encode you're javascript in a manner that you can get it to run. You have to make sure you check every input and every output. Automated tools are good and all but they're only a starting point.

Hope This Helps!

Four_0h_Three
  • 1,225
  • 2
  • 8
  • 13
  • 1
    I forgot to mention to check different browsers as well. Try your attacks in IE, Chrome, Firefox, Safari and Opera. This kind of thing takes a long time to do but if you don't test these I guarantee someone from the internet will :) – Four_0h_Three Jul 01 '13 at 15:43
  • 2
    Have to add this for completeness: http://xkcd.com/327/ – Ryan Jul 01 '13 at 16:21
  • Thanks for noticing that names cannot have – Val Jul 01 '13 at 18:53
  • 3
    It really shouldn't matter if there's markup in the password because the password plain text should never be stored anywhere in the database ever. Passwords need to be salted and hashed. The salt should be done in a manner that would render dictionary attacks useless so the attacker will have to use brute force and if two people have the same password it doesn't compute to the same hash. – Four_0h_Three Jul 01 '13 at 19:21
1

There are three basic approaches to security testing - as with any other testing. This is the framework that I've put together for the fortune 500 company where I am responsible for defining the security testing strategy. This is based on standard QE/QA test practices, just expanded to address "security" features.

  1. Hire experts. They are very expensive and will generally not test your entire product. Or, if they do test your entire product, it is absurdly expensive.

  2. Automated testing, using scanners. This covers you for the most basic of vulnerabilities but scanners are dumb, and miss a lot.

  3. Testing that your product behaves properly with unit, integration, and system tests. Do your encoders properly encode output for the various locations where XSS occurs (javascript, html, css, urls, etc)? Do you have a UI framework? Does the UI framework properly use the encoders in all locations where output is written (including normal output and error messages)? Is the UI framework called consistently throughout the application?

atk
  • 2,156
  • 14
  • 15
-1

You can test for XSS vulnerabilities yourself. First of all understand there are 3 types of XSS attacks

  • Persistent XSS
  • Non-Persistent XSS
  • Dom based vulnerability

You can check the OWASP wiki for more information

If you are not ready to read,you can try some tools available online such as Xsser

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
Jijo John
  • 129
  • 3