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?

Improve this question
2
  • 2
    You need to hire an expert to perform VA/PT for your applications.
    – Shurmajee
    Commented Jul 1, 2013 at 12:27
  • It seems that you don't use any scriptable tags/attributes in your input. Try something like <script>alert(1);</script>. Burp Suite Pro also has an excellent automated XSS scanner.
    – buherator
    Commented Jul 1, 2013 at 12:53

4 Answers 4

Reset to default
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

Improve this answer
1
  • 1
    +1 for the html5sec link I was not aware of.
    – Lex
    Commented Jul 1, 2013 at 14:12
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!

Improve this answer
4
  • 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
    Commented Jul 1, 2013 at 15:43
  • 2
    Have to add this for completeness: xkcd.com/327
    – Ryan
    Commented Jul 1, 2013 at 16:21
  • Thanks for noticing that names cannot have <script> in them. It seems that developers were good to pass it through. Since nobody else mentioned that, html tags are valid in names and passwords.
    – Val
    Commented Jul 1, 2013 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
    Commented Jul 1, 2013 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?

Improve this answer
-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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .