Application security challenges lie not only in the threats and application vulnerabilities themselves, but also in the processes and approaches taken within the organization to manage application security. A closer look at some of the top application security challenges from both a threat standpoint and a business management view can help you avoid some of the most common pitfalls.

As more organizations take an agile approach to application development, new versions of apps are released quickly, making security not only more important, but also more challenging. It should come as no surprise then that spending on application security solutions is expected to reach $7.1 billion by 2023, as compared to $2.8 billion in 2017. 

Make sure you get the maximum benefit out of the money you invest in AppSec security by arming yourself with knowledge of the most common threats and internal missteps. 

Outside threats: The most common application security vulnerabilities

Injections 

The most recent State of Web Application Vulnerabilities in 2018 report found that the most common type of web application security challenges are injections, coming in at 19 percent of all vulnerabilities. Perhaps even more alarming, this represents a 267 percent increase from the previous year. 

The two most common types of injection vulnerabilities are: 

SQL Injections—This type of attack involves the insertion of a SQL query into the application so the attacker can read sensitive data from the database, modify database data, or perform other malicious activity. SQL Injection flaws make their way into applications when developers create dynamic database queries that include user-supplied input. 

That said, the best way to avoid SQL injection flaws is to stop writing dynamic queries. If that is not going to happen, you need to defend against (prevent) user-supplied input containing malicious SQL from impacting the logic of the executed query. Additional prevention tips are available from OWASP

Remote command execution (RCE)—RCE occurs when an attacker is able to add his or her own code to execute arbitrary commands. They may escalate their privileges on the server, insert malicious code, or worse. 

To protect your application: 

  • Avoid command line calls as much as possible. (Use APIs instead.) 
  • If you do use shell commands (commands the operating system will execute), make sure the input values do not contain malicious characters. 
  • Review code thoroughly. 
  • Run servers on restricted permissions, giving them access to only what they need.

Cross-site scripting 

Cross-site scripting (XSS) is the second-most-common web application vulnerability from 2018. XSS allows attackers to execute scripts in the visitor’s browser on behalf of a vulnerable website, unbeknownst to the user. 

They can be redirected to malicious sites or made subject to other malicious activity, such as having their cookies stolen. The key point to keep in mind to protect yourself against XSS is that it is easily identified with application security testing tools. So employing these tools as part of your security testing process is important.

Inherited vulnerabilities 

In an effort to remain agile, application developers often leverage application frameworks based on long-standing languages such as JavaScript. This allows developers to create and prototype applications quickly. 

But these frameworks often rely on numerous intertwined dependencies, and can pull in components from unknown sources across the Internet—opening the applications to threats. 

Developers tend to rely more on the popularity of a given JavaScript library to determine its security, making the false assumption that if a lot of developers are using it, then it must be secure. This is a flawed approach that makes your application vulnerable.

Proactive steps can be taken to prevent this type of attack: 

  • Pull in packages you want to use, and mirror them locally in your development environment, rather than pulling them directly from the internet every time you build. In other words, do not build and deploy from the internet. 
  • Use application vulnerability tools—specifically Software Composition Analysis (SCA) tools—to locate vulnerable packages in your local repository. For example, the OWASP Dependency Check tool is an open source application that can scan your code base for outdated libraries it may be using.

A look within: Internal application security challenges

Not using a variety of application security testing tools

If you are only depending on one or two tools for application security testing, you are leaving your application vulnerable. It takes more than a few tools to provide full coverage for your application. 

The best approach is to use a wide and blended range of testing tools, including Static Application Security Testing (SAST) tools, Dynamic Application Security Testing (DAST) tools, Interactive Application Security Testing (IAST) tools, and SCA tools. The best approach is one that combines manual testing and threat modeling.

Of course, managing all of these tools can become quite cumbersome and a challenge in itself. Fortunately, you can employ an application vulnerability manager to correlate the results and present them in one standard format. Some of these tools even cross-reference results from SAST and DAST tools, helping you identify which potential threats are actually exploitable (and the highest threat to your application).

Lack of progress tracking 

It’s one thing to identify threats and vulnerabilities, but if you don’t assign them out and make sure they are handled quickly, your application and business will suffer. An additional benefit of an application vulnerability manager is that it integrates with popular development environments and issue tracking tools, such as Eclipse and Jira. 

You can assign issues to developers within their preferred working environment and easily track progress to make sure problems are resolved right away. Some tools maintain well-understood metrics to help you track your progress. Make sure the tool you use gives you the information you need.

Pressure of speed 

Gartner recently pointed out the increased speed at which application development is happening. This speed trap often leads development teams down a path that places security on the sidelines. 

While this may get your product to market faster, it does so at a serious risk, as all it takes is one breach and you will lose the trust of current and future customers. Security must be baked into the design and development process from day one, so it remains a priority—even if it slows you down a bit. It is worth it.  

Failure to build the right team 

Application security goes beyond developers. It includes quality assurance, security analysis, executive buy-in, and an organizational commitment. A developer won’t make security a priority if they are pressured from management to deploy updates in an unreasonable amount of time. Leaders need to walk the walk and show their commitment to comprehensive application security.

Failure to develop a formal AppSec plan 

Application security cannot be accomplished on a whim. A formal plan must be in place, documenting the tools used and organizational standards around application security testing. 

The plan should be revisited annually to make sure it still meets the needs of your organization.  Record and measure results so you can see how your organization performs over time and tweak the policies as needed.

It may take a little extra time and effort to make sure you deploy a safe and secure application. With a little education and planning, you can take the necessary steps to avoid the most common application security vulnerabilities and make sure you take the right operational approach to AppSec. This initial investment has a big ROI when it comes to your reputation and success in the marketplace.