First Steps In Security Testing

For about couple of months I've been interested in security and penetration testing. In my opinion, it's the most difficult area in testing at all, because it's the most technical one. The main challenge is to understand all processes, all data flows and all technologies, that are used in application. If you are in developing team, then it's a little bit easier – you can ask (or see, if you have admin privileges) some things, but it's still quite difficult to see and understand the whole picture of all processes.

Second challenge is motivation. Security bugs are not common ones, so you can spent a lot of time and effort (especially if you are a newer in this area) before you find some serious bug. As all bugs – not all security bugs are worth to fix. For example, if you can inject some SQL in admin component, which is being used only by one admin user, then probably project team doesn't want to spent time and money for fixing that (admin user can corrupt application and data anyway, event without SQL).
As a tester I am getting excited when I find bugs, not when I can see that application is pretty good. So for me browsing the application for 2 hours and not finding anything is quite boring. Which is bad for the project, I know, but I guess this is where the difference between tester and QA is.

The barrier to entry into security testing is quite high, however, the excitement of finding the security bug is also high. In my opinion, security bugs are the most important ones: better not to ship fully functioning but insecure software (especially if you have some payment system – even small possibility to loose money during transactions can be worse than delaying production).

And by security bugs I mean all bugs that violate one of the 3 characteristics:

• availability – does somebody using this bug can disable some services?
• integrity – does somebody can corrupt some part of the application?
• confidentiality – does somebody can get access to information which he doesn't suppose to get?

So I decided to write some steps, which every tester can perform to check basic security level of you application.

1. URL parameters
Study URLs of your application. URL with parameters looks like this: https://www.somedomain.com?lang=en&accId=10054366&name=irinaivanova, where lang, accId and name are parameters and en, 10054366 and irinaivanova are values.

Basically, three cases are possible here:

• URL contain some sensitive data, that can be stolen by third party. By sensitive data I mean password, legal code, telephone number. In our example, I would say that name=irinaivanova is sensitive data.
• You can modify values of parameters in URL to access some third party data. For example, if you have log in system and you give id of account or user in URL, then you can try to change that id for random number – likely you will get the access to other account without any password (and get his privileges). In out example we have parameter accId=10054366, which stands for account id. You can see what happens if you change the value: accId=1, accId=0, accId=10054365 etc (bonus tip: admin account with all privileges will likely have id 1, -1, 0 or 10000000, where number of zeros can be taken from your account id).
• You give info that is actually unnecessary. For example, such value as name you can take from database through account id. URL is not good place for spare info.

2. ID smart card authentication
In Estonia ID smart card authentication is very popular. If your application use this authentication you should test at least one case: log in with your ID card -> log out -> try to log in again in the same tab. I can bet that your application allows you to log in for second time and doesn't even ask the PIN code. This is actually browser plugin bug, not your application's, but it is possible to block second logging in without PIN code (for example, try to do same case in some internet bank page – you can't because they block second logging in in the same tab).

3. Cookies
If your application use cookies – you should test them.
Good article about cookies with simple test cases – Website Cookie Testing, Test cases for testing web application cookies?.

4. JavaScript injections
The simplest JavaScript injection is <script>alert('Vulnerability!');</script>. If you insert this script into field and process the form – you will get a dialog window with 'Vulnerability!' text in it, if your application has JavaScript vulnerability. Tip: it is more likely to execute JavaScript if you can save data in you application. For example, if you have field for name and can see this name in view mode, then try to insert script instead of name.
If you can execute such simple script that means that a bad guy can execute some more serious and harmful stuff.

5. SQL injections
Good article about SQL injections with examples – SQL Injection – How to Test Web Applications against SQL Injection Attacks.

6. Source code
Study source code in browser (mouse right click – View page source). Even if you can't understand the code you can note sensitive data, if there is one. For example, in the browser source code you can see JavaScript content, so your application should not contain data that you don't want to share in JavaScript variables.

Bonus: WTF character
There is such character as right-to-left mark. If you insert that then your further inserted text will be reversed right-to-left (it is used in Arabic languages). Beauty of this character is in his possibility to reverse the whole content of you page. For example, if users can insert comments on you page and somebody will insert this character, the whole you page will be mirrored and if you haven't heard about this character you will never know why! And it's really hard to find it in you database (to remove harmful comment).
I've already wrote post about it – WTF is this Character?



These are only first the easiest steps in security testing. I assume, that many testers have already heard about them, so I hope to write some more interesting and complex stuff as soon as I get smarter at this.