Web App Security Training - Should You Take One?

There are tons of statistics about cyber security out there. The ones that I see most often agree that the security market is growing, with high demand for security engineers, and increase in their salaries. Apart from that, according to securityheaders.com around 46% out of scanned websites were assigned with the F grade for their security related HTTP headers. Recently, when I got a chance to participate in web app security training, I decided to do so. Let me share some knowledge and thoughts here.

Being a hacker

During the first part of the training, we had the opportunity to play the role of hackers. We picked a domain, and started with DNS reconnaissance. This technique is used to collect information about:

• the target domain’s DNS records,
• related IP addresses,
• subdomains,
• mail servers.

That information allows us to inspect the network infrastructure and look for potential vulnerabilities. We often found subdomains of test servers. I’ve already seen projects where test environments were running with a clone of the production database, and usually, such environments don't have production-like observability, developers' attention, and security. There are lots of tools for such reconnaissance, like dnsrecon for example. After selecting a server, as a hacker, you will scan it, to quickly find common vulnerabilities, misconfigurations, or outdated software. There are lots of tools for that as well, one of them being nikto. It’s a simple server scanner, but a good starting point. We also deep-dived into the zaproxy scanner, which is much more powerful, commonly used by pentesters.

Having those tools in our belt, we were given a host of test applications, the goal of which was to find vulnerabilities and use them. We managed to find a way to perform a Cross Site Scripting (XSS) attack on the website, by injecting JS script in one of the application URLs. Imagine a real-world app with such vulnerability - combined with social engineering, such malicious URLs could be sent to application users in the form of shortened URLs, most likely someone would open them. We also found a way to inject SQL into the application’s database.

Learning web app security through such practices is more valuable than just reading about them, at least for me. There are projects that enable you to do so like natas where on each level you need to hack the server by finding some vulnerability to get credentials for the next level. There are 33 levels and I can tell you it gets pretty hard from level 7 (for a beginner as myself).

Being a dev

The second part of the training focused more on a developer's perspective, which was my primary interest. How to handle software security during the design process? What are some good practices and security knowledge bases?

Design process

When delivering new web services, technical discussions often center around databases and frameworks. While these are all important, security is often overlooked in the process. But how should we “design” it? We’ve been given a step by step approach called threat modeling. The process can be described with the following questions:

• What are we building?
• What can go wrong (security wise)?
• What can we do about it?
• Is this enough?

Having those questions, the design discussion can iterate over questions 3 and 4 until reaching the answer “yes, this is enough” or unless a solution can no longer be challenged by us. Additionally, we should design with the attacker's profile in mind. For example, hacker groups are very technical, but there are also ex-employess, opportunists, even regular users.

Imagine that we are designing a login functionality on our website. What is the threat from regular users, what can possibly go wrong? Well, people like simple, reusable passwords - they can be cracked with brute force methods. What can we do about it? Enforce password policy. Is this enough? Probably yes. Let’s go further. Assume user credentials leaked. What can we do about it? We can enforce 2FA to prevent unauthorized access. Again, is this enough? The answer probably depends on the type of product you are working on, but I hope you get the idea.

Let’s try to think of some threats from opportunists. Such persons are looking for personal gains and benefits, they will try to cheat in order to get something for themselves but not necessarily hurt your business. What can go wrong? Opportunists may try to login to an existing user account to get access to some resources. What can we do about it? We can monitor suspicious activity, based on things like User-Agent header values, request origin location or number of attempts. We can inform users about such activity.

What about real hackers? They can intercept traffic to our website and try to read user credentials. We can use TLS for connection encryption. Is this enough? Well, our users may still access the site over insecure HTTP connection, which will be followed by a server redirect, and there we are vulnerable to man-in-the-middle attacks. Let’s ask again, what can we do about it? We can use the HTTP Strict Transport Security (HSTS) header in our server responses. This tells browsers to enforce HTTPS connections to our domain (for some period of time) and that mitigates the risk.

We practiced similar examples during the training and there are plenty of considerations for each attacker profile. It’s, of course important, to stay sane and design against the probable threats. The security level of services from critical infrastructure like banks and online government services will differ from a static web page service setup. However lots of security benefits can be gained with simple things like proper usage of security related HTTP headers.

Good practices

Lets look at some good practices from the developers standpoint. When multiple teams are building different services, it becomes harder to enforce and maintain some standards and in that case referential architectures can help. They could be as simple as a microservice template with proper security-related server settings, or more complex architectures including several components. If kept up to date with the latest practices and standards, they can remove some burden from the developers.

Reducing the attack surface is another concept that’s worth mentioning here. It’s about minimizing the number of potential entry points for attackers. The simplest example could be removing unused endpoints from our API. In a cloud environment it could be restricting access to management interfaces like SSH, or running services like databases in private subnets, with no direct access to the internet.

For devs OWASP is probably one of the best knowledge bases out there. You will find many resources on the project web site, however, a quick start could be to look at their recommendations for HTTP headers called “Secure Headers Project”. I’d say that headers are the low-hanging fruit for improving your app security. Another one is MITRE, with its cybersecurity defences & attacks strategies with detailed descriptions of each action.

There are also good practices for day to day development. One of them is to pay attention to default configurations of components you are using. Often default configurations are only good for local development. For example, MongoDB in its few initial major versions had authentication disabled by default. Attackers exploited this misconfiguration, targeting publicly exposed MongoDB instances, stealing its data, and demanding ransom payments in exchange for data recovery.

Another simple thing that enhances security is the validation and sanitization of data in our APIs. Your frontend forms might have validations, but that should be treated as purely UX, as those can be easily disabled. Anything that comes into your API should be treated as potentially dangerous. Validation and sanitization will safeguard you from attacks like SQL injection. Also think about what your API is returning in case of errors (also those unexpected). Web scanners will try to break your API, either with malformed input or load. The error messages can give attackers information about libraries you use, databases, or injection possibilities. Error handling is crucial here, and the more generic your API errors and response codes are, the better. Your clients and business might not like what I’m saying here, so you might need to balance this.

Summary

We all agree that security is important, but we don’t need to become experts in it. There are guidelines created by experts that we can follow, which combined with some good practices, will probably give our services a good security grade. The training took 2 days, and I am sharing just a little portion of the knowledge that I found particularly interesting. The training was conducted by our technical partner Niebezpiecznik, a Polish based cybersecurity company. Thanks for reading!

Reviewed by: Krzysztof Ciesielski