Web Application Security Testing: 18 Points Checklist
Web application security is a very important topic in the world of information technology. With an ever-growing number of web applications, hackers are finding new ways to exploit them and steal sensitive data. The best defense against these attacks is to perform thorough testing before releasing your website or app into production. This checklist will help you create a plan for how to test your web application for vulnerabilities that could lead to hacking attempts.
Here we go:
1) Check for a Secure Web Application Firewall (WAF)
Use a WAF to scan your website for vulnerabilities. If you find any issues with its configuration or setup, make sure they’re fixed before moving on. WAFs are designed to filter traffic and prevent certain attacks from reaching the webserver. If you have one, it’s important that they’re configured correctly so that suspicious requests don’t get through.
2) Use an Automated Vulnerability Scanner
Look for the vulnerabilities that the WAF might be missing by scanning your application with an automated web application security scanner. These tools are great because they’re able to find more than just one type of issue at a time and can scale with your website or app as it grows over time.
3) Enumerate all exposed paths/pages
Ensure there aren’t any pages or directories on your website exposed to users which should not be publicly accessible like admin panels or test suites. This is also known as “lack of authorization” in OWASP terminology.
4) Perform Input Validation
Make sure user input is validated before using it anywhere in an SQL query, HTML output, or anywhere it could be executed. You can use a whitelist approach to ensure input matches an allowed set of characters, or you can use the OWASP ESAPI Validation API to validate inputs against a list of rules specific for your application’s needs.
5) Ensure function level access control
Make sure that sensitive functions are only accessible when they need to be by authorized users and not through public-facing pages which would allow anyone access. This is also known as “lack of authorization” in OWASP terminology.
6) Do Application Security Code Reviews
A code review with another developer often reveals security bugs that may have been overlooked during development due to time constraints or a lack of application security knowledge.
7) Perform Static Code Analysis
This is the process of running an automated tool over your source code to identify potential security vulnerabilities or bad design patterns which could lead to low-level attacks like SQL injection and cross-site scripting.
8) Harden Configuration Settings
Make sure any production server has been configured with a secure baseline so that additional services added later on will not introduce new points of weakness in the system. Also, make sure software components are always kept up to date with the latest hotfixes and patches as soon as they’re available for installation by users without administrative access (e.g., via package manager).
9) Harden Network Services
Ensure services like SSH, FTP, and SMTP are only accessible by the intended users on either an internal network or over VPN connections. If you’re using a cloud computing provider then it’s important that your connection to their servers is encrypted with strong encryption protocols (e.g.IPSEC).
10) Keep web server software up to date
This includes both OS packages as well as any applications running on top of them such as Apache, Nginx, PHP etc. You can use package managers for this purpose which will ensure all dependencies including those required for any plugins/modules installed have been updated with the latest patches from upstream developers within reasonable timeframes after they’ve been made available online.
11) Disable Unnecessary Services
Any services not being used should be turned off or removed from the system. In some cases, disabling a service is all that’s required to fix a security bug but other times you may need to install additional packages/services for this purpose which will depend on your chosen OS and development environment of choice e.g., Debian based systems often have older versions included in their default distributions whereas more modern ones like Ubuntu are kept up to date by users with administrative access (e.g., via the package manager).
12) Keep software updated
Make sure any installed applications including those running as web servers or database engines are kept up to date with the latest patches released after installation before moving it to a production environment. This will help avoid potential vulnerabilities which have been patched and prevent servers from being compromised through zero-day bugs in unpatched old software versions.
13) Run network monitoring tools
You should always be running some sort of intrusion detection system (IDS) or intrusion prevention system (IPS). For example, snort is an open-source alternative with many active contributors as opposed to other proprietary IDS/IPS alternatives such as Sourcefire’s FireAMP product line.
14) Perform Security Testing at all stages
It doesn’t matter if you’re security testing your application only during the development stage before moving into QA or after it has already gone live and there are users actively using it. You should always be looking for vulnerabilities that could potentially lead to data breaches or unauthorized access of any kind, whether the application is publicly available on the Internet or used by staff members internally on an Intranet network behind a demilitarized zone (DMZ) firewall.
15) Regularly Test Log Files
Ensure your web server’s error log files are regularly monitored and checked for signs of automated tools like scanners performing vulnerability scans against known exploits as well as other suspicious activity occurring over longer periods of time e.g., password brute-forcing attempts resulting in remote code executions due to weak passwords/configurations found within the system allowing attackers remote shell access into compromised systems.
16) Segmentation
You should always look to segment your web application from the rest of your system by placing it on a separate network where possible. For example, if you have a DMZ between an Internet-facing frontend and private network behind this then place all web applications in this demilitarized zone where they can be monitored separately via IDS/IPS devices which will help prevent attackers from gaining access to sensitive data stored within backend databases or file systems used for storing user credentials, password hashes etc.
17) Penetration Testing
If you don’t want to run security tests against your own infrastructure during development stages before going live but instead would prefer having them carried out externally with full permission beforehand so there are no false positives/negatives for identified vulnerabilities, then you can always hire a third-party penetration tester to perform tests against your infrastructure. This is usually the most cost-effective approach as long as they are able to provide references or recommendations before signing on contract with them. The testing may involve Whitebox, Gray-box and Blackbox penetration testing.
18) Additional Steps
There are also several other steps that should be followed during security testing of web applications such as checking all files uploaded by users e.g., images and PDFs for malicious code within these document types, looking at how cookies are being used, ensuring session management tokens aren’t being stored in URLs etc.
Summing Up..
This web application security testing checklist is a good starting point for any company that has not taken the time to review its applications and determine where they may be vulnerable. It’s also useful as an easy refresher if you’ve been doing this work a while but want to ensure that your team is following best practices. You can use these checklist points as part of your regular business process, or run them through periods when there are new updates made to the software, infrastructure changes, etc.
