Secure your applications to avoid over 43% of breaches
Did you know the primary applications used by most businesses are web applications (i.e. websites)? Attacks against web applications are attacks on the application layer. Verizon’s 2020 data breach report suggests web applications were involved in 43% of known breaches. Statistics cannot be used to account for unknown breaches and there are other applications that can be used in a breach. This means that application-layer attacks likely account for at least 43% of breaches.
Common application layer attacks
Authentication – Applications normally implement some form of authentication that allows users to access resources and functions that others are not allowed to. Authentication occurs when a user is required to provide information to verify that they are allowed to access the resources requested. Vulnerabilities surrounding this are concerned with weaknesses in password policy, user accounts, and credentials on the system. Attackers will try to find weaknesses that allow them to obtain credentials without asking a user to provide them.
Authorisation – Where there are login credentials, there are mechanisms to enable this to be possible. This is typically in a login page/form where a user inputs credentials to send to the server to be authorised access. Attackers will try to exploit these mechanisms to steal passwords, bypass login mechanisms, or perform functions they should have no access to.
Input Validation – The most common vulnerability type found when testing applications is input validation. This is a potential risk whenever users can input data that the application processes such as SQLi, XSS, and Command Execution. Due to the vulnerabilities that can occur, vulnerabilities in input validation are more likely to be high or critical when compared to other categories.
Application Logic – Furthermore, vulnerabilities can sometimes be found in the applications logic that can involve subversion of parameters or workflows. Application logic vulnerabilities can also be in the form of denial of service vulnerabilities. Specific examples of these involve but are not limited to HTTP(S) flooding and slowloris.
Server Config – The application’s configuration on servers can also raise risks where configuration can reveal sensitive information or expose the application to additional vulnerabilities due to poor configuration or the inclusion of resources that are vulnerable. Most vulnerabilities reveal sensitive information, however, vulnerabilities in the application’s software or the third-party software can have severe consequences.
So why are these so dangerous?
There is a big variety of different vulnerabilities that can affect an application. This makes it hard to be aware of and mitigate all risks 100%. The bigger the application, the more areas that are likely to contain a vulnerability that an attacker can exploit. Due to this, it is not uncommon for applications to have multiple exploitable vulnerabilities which all add to the overall security risk of the application.
Another aspect that makes application-layer attacks dangerous is the potential damage they can cause. In the worst cases, in 20% of all vulnerabilities found, vulnerabilities can gain complete control over a system and could lead to a complete network compromise. An attacker with this level of permissions puts you in a very vulnerable position where they choose what happens and you will likely not know until it’s too late.
With the variety and damage potential that an attack could cause, the last thing to be aware of is an attacker only needs to succeed once for a breach to occur, but you need to succeed 100% of the time to prevent a breach occurring. This becomes very difficult when trying to protect against all types of threats simultaneously. And this becomes even scarier when you know that 55% of application-layer attacks on web applications take more than 30 days to fix once vulnerabilities are found.
Is there any hope for us?
All hope is not lost. There are ways to protect your organisation that limit the risk from application-layer attacks. The first and simplest of these is to keep all your applications up to date. Most vulnerabilities from the software you did not code can be fixed by updating the software. Without this, you are exposing your business to risks that could be mitigated.
One of the problems with mitigating attacks is how to know what attacks need mitigating. The best solution to this is by getting the application security testing to find these risks before an attacker is able to exploit them. This means testing the application before it is made public or used in production environments, to reduce the opportunities an attacker has to exploit current weaknesses.
Since the biggest threat usually comes from a form of validation of input, the next advice I would give is to validate and sanitize ALL inputs that a user can access/manipulate. This should be highlighted in the penetration test, but when features are added, this is the biggest area of concern and should be dealt with accordingly.
The choice is yours!
We have covered types of application-layer attacks in a broad sense to give you an idea of how varied they can be. This also led to the reasons why these attacks can be dangerous and what you can do to mitigate them.
Now it is up to you to do what you can to protect your business and your assets. Your applications can make you money, but without proper care, can cost you even more. Security testing is an investment in your long-term profit, so invest what you can to ensure it goes up.
Risk-Driven Application Security Testing
Risk Crew offers a Risk-Driven Application Security Testing Service that is comprised of four critical activities: first identifying the applications’ design flaws, then risks to the assets it processes followed by identifying its attack surface and then customising a security penetration test based on the flaws, risks, and attack vectors specifically associated with the application.