The threat landscape is evolving quickly. Application security is working to keep pace with the ever-evolving threat landscape. As the application development process becomes more incremental, with developers embracing frameworks such as Agile and DevSecOps, it is becoming more important for developers to pay attention to application security trends, know what they can do better in their own work, and become the first line of defense against application security attacks.
Why Focus on Application Security?
Application security has been important as long as devices have been connected. However, some major events in 2021 have led to a renewed focus on application security vulnerabilities for 2022
SolarWinds
In late 2020, the SolarWinds compromise came to light, and into early 2021 details were still being gathered. Throughout the year, it remained on the minds of security experts all over the world. As more details became known, what emerged was a picture of a compromised build process that allowed attackers to inject malicious code into the Orion network monitoring software, after which SolarWinds pushed malicious updates to customers. This underscores the need for securing every step of the software build process, and for embracing software security measures that can keep up with incremental development.
Log4j
In December 2021 a critical Log4j bug was announced. Exploiting that bug, found in a widely used Apache logging library, could lead to remote code execution on Java-based web servers. Though the vulnerability has not had the cataclysmic effect that some people thought it would, it is still being actively exploited into 2022, especially by cryptocurrency mining gangs and ransomware gangs, as well as some distributed denial of service (DDoS) activity. Having visibility into what open source libraries are in use in your applications is key to understanding risk and impact of vulnerabilities like this.
Moving Forward
Though these are some of the major signposts, there were many smaller-scale application security vulnerabilities and attacks that were destructive as well. In light of these elements, it is safe to say that applications are an attack vector that malicious actors love, and a clearer focus on security is necessary.
Even experienced developers realize they need more training on security: according to a recent VMWare/Forrester study, only about a third of developers believe they are thoroughly educated on the secure development processes expected of them. It is time to start bridging this gap.
Key Vulnerabilities
For developers trying to improve their knowledge, a good first step is to become familiar with application security vulnerabilities that are both common and impactful. This will enable developers to understand how to identify and respond to these issues during the development process, improve existing code to resist current attacks, and write more secure code in the future. This list of current important vulnerabilities is based both on the latest updated version of the OWASP Top 10, an industry-recognized consensus of the most critical security vulnerabilities in web applications, as well as ShiftLeft’s own observations of what software vulnerabilities are detected most often in real-world scans.
Injection
Injection vulnerabilities remain near the top of the OWASP Top 10. They are also the most common category of vulnerabilities found by ShiftLeft in the real world, including subcategories like cross-site scripting (XSS), SQL injection, and mail injection. Though they are a category of vulnerabilities that has long been understood, they are still easy enough to introduce to software that they remain a problem.
At their heart, injection vulnerabilities come down to poor input validation, filtering, or sanitizing. An application accepts input, and an attacker discovers that the input can be crafted in such a way that it can run commands. Those commands are often either JavaScript, in the case of XSS, database manipulations or queries, in the case of SQL injection, or SMTP parameters, in the case of mail injection. However, they can also be other kinds of code such as OS commands, LDAP commands, or other commands. This can result in remote control of the server, or access to underlying application data, like user information.
No matter what kind of injection vulnerabilities you are dealing with, preventing them comes down to validating input and keeping untrusted input away from being run:
- XSS: Use JSON URLs instead of JavaScript files to interpolate sensitive data, since they are subject to the same-origin policy. Add a Content-Security-Policy header to HTTP responses if tags are used, since otherwise they accept cross-site scripts.
- SQL Injection: Use safe APIs, construct parameterized queries against the databases, and follow the principle of least privilege for all database accounts.
- Mail Injection: Ensure that email content is constructed completely on the server side, and that untrusted parameters are not used to construct messages. Require authentication or a CAPTCHA before sending mail to a new address. Validate all email addresses, checking for characters such as newlines that may indicate the addition of untrusted headers. And, when creating messages to users, consider using a separate transactional email service instead of rolling your own mailer for your web application.
- Remote code execution flaws, which are also among the ten most detected types of issues within ShiftLeft application tests, are closely related to injection flaws. Beyond input validation best practices, which can help with a broad range of injection issues, functions like “eval” in JavaScript often lead to remote code execution issues. Look for code evaluation functions with a SAST or linter, and find out if it is possible to solve the problem without such functions.
Access Control Flaws
Access control flaws became so much of a problem over the last several years that they shot up to the top of the OWASP Top Ten in 2021, up from fifth in the 2017 list. Among applications actively tested by ShiftLeft, the most commonly detected flaws related to access control include directory traversals and insecure cookies.
At its heart, the realm of access control flaws refers to a broad range of issues that lead to users being able to do things in an application that are outside of their intended permissions. This includes, but is not limited to, accessing, modifying, or deleting data that a user should not be able to interact with in that way.
Access control flaws are a broad group of application issues that must be addressed at both a code level and a design level:
- Except for resources that are deliberately intended for the general public, deny access by default.
- Ensure that access control is only performed via trusted server-side code, or a trusted serverless cloud service API.
- When securing directories, prevent users from passing characters associated with file paths (such as /, .., \, or ~), mount directories as static, or build in a content management system that is designed to generate secure document paths and manage permissions in a granular fashion.
- When designing cookies, use attributes like Secure, HttpOnly, Domain, Path, Expire, and Max-Age to limit the function of session cookies to what is intended.
Insecure Deserialization
Serialization, or the storage of data structures as a stream of bytes, makes objects easy to store for later use. However, if a program deserializes untrusted data — think, binary data from an HTTP request — then your code may end up deserializing an attacker’s code at runtime, meaning remote code execution. Insecure deserialization remains on the OWASP Top 10, under the category of software and data integrity failures. It is common in the real world: in fact, it is the second-most detected category of issue within the ShiftLeft platform.
The best way to avoid insecure deserialization is to avoid serialization. If an application needs to take in structured data, use a format like XML or JSON. If software must use serialization, make sure to build in safeguards such as making the necessary assertions about each object’s class, and verifying digital signatures of serialized data.
Prototype Pollution
Prototype pollution is a relatively new type of vulnerability. It occurs in languages such as JavaScript that use prototypes: when new objects are created, they inherit all of the objects in the prototype. But, since objects in the prototype can also be altered, prototype pollution can lead to code calling altered versions or injected attributes of these base objects. This can lead to issues such as denial of service, remote code execution, or cross-site scripting.
Given the prevalence of JavaScript and frameworks like Node.js, and the fact that prototype pollution is such a newly understood vulnerability, we expect that this is going to become a more prevalent issue, as attackers find ways to leverage it before developers get better at preventing it.
This is the time to get out in front of it by following best practices for remediation. At the design level, block modification of attributes such as proto or prototype. At the code level, use objects without prototypes, or if practical, freeze the object prototype.
Security Misconfigurations and XXE
With software development becoming increasingly modular, security configurations are becoming more complex. That opens up more room for both developers and operations teams to make costly errors in security configurations, an issue that remains in the OWASP Top 10. XML External Entities, or XXE, were considered their own issue on the 2017 version of the OWASP Top 10, but have been rolled into the Security Misconfigurations category for 2021. This is one of the ten most common issues identified in ShiftLeft scans. An XXE issue happens when XML that refers to an external entity is processed by an XML parser. This can be leveraged to access data either directly or through a verbose error message that leaks the XML document.
Preventing security misconfigurations is a broad goal that requires both code-level and program-level hardening. This is best handled by creating and documenting application security processes that can be repeated, so that security configurations can be properly hardened each time software is deployed or updated. To prevent XXE specifically, ensure that XML parsers disable inline Document Type Definitions (DTDs), and limit effects by adhering to the principle of least privilege when designing server infrastructure and accounts.
Cryptographic failures
Secure cryptography is a foundation of protecting data in a connected world, since it is typically the last line of defense for both data in motion and data at rest. Not only is data encryption a best practice, it is becoming a regulatory requirement under an increasing number of frameworks including HIPAA and GDPR. There are many cryptographic failures that show up in applications including cleartext data transfer, outdated algorithms, weak keys, and bypassable enforcement.
Addressing cryptographic issues is as complex as the range of failures, which underscores that software developers must know about both the best practices for algorithms to use, as well as for secure implementation of data encryption in the software they develop.
Developer Lessons
Given the differences in both vulnerabilities and framing of those vulnerabilities in the 2017 OWASP Top 10 compared to the 2021 version, the focus has shifted from code-level issues more toward design level issues. Consider the shifting of XXE under the larger heading of security misconfigurations, or XSS moving under injections. Though that is a positive sign at code level, suggesting developers have become better at addressing those vulnerabilities, it also suggests that companies now need to adapt their security programs in order to address design issues.
The best way to address design-level issues is to shift security further left in the software development lifecycle. By involving security experts and discussing security questions during the requirements and design phases – in other words, shifting security left – you can save your company the cost of having to uproot a project that has been further along to fix a design issue, or save them the cost of a breach. For example, issues like insecure cryptographic algorithms, security misconfigurations, and access control can be “designed away” by choosing more secure options to build the project.
Though design-level issues are taking up more space in the AppSec discussion, developers still need to know how to identify and correct code-level issues. After all, some of the most identified issues in the real world still include things like XSS and insecure deserialization. To identify and address remaining code-level issues like XSS and insecure deserialization, developers can integrate a SAST into their development process. It can scan their code and give feedback at each pull request, helping identify code-level vulnerabilities as early as possible and providing feedback about how to secure the application.
How ShiftLeft Can Help Combat Application Security Vulnerability
A good SAST, one that is regularly updated with the latest vulnerabilities and languages, is a key application security technology. It can help keep developers on top of the vulnerabilities that matter. Modern SAST can be configured to scan code at several points during the development process: at each check-in, and also further along in the process as each feature is more thoroughly developed. That way, developers see as early as possible what issues are.
ShiftLeft clients are seeing real improvement in addressing their code-level issues: by integrating ShiftLeft’s next-generation SAST with their CI/CD pipeline, 91% of code-level and OSS vulnerabilities have been resolved over the course of two sprints.
ShiftLeft also provides contextual security training within the platform. Findings in ShiftLeft are accompanied by information about the finding as well as training for mitigation of those vulnerabilities. This both makes the findings more actionable and provides concrete assistance toward the goal of teaching developers how to create more secure code for the long run. In addition to the training within the application, we also have online guides to addressing common security issues in Java and Node.js, which discuss these most common vulnerabilities and more, and we plan to expand this collection in the future.
The Next Step
Confronting application security vulnerabilities is complex, but there is no better time than now for developers to improve their secure development abilities. After all, developers are critical for secure software. By learning about current vulnerabilities and learning how to design and build in a way that avoids those issues, developers can help make sure a trustworthy product makes it onto the market. And, by choosing a tool that integrates smoothly into the development process and provides continuing developer education, developers can be set up for success.
To learn more about how ShiftLeft enables companies to deliver more secure software at scale, read our AppSec Shift Left Progress Report. It shows how ShiftLeft is helping clients scan software more frequently, address security issues earlier in the development process, and reclaim developer time for other features or products.