This week on our blog, we have a guest post from Nathan Britton, Principal Consultant at NTT Security. 

I recently attended an OWASP (Open Web Application Security Project) London Chapter meeting and listened to a bug bounty hunter present to the crowd. A bug bounty hunter is someone who actively seeks to find bugs in web applications, informs the application owners of the vulnerability and collects a nice little bounty for their trouble.

This particular researcher highlighted a number of different bugs he’d found but one in particular piqued my interest. He identified that a very well-known telecommunications company had a design flaw in the Profile Settings section of its web application which bypassed inbuilt security protections.

Specifically, when logged into the customer portal whenever the account holder wanted to change details in the Profile Settings section, for instance their mobile number, email address etc, it would force them to re-enter their account password as validation. However, the researcher found that, by inspecting the source HTML of the page, he could manipulate the validation form and remove the code that presented the password field to the user. What this meant was he was able to modify his profile settings without having to re-enter his account password, bypassing the security controls.

So how can other organizations prevent this type of threat from happening in their web applications? In a previous post, I explained the steps for developing more secure web apps – but there’s another effective tool, threat modeling, which our own application security team has been working to include in our services. It is a wide-ranging term, but simplistically it looks at an application, system or infrastructure and identifies where threats may occur and from whom. It could range from identifying a way of bypassing a security guard at a perimeter fence, to accessing a privileged area of an application without the proper authorization.

One aspect of threat modeling, and the reason why this particular flaw caught my attention, is the analysis of use and misuse cases. When designing an application, a developer maps out how a user will interact legitimately with the web application. For instance, what functions they will use, how they will access them and the flow of data as part of that interaction. These are use cases. Use cases should then generate security requirements to be designed and deployed.

Misuse or abuse cases are ways in which a malicious person could interact with the application illegitimately and requires developers to get into the mindset of a potential attacker. Misuse cases are another great way of introducing security requirements into a piece of code or application as it challenges existing security features and controls and ensures questions are asked about how they may be bypassed using non-standard means.

To assist with misuse cases, threat modeling offers a number of tools and techniques, one of which is the STRIDE approach (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege). Once use cases have been established, by using STRIDE, you can apply potential threats to each of them. For example – how do we prevent someone from pretending to be someone else (Spoofing) or threatening the integrity of the asset (Tampering)?

In this example, the developer had put in a mitigation technique to prevent spoofing by requiring the password to be re-entered, however, the threat of tampering was not factored in, hence the ability to compromise the integrity of the web page to bypass the inbuilt security controls. By thinking like an attacker, this flaw may have been identified at the design phase and had a security requirement built in.

Our recent NTT Security GTIC Threat Intelligence Report found that web application attacks had increased by over 40%. This shows that traditional reactive security controls are not keeping up with the fast paced nature of application development. Organizations should be looking at tools such as threat modeling, alongside security testing and other good security practices, as part of a wider application security programme to embed security throughout an application’s lifecycle. This way, flaws can be identified earlier in the lifecycle of an application and resolved in a more timely and cost effective manner. Only by encouraging organizations to shift their security to the left, will we potentially see the number of web application attacks decreasing in the future.