Hardening your webapp security

Hardening your webapp security - Top 5 tips from pentesters

The recent explosion of webapps has led to a dramatic rise in cyber attacks specifically targeting vulnerabilities in web applications. Three quarters of the web applications tested by Silent Breach presented high or critical vulnerabilities that could have led to a data breach, or even total compromise of the website: Fortunately, the most common vulnerabilities among web applications are quite predictable, and have been successfully mapped into the Top 10 Application Security Risk table (2017) by the OWASP non-profit organization.

However, while the issues can be clearly identified and classified, little has been done to describe the mitigation process. Here are the top 5 tips from our expert pentesters to close these vulnerabilities and harden your web application.

1) Sanitize all application inputs and outputs

Sanitizing all application inputs and outputs should be your number one priority. A successful website hack usually means that a user has abused your application in a way it wasn't designed for, thereby pushing the app beyond its limits. Forcing the application to deliver information that should have been kept secret constitutes the art of exploitation. This is only possible if user input allows an attacker to include special characters such as a semi-colon, for example, which holds a special meaning in most programming languages (instruction separation). By 'injecting' code into your web application input forms, a malicious payload can make its way to the database to extract information there (SQL injection) or surface back in another client's application in order to steal valuable information (Stored XSS attack).

Most programming languages already have libraries to assist with input sanitation, such as the Sanitize filters in PHP, or DOMPurify for Javascript. By filtering user input, as well as anything produced by your application (to block stored XSS attacks), you can address both A1-Injection and A7-Cross-Site Scripting (XSS) from the OWASP Top 10 table.

2) Review the configuration files of each module in your stack

Software components usually ship with a default configuration that simplifies deployment and testing. However, going to full production requires that you pay additional attention to these settings. Default configurations are dangerous because open source software is freely available to anybody, including hackers. Most opportunistic attacks typically target mis-configured systems by simply looking up default credentials or configurations of common frameworks. By playing the numbers, it's only a matter of time before they manage to find a vulnerable system somewhere on the web.

Nowadays, most software components are built with security in mind, and mechanisms do exist to harden their security. However, they need to be configured and tightly adjusted to your use case. By addressing these problems, you can often address A3-Sensitive Data Exposure and A6-Security Misconfiguration.

3) Practice code review on your security features

Code review is considered 'best practice' in most companies to catch programming errors. However, it can also be a powerful method for catching security vulnerabilities that can lead to poorly implemented authentication mechanisms for example, or inadequate access control.

APIs in particular should be well secured and reviewed by peers to make sure they don't allow more control than initially intended.

Another important security feature that is underestimated is application logging. Each security event should be logged so that traces for a given activity and user exist somewhere on the disk. Lack of proper logging can make the task of tracing down a hacker virtually impossible. In addition, code review should point out areas of the code that require additional traces. Also keep in mind that the logs produced can be useful when integrating with event and monitoring tools such as System Information and Event Management (SIEMs) or other security tools.

Careful code review can help catch most issues in the A2-Broken Authentication, A5 Broken Access Control, A8-Insecure Deserialization and A10-Insufficient Logging&Monitoring categories.

4) Keep your system up to date

As obvious as this may sound, keeping your system up to date with patches is critical for protecting your web application. The time window between the moment a vulnerability is found (i.e. the 0-day) and the moment a particular system is patched presents a vulnerability window that can be exploited by hackers who simply attack faster than your ability to defend. The sooner patches are deployed, the lower the likelihood that a vulnerability will be exploited on your system.

Keeping your system up to date with patches will help address A9-Using Components with Known Vulnerabilities

5) Check your security headers

Most websites typically manipulate cookies and frames, along with making AJAX requests to external or internal resources. But have you ever wondered if the mechanisms your webapp rely on are really secure? Use this great tool to check your security headers: https://securityheaders.com

Protected security headers will help you further address A2-Broken Authentication, A5 Broken Access Control, and A7-Cross-Site Scripting (XSS).

Conclusion

Follow these tips to harden your web application and make sure you adopt a pragmatic approach to security. It's usually considered best practice to perform a penetration test at least twice a year to make sure all of your security measures are implemented correctly. Nothing beats a reality check when it comes to security and whenever possible, these tests should occur in the QA environment, before rolling out the application to production.

Silent Breach can assist with your penetration test needs, and offers comprehensive packages for periodic tests, as well as detailed reports including snapshots, steps to reproduce, OWASP mapping and steps to remediation.

Please reach out to Silent Breach for more information.