
In this article I will talk about modern methods and approaches to testing the security of web applications.
Begin research
Successful testing of web applications requires a systematic approach or methodology. The most famous are OWASP and WASC. They are the most complete and formalized methodologies to date.
Next, you need to determine the web application - for research you can take the latest version of one of the free CMS, and install the vulnerable plug-in (you can download the vulnerable versions from exploit-db.com).
')
Test methods
Since we are not web developers of this application, we will skip the testing phase when creating the architecture and developing the application (but it is worth noting that they are important when developing).
There are several testing principles that we can apply:
DAST is a dynamic (i.e. requiring execution) analysis of an application without access to the source code and the server part, in essence BlackBox.
SAST is a static (i.e. no execution required) analysis of an application with access to the source code of a web application and a web server, in fact, it is an analysis of the source code based on formal signs of vulnerabilities and a server security audit.
IAST - a dynamic analysis of the security of a web application, with full access to the source code, the web server - in essence is WhiteBox testing.
Source code analysis - static or dynamic analysis with access to the source code without access to the server environment.
These methods are fully suitable for training your skills in detecting vulnerabilities of a web application if you have access to a web application, or partly if you research a web application, for example, when you participate in the BugBounty program.
Main steps
For completeness testing, you should try to follow the recommendations below to customize certain steps depending on the web application.
Intelligence service
- Port scan.
- Scan subdomains.
- Examination of visible content.
- Search for hidden content (directories, files)
- Definition of platform and web environment.
- Definition of input forms.
Access control
- Verification of authentication and authorization.
- Definition of password policy requirements.
- Testing the selection of credentials.
- Testing account recovery.
- Testing session save functions.
- Testing account identification features.
- Authorization and access control.
- Session studies (lifetime, session tokens, signs, simultaneous attempts, etc.)
- CSRF check.
Parameter fuzzing
- Testing applications for various types of injections (SQL, SOAP, LDAP, XPATH, etc.)
- Testing applications for XSS vulnerabilities.
- Check HTTP headers.
- Check redirects and redirects.
- Check the execution of OS commands.
- Check local and remote includa.
- Check for the implementation of XML-entities.
- Test template-injection.
- Check the interaction of web sockets.
Checks the logic of the web application
- Testing the application logic on the client side.
- Testing for the so-called. “Race condition” - race condition.
- Data link testing.
- Testing the availability of information based on access rights or lack thereof.
- Check the possibility of duplication or separation of data.
Checking server environment
- Check server architecture.
- Search and identification of public vulnerabilities.
- Check server accounts (services and services).
- Determine server or component settings (SSL, etc.).
- Authorization check.
Total
Having a plan for testing the application, we can step by step explore all its components for the presence of certain vulnerabilities. Based on the web application, one or other items can be supplemented with specific for this application checks.
In the next article I will talk about a toolkit that is suitable for testing a web application for this checklist.