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:
nameare parameters and
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=irinaivanovais 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=10054365etc (bonus tip: admin account with all privileges will likely have id
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).
Good article about cookies with simple test cases – Website Cookie Testing, Test cases for testing web application cookies?.
If you can execute such simple script that means that a bad guy can execute some more serious and harmful staff.
5. SQL injections
Good article about SQL injections with examples – SQL Injection – How to Test Web Applications against SQL Injection Attacks.
6. Source code
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 staff as soon as I get smarter at this.