What follows in the article is a brief overview of a OWASP Top 10 2017 vulnerability – A7-Insufficient Attack Protection.
This post is useful for beginners who want to understand about Insufficient Attack Protection and for developers to help protect their applications against this vulnerability.
Whenever a user with malicious intention visits any application, his first motive is to damage the application or to create a sense of panic among the application’s admins or users who are using the application.
It is natural behaviour for most attackers targeting an application to perform extensive research about the application, its services and categories of users accessing the application. The research usually starts with an ‘information gathering’ phase which includes collecting information about the application stack and usernames that are available to any random user who has access to the application, in addition to observing contact-us forms’ structures.
Once the attackers have enough information about the application, they try to start with their attacks on the application.
Let us consider an application for example – a blog wherein a user can view all comments from the application’s other users regarding the application and how they have used the application’s facilities. Taking advantage of these comments, an attacker can gather all the users’ usernames and try to login to the application with those usernames, trying multiple combinations from a set of predefined passwords which are easily available online.
Attack Scenario 1:
If the application has insufficient attack protection vulnerability, attackers can take the advantage of this to initiate a brute force attack on the login page. The attackers usually collect all the usernames that are available in the application in a text file, say usernames.txt.
Default passwords lists are available online, attackers can collect and save them as another file, say passwords.txt. Brute force attacks can then be initiated using the two text files.
Bruteforcing, in simple terms is entering predefined values into the username/password fields and observing their responses.
If the attackers successfully access any user account (irrespective of role) using brute force technique then it may result in the rise of a new vulnerability called Account Takeover.
Attack Scenario 2:
If the contact us forms or the support forms in any application do not have sufficient attack protection, then an attacker can use automated tools to send numerous fake submissions to the application which may result in the fill up of the application admin’s inbox with dummy e-mails.
To prevent attacks associated with both the cases, application developers have to implement captcha on the login forms as well as on the contact/support forms.
Researched by Jos Rohill