Application Attacks

Application development is burgeoning with the adoption of Agile and DevOps. As a result, cyber criminals recognize the application attack surface is expanding, and they are exploiting application security vulnerabilities. Applications are attractive targets because of the increasing amount of vulnerabilities left behind by legacy application security tools.

Modern developers in technology companies indicate that the average application has more than 10 vulnerabilities. Cyber criminals know these vulnerabilities are common, and they constantly probe to identify application vulnerabilities; research shows the average application in production received over 13,000 attacks each month over the past year. Application security risks and successful application attacks can impact businesses in multiple ways—from disrupting operations, to critical data theft and ransom, to brand degradation.

What is an application attack?

An application attack consists of cyber criminals gaining access to unauthorized areas. Attackers most commonly start with a look at the application layer, hunting for application vulnerabilities written within code. Though attacks target certain programming languages more than others, a wide range of applications representing various languages receive attacks: .NET, Ruby, Java, Node.js, Python, and many more. Vulnerabilities are found in both custom code and open-source frameworks and libraries.

How attacks exploit application security vulnerabilities

Application vulnerabilities create opportunities for cyber criminals to exploit applications in production. These exploits target both custom code and open-source frameworks and libraries. Some of the methods cyber criminals employ include:

Attacks due to application security vulnerabilities written into code

85% of developers revealed that the average application has 10 or more vulnerabilities. There are a number of reasons this application security risk is so great, starting with the fact that developers are under increasing pressure to shorten release cycles. Legacy application security tools are inaccurate and generate piles of false positives that waste valuable time on the part of security teams—in triage and diagnosis. When vulnerabilities are not identified and remediated, bad actors use probes and targeted attacks to pinpoint and exploit them—often with deleterious consequences.    

Attacks due to vulnerabilities from outdated certificates

Applications are able to communicate and transfer data through application programming interfaces (APIs). With data constantly on the move, the security risk of interception of data in transit by a bad actor increases. Using secure sockets layer (SSL) code, data is encrypted into an unreadable form, making it more secure as it travels from application to application. However, SSL code certificates do not last forever, needing an update at least every two years to avoid expiration. If the SSL certificate expires, application communication can no longer take place over secured HTTPS connections and data moves across APIs in plaintext. Attackers can exploit this vulnerability by intercepting data in plaintext via a number of advanced application attacks.

Attacks due to vulnerabilities from lack of authentications

Authentications secure applications by creating boundaries. The stronger the authentications, the less application security risk, hence the more secure applications will be. Those with weak security or lack of additional security measures are a common target for application attacks. For example, two-factor authentication adds an extra step to the process of logging in. Users can only gain access with the use of a secondary device or account that matches. This is not an industry standard, with only some applications adding this extra step in their application security measures. If attackers can easily break access and gain entry with a one-step authentication, user credentials and application infrastructures are at risk.

Another common target for cyber criminals is session IDs. They are responsible for communications between the user and the application. Session IDs make the use of applications convenient for users as they store credentials that lead to faster logins. Improper management of session IDs allows authentications to extend past login—increasing the probability of an application attack. In addition, session IDs could be highly predictable, thus making them vulnerable to attacks like brute force where attackers guess user credentials until they gain access. When it comes to application security, organizations must maintain strong session IDs, as well as regularly change and update them to prevent malicious HTTP requests.

Most common web application attacks

85% of developers indicate that an average internet / web application has more than 10 vulnerabilities when pushed to production. Attackers know that increased pressure to release applications means increased chances for mistakes written in code. It is an ongoing battle between cybersecurity professionals and cyber criminals. Each side is constantly trying to catch up to the other, with attackers always trying to get a step up from today’s legacy application security measures. Application attacks are evolving at a faster pace than application security measures. Some of the most common internet / web application attacks include:

Cross-site scripting (XSS) attack

A cross-site scripting (XSS) attack is on the OWASP Top 10 as one of the most common application attacks around today. Attackers execute this type of attack by searching for a vulnerability that allows them to access core code, most often creating a corrupted link and sending it via email or text message. If this application vulnerability is exploited, cyber criminals can inject malicious code on the client side, taking control over HTTP requests. With control over HTTP executions, cyber criminals have little to no limits in accessing personally identifiable information (PII)—including banking details, Social Security numbers, and even highly sensitive government information.

SQL injection attack

Of all applications with vulnerabilities, 65% of them experienced an SQL injection attack. SQL statements are used within applications and network communications, permitting access through authorizations and authentications. When a bad actor obtains SQL statements and tampers with them, they can manipulate applications into executing corrupted commands that allow them to ultimately gain access to otherwise unauthorized areas. With access to core code and manipulation of communications between other web applications, cyber criminals have the entire software environment at their disposal—able to evade security checks and protocols and and be left to roam around undetected until it is too late.

Broken access control attacks

Applications are often constructed with borders that users cannot cross. On one side rests the infrastructures and inner workings of an application, allowing only administrative teams access to make changes to structures. On the other side is the application front end—accessible to authenticated users. When the borders are broken and users are able to access administrative areas, it is known as a broken access control attack. Broken access control attacks rank No. 3 in the OWASP Top 10, taking place often and leaving user credentials and the entire application infrastructure at risk.

