Security Testing Fundamentals
Security Testing is a type of Software Testing that uncovers vulnerabilities of the system and decides that the data and resources of the system are shielded from possible intruders. It assures that the software system and application are free from any threats or risks that can cause a loss. Security testing of any system is focused on locating all potential loopholes and vulnerabilities of the system which might result in the loss of information or fame of the business. Learn Security Testing Fundamentals with us !!
The Objective of Security Testing:
- To recognize the threats in the system.
- To estimate the potential vulnerabilities of the system.
- To help in detecting every potential security hazards for the system.
- To help developers in fixing the security problems by coding.
Principle of Security Testing:
Below are the six basic principles of security testing:
Major Focus Areas in Security Testing:
- Network Security
- System Software Security
- Client-side Application Security
- Server-side Application Security
Types of Security Testing:
- Vulnerability Scanning:
Vulnerability scanning is performed with the help of automated software to scan a system to detect the known vulnerability patterns.
- Security Scanning:
Security scanning is the identification of network and system weaknesses. Later on it provides solutions for reducing these defects or risks. Security scanning can be carried out in both manual and automated way.
- Penetration Testing:
Penetration testing is the simulation of the attack from a malicious hacker. It includes analysis of a particular system to examine for potential vulnerabilities from a malicious hacker that attempts to hack the system.
- Risk Assessment:
In risk assessment testing security risks observed in the organization are analysed. Risks are classified into three categories i.e. low, medium and high. This testing endorses controls and measures to minimize the risk.
- Security Auditing:
Security auditing is an internal inspection of applications and operating systems for security defects. An audit can also be carried out via line by line checking of code.
- Ethical Hacking:
Ethical hacking is different from malicious hacking. The purpose of ethical hacking is to expose security flaws in the organization system.
- Posture Assessment:
It combines security scanning, ethical hacking and risk assessments to provide an overall security posture of an or organisation.
Managing Heuristic Exploratory Testing Based on MindMap
Web Application Security Testing Checklist
Step 1: Information Gathering
Ask the appropriate questions to properly plan and test the application at hand.
Discover highly problematic areas of the application.
This covers areas where users can add remodel, and/or delete content. These locations require verification on input sanitization and output encoding.
For example: Applications that allow users to enter large amounts of data such as blog posts, especially when done through HTML editors, are at high risk of injection attacks if proper prevention mechanism aren’t enforced.
Build business logic and data flow.
This covers areas that require manual testing specifically focused on bypassing, escalation , and sensitive data exposure techniques. Business logic flow can be defined as the data flow specific, and unique , to the application. This type of functionality is usually inspected with automated analysis.
For example: Functionality may include an approval workflow or privileged account access. A tester must ensure:
- Integrity of the workflow
- Users can’t bypass or skip steps
- Users can’t perform privileged activities without authorization
Request an understanding of the permissions/role structure. Gather two credentials for each.
This is required in case of lockouts and/or multiple team member access.
Step 2: Planning
Document your testing strategy to ensure each assessor knows what they’re working on and how much time they have to complete testing-related tasks.
Organize the types of vulnerabilities applicable for this type of application.
If the application implements authentication, the following checks are applicable (not exhaustive):
- Session management
- Brute forcing
- Privilege escalation
- Password complexity
Assign specific roles and credentials to each team member (if working as a team).
The application should be split among team members by functionality or vulnerability type, depending on expertise.
Determine the types of automated tests to be performed.
Assign an individual to configure and scan.
Establish the “stop testing” deadline at which point the team will document all vulnerabilities.
This is the point when you should write the report.
Set up status calls internally and externally.
Internal status calls should take places twice a week and include the testers and the project/client manager. External status calls should take place once a week and include the internal team and the customer(s). If possible, the project manger should walk through team status and then pass to team members for details.
Document specific test cases.
This should be done only when the client requests it.
Perform automated and/or manual crawling.
If required within the terms of the contract. This aids in the execution phase and provides details on scope if any adjustments need to be made.
Step 3: Execution
Conduct tests and discover vulnerabilities (in any exist).
Perform automated test and triage the results.
Automation tools should be carefully selected (cover common OWASP Top 10 vulnerabilities at a minimum). This allows testers to focus their skills on the business logic and data flow requiring manual analysis. Automated testing differs slightly per organization depending on what tools are licensed and/or internally built.
Perform manual tests.
Manual tests cover business logic and data overflow specific to the application that are typically overlooked by automation. A manual test may look like the following:
- A tester identifies a URL accessed by an admin that is slightly different from what they see: https://www.example.com/users/edit?id=123456&admin=false
- They modify the URL in an attempt to act as an admin https://www.example.com/users/edit?id=123456&admin=true
- Depending on the result, a vulnerability should be documented and the tester should navigate to similar pages to see if this issue is persistent.
Most tools send several requests to the same page to determine if the responses are different. Many tools state that a vulnerability exists when HTTP 500 errors are returned. It is the tester’s responsibility to review the request and the error message to determine if a vulnerability actually occurs.
Document and collect artifacts when vulnerabilities are discovered.
Clients may request an output of tests performed even if vulnerabilities aren’t identified.
Step 4: Reporting
Document results thoroughly and report to the client.
This should include descriptions, instances (affected URLs), roles, evidence, steps to reproduce, likelihood, impact, and remediation.
Conduct technical review of final reports.
This ensures that consistency, aesthetics, and technical writing remains intact.
Perform a “report out” call.
(If requested by client) Review the results and make any appropriate adjustments based on the conversation.
Step 5: Remediation
Address the vulnerabilities discovered during testing.
Address and follow the remediation guidelines in the report.
It is the application owner’s responsibility to task a developer with specific remediation task. It is important to apply fixes in all similar locations of the code. Black box test may not be exhaustive and similar issues could exist.
Step 6: Verification
Confirm that the vulnerabilities found during testing are resolved and ensure the fixes can’t be evaded.
Review the application again.
Look for specific previously identified issues.
Ensure the fixes prevent “transformed” attempts at the same vulnerability.
- Perform filter evasion techniques for XSS, attempt escalation attacks with different roles, and perform redirects to different URLs.
Linux Commands that can useful with Linux based testing
“Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.” – James Bach