As a professional QA engineer it’s a part and parcel of one’s day to day life to test the limits of the application in terms of functional and non-functional requirements. This tutorial focuses on understanding and implementing security testing methodologies in your day to day testing so that the most common security threats and vulnerabilities are enumerated before the code goes in to production environment. We shall learn to use various tools which come in handy to perform basic security testing while performing regular duties with relation to testing.
The above cycle can be considered as the tester’s cycle for security testing. Being a part of the team, within the organization, gives plenty of opportunity to understand the feature and the environment. Hence, the information gathering part is not made exclusive in the cycle. After having enough information about the features and the environments, the tester must learn to focus on scanning through the features for the possible vulnerabilities which might arise based on the usage of third party software, style of coding, if the feature is heavily client facing, amount of user interaction to a particular feature etc. After scanning thoroughly for the vulnerabilities, the tester must enumerate the vulnerabilities in the order of severity and prioritize them in a consolidated list. Based on the severity and priority rating the tester moves in to the next phase, to determine if the existing vulnerability is actually exploitable. More often than not, the tester comes in to situations where he manages to find a vulnerability which is not actually exploitable. If the exploitability exists then, the amount of user interaction involved to cause any damage. These parameters help us determine the final severity and priority of fix for a bug. Then, we report the findings to a developer who developed that feature and help him with the possible solutions which he can code. In the freeze phase, we do a re-testing of the fix and make sure that the fix is ready for a code freeze and can safely move in to the production environment.
There is a paradigm shift from software applications to web based applications – thanks to cloud computing. There has been a rapid surge of developing quick web application code to meet the demands of the market. Web applications are different as compared to software applications. We need to understand the nature of a security bug. The security bug is a major combination of 3 major parameters – Attacker, Asset and Vulnerability. Finding the areas where security bugs majorly hide is an important key criterion in starting security testing. Let’s find out more about this in the following section.
In the above figure we see two ovals – As designed and As Implemented. The functional bugs are majorly found when the implementation lacks what the requirement specification whereas security bugs are majorly found when an implementation of a particular requirement does something extra other than what is required of it to carry out the operation. These include poor coding practices like improper input sanitization, non-verification of URL redirects, accepting URL requests without header checks, etc.
Security Frame to hunt for bugs:
|
|
|
|
|
|
|
|
- Error exception and handling
|
|
|
- User and Session management
|
This gives a brief checklist for finding the most common security vulnerabilities which lay in the code base. The list is not comprehensive but a good collection of parameters to begin with. We should always be prepared for new attacks which might not be covered in the security frame above. This is where the constant mental updates about the who’s who of security domain help.
Initiation to security testing through mnemonics:
Starting security testing initially might be challenging for folks who are not having the mindset of an attacker. For this we have some really helpful mnemonics which can help the initiation in to security testing. Let’s focus on them one at a time.
STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Escalation of Privileges.
STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the hacker). This helps in getting to learn as to how we can think and work our minds like an attacker.
Applying them in to your day-to-day testing:
ü Look at each function of the application
ü Identify bugs from the security frame
- Most common attacks under each bullet
- Revisit stride and hunt for potentially new bugs
For example: Sign-up for a new account à Authenticate à S.T.R.I.D.E
Be aware of the bugs which were lodged in the past. There is high possibility for those bugs to be present in and around the fix. This will also give a thorough understanding of the type of the bug under observation, its behavior and the fix that was applied.
DREAD: Damage, Reproducibility, Exploitability Affected users, Discoverability
DREAD is a classification scheme which can be used to prioritize each security bug based on the above parameters. The calculation for DREAD is as follows:
ü Each parameter has a value from 0-10.
ü 0 is the lowest and 10 is the highest degree of damage.
ü Calculating DREAD factor is pretty simple – (D+R+E+A+D)/5
- The value is always between 0-10
Higher the DREAD value, Higher is the severity and priority to fix