Path traversal attacks

A path traversal (or directory traversal) attack is an application attack that targets the root directory of an application. Normally a result of a manipulated dot-slash sequence, path traversal attacks trick applications into allowing access into server files where all of the information within a system rests. Accessed data can include user credentials, access tokens, and even entire system backups that hold everything from sensitive data to system access controls.

Session hijacking attacks

A session hijacking attack tampers with session IDs. This unique ID is used to label a user’s time online, keeping track of all activity for faster and more efficient future logins. Depending on the strength of the session ID, attackers could capture and manipulate the session ID, launching a session hijacking attack. If successful, attackers will have access to all information passed through the server for that particular session, getting ahold of user credentials to access personal accounts.

Implications of application attacks

In the 2020 Cost of a Data Breach Report released by IBM and Ponemon Institute, the average cost of a data breach was pegged at $3.86 million. When an application is attacked, every single user that is signed up and has an account is at risk of sensitive data exposure. The capturing of sensitive details leads to loss of confidence in a brand, tainting them long after the problem is patched and they are back in business. Take Yahoo! for example. They experienced three substantial, and almost consecutive attacks—affecting a total of 1 billion user accounts after all was said and done.

Though the Yahoo! data breach was serious, most user accounts had no financial information; the breach largely consisted of emails, dates of birth, and addresses. This was not the case when Equifax experienced a cyberattack, which resulted in the theft of millions of PII. This 2017 attack was able to go unnoticed longer than the company initially admitted, taking advantage of a vulnerability. Using malicious code injection, bad actors were able to pass administrative boundaries and allow corrupted requests. They targeted a specific vulnerability in the Apache Struts framework, which mishandled files and allowed hackers to run code remotely. Because of an outdated certificate of encryption, attackers were able to obtain millions of Social Security numbers and names, all in plaintext form.

Beyond having a detrimental brand impact, application attacks can disrupt operations. Application downtime translates into lost productivity and even lost revenue. It also can impact the loyalty of existing customers

Defending against web application attacks

Because of the impact that both companies and users can experience due to an application attack, securing applications in development and deployment and protecting web applications them once they are in production is crucial.

Web application security in development

Historically, application security steps occurred at the end of the development waterfall process before deployment. Dedicated application security specialists would identify application vulnerabilities using penetration testing. However, there are numerous problems with penetration testing. First, it was designed for waterfall development processes where only a handful—typically one or two—deployments took place per year. With the majority of organizations now embracing Agile and DevOps practices and releasing code as often as multiple times per day, penetration testing simply will not scale. Second, because penetration testing occurs at the end of the development process, fixing vulnerabilities is immensely more time-consuming and costly. Finally, penetration testing requires specialized application security professionals and skill sets that are hard to find and difficult to retain.

A second approach used in application development to identify vulnerabilities is through legacy vulnerability scanning tools. There are two types of legacy approaches here. Static application security testing (SAST) analyzes an application’s source code early in the software development life cycle (SDLC) for vulnerabilities. Dynamic application security testing (DAST) is designed to find vulnerabilities during an application’s running state.

Legacy application security scanning is problematic on multiple fronts. First, legacy static scanning identifies every possible vulnerability and packages them into a PDF report. But many of the purported vulnerabilities in those reports are false positives. Development and security teams expend significant time and resources triaging and diagnosing alerts that pose no threat. Second, similar to penetration testing, legacy static scanning requires specialized application security experts who are hard to find and retain. Legacy dynamic scanning has its downsides as well. First, DAST relies heavily on application security experts to write tests. Second, it is difficult to scale as organizations add more applications in development. Third, false negatives (missed vulnerabilities) are inherently going to occur due to the nature of legacy dynamic scanning.

Rather than approaching application security from the outside in, growing numbers of organizations are doing so from the inside out. Using interactive application security testing (IAST), developers can get a real-time, accurate look at triggered vulnerabilities in development and beyond. With instrumentation, organizations are able to shift applications left in development and detect vulnerabilities during runtime. This virtually eliminates false positives by pinpointing only vulnerabilities that can be exploited. And because instrumentation is within software, it is easier to integrate application security within IDE processes and continuous integration/continuous deployment (CI/CD) pipelines.

Application protection in production

For a couple decades, perimeter defenses have been used to protect against web application attacks. Web application firewalls (WAFs) protect the application perimeter from the outside in, compiling a list of security alerts that are compiled in a PDF format. However, the list of alerts is often full of false positives that require valuable time and energy to triage and diagnose. The same issues with false positives in development apply here, though the security operations (SecOps) team is typically the one most impacted in production environments.

Unlike WAFs, runtime application self-protection (RASP) is quick to deploy and takes little to no time to manage. Using instrumentation to embed RASP within an application's source code, security teams have a continuous monitor that sits inside of the application. Its accuracy is far more advanced than legacy application tools, taking some of the pressure off of stressed-out development teams. Because RASP is hooked into runtime, it provides swift detection of vulnerabilities and diagnoses and triages long before an application attack can exploit them.