reachable vulnerabilities

Complete Guide to Application Security 2021

With more organizations now depending on software to move their business processes forward, keeping application security in line with development practices has become essential. The way in which developers build and release applications has changed dramatically in recent years. Today’s development cycles resemble software factories, where new features and updates often roll off an assembly line daily. For software security managers, this adds complexity and additional risk in order to ensure applications do not create new vulnerabilities in business systems.

This Application Security Guide is aimed to shed light on core application security concepts and methodologies, vulnerabilities and issues, and equip you with all the tools you need to stay secure in 2021.

Contents:

  1. Intro to Application Security
  2. 5 Types of Web Application Security
  3. Application Security Tools
  4. Application Security Challenges
  5. Application Security Trends 2021
  6. Application Security Glossary for Developers

What Is Application Security?

Application security, the process of finding and fixing vulnerabilities within software, is a vital part of any development cycle. It requires a proactive approach during every build and release cycle, often depending on automation to identify threats. It is an ongoing process that relies on the most up-to-date information about the organization’s attack surface to ensure deployed applications remain protected while in production.

With hackers now targeting applications more frequently, in order to ensure the technology landscape remains secure, application security best practices employ different tools and methods in every stage of the build, test, and release cycle.

Why Is Application Security Important?

Application security as a distinct discipline continues to grow. By 2019, the market was valued at $4 billion, with analysts expecting it to reach $15.25 billion at a CAGR of 25% by 2025. This drive for growth has largely been due to the implementation of CI/CD processes within companies, and enterprises in particular. Vulnerabilities can originate from something as simple as a configuration error or using a software component that contains a known vulnerability. 

One recent study revealed that out of 85,000 applications that were analyzed 83% contained at least one security flaw. Of these, 20% had a severe vulnerability. While not all of these vulnerabilities necessarily present a major security risk, hackers continue to refine their attacks by using ingenious workarounds to penetrate software. To improve app security, companies need to invest in tools that integrate with their development environment. This is critical for companies working with highly sensitive data (e.g., financial institutions, government organizations, healthcare, etc.).

5 Types of Web Application Security

  1. Critical Infrastructure and Cybersecurity
  2. Mobile and Network Application Security
  3. Network Security
  4. Cloud Security
  5. Internet of Things Security

There’s no cookie-cutter solution for app security. Every organization has a different approach to vetting solutions prior to their release. Finding the best approach for improving your application and software security requires adopting a holistic view of the attack surface. This also depends on the specific access and deployment models used for the application, including the environment in which it’s used and how crucial it is for continued operations.

1. Critical Infrastructure and Cybersecurity

Cyber-physical systems that provide access to critical infrastructure (e.g., electricity grids, water purification, or hospital and financial service systems) will require the deployment of additional security solutions. It is critical that organizations managing any such applications exercise due diligence.

2. Mobile and Network Application Security

In enterprises, any application (whether internal or public-facing) requires a formal process to test and fix vulnerabilities during development. Whenever mobile or remote access is required, encryption should be built in as part of the design. In addition, traditional layers of protection like firewalls and antivirus should be used on every connected node.

3. Network Security

Network intrusion tools and threat monitoring systems can protect internal systems and help improve overall security. Traditionally, this task would have fallen on network administrators. However, with the advances in build and deploy methods, it has now become the responsibility of every developer involved in the process of releasing new applications into a company’s networks.

4. Cloud Security

Software-based security tools that protect cloud applications and monitor company data have made cloud resources a preferred deployment method. Cloud service providers are continuously reviewing their platforms and improving their security solutions. On the other hand, it was found that on-premises deployments suffer more breaches on average than cloud environments. 

Bear in mind that the responsibility for cloud security is distributed between the cloud provider and the customer. The provider must handle the security of the infrastructure itself, while the customer is responsible for managing users and access control.

5. Internet of Things Security

The growing adoption of the internet of things (IoT) has put organizations that have yet to implement and control their connected devices at risk. Everything from biometric scanners, CCTV cameras, and building management systems (BMS) can lead to breaches if not adequately protected. 

Any device that connects to the company network or is accessible via the internet requires additional security. This is to prevent hackers from using these devices as an intermediate or starting point of an attack for further escalation. Such attacks can also be challenging to detect, making this all the more important.

What Are the Application Security Tools?

Application security tools look for known vulnerabilities and classify the results. They can be used to identify trends and patterns. Because breaches often exploit the application layer to access systems, application security tools are critical for improving application layer security. They help developers test for known vulnerabilities (or code errors) during the build and release phases.

Secure your applications

Automatically find, prioritize and fix vulnerabilities in the open source dependencies used to build your cloud native applications

With new vulnerabilities constantly surfacing and the significant time investment involved in manual code reviews and other traditional testing methods, security tools can offer numerous advantages.

These tools improve application security testing. The tests they carry out arerepeatable and scalable. A given test can be performed repeatedly at only a small incremental cost. These tools look for known vulnerabilities and classify the results. They are also capable of identifying trends and patterns.

Let’s explore five of the most popular application security tools:

  • Static application security testing (SAST): SAST is white-box testing with access to source code, at rest, it identifies weaknesses that may lead to a vulnerability and then generates a report.
  • Dynamic application security testing (DAST): DAST is  black-box testing while the application is running, without requiring in-depth knowledge of how a system works internally. DAST tools analyze operating code to identify issues with requests, responses, interfaces, scripts, injections, authentication, and sessions using fuzzing.
  • Software composition analysis (SCA): Also known as origin analysis, this method helps to analyze all sourced software components and libraries. These tools help identify known vulnerabilities and notify the user of any available patches or updates.
  • Interactive application security testing (IAST): Combining static and dynamic approaches, hybrid IAST tools perform testing on application and data flow using predefined test cases. The tool may recommend additional test cases based on the results.
  • Application security testing as a service (ASTaaS): In this scenario, the organization enlists an external company to perform all testing for their applications. ASTaaS usually combines static and dynamic security methods, including penetration testing and evaluating application programming interfaces (APIs).

While different tools can provide one or more of the features above (and other testing methods), a new term that is gaining traction is application security testing orchestration (ASTO). These application security methods can also be consolidated into a central management and coordination console for all testing tools using ASTO.

What Are the Application Security Challenges?

Organizations face many challenges in trying to improve their application security. Chief among these is insufficient budgets to keep up with the increasing attack surface of the technology landscape. Most security managers will readily admit their test and security programs will need to improve in the future, requiring greater spend on application security testing. Other challenges include inherited vulnerabilities, third-party open-source vulnerabilities, lack of a DevSecOps model, a shortage of qualified experts, and no centralized testing management tools, which we explore below.

Inherited Vulnerabilities

By reusing old code or legacy applications, developers inherit technical debt. Blindly using code previously written by someone else is a huge risk. You cannot know what security measures have been taken and the code may contain many weaknesses and omissions. If using old code, it’s critical to ensure it is reviewed for security before integrating it with the rest of the application. SAST tools may also help you catch vulnerabilities in the code faster.

Third-Party and Open-Source Vulnerabilities

As many as 96% of applications use open-source software and libraries. But the use of external components and modules, particularly open source, requires continuous monitoring for vulnerabilities and ensuring updates and patches are applied immediately.

Adopting a DevSecOps Approach

The adoption of a DevSecOps approach is key for ensuring the security of your application throughout the entire secure development life cycle, as opposed to treating security as an add-on. This “shift-left” approach means every security incident should be resolved as quickly as possible.

application security requires adopting devsecops model
DevSecOps Adoption: Integrating Security into the CI/CD Pipeline

Unfortunately, however, many companies and software houses creating applications have yet to adopt the DevSecOps model due to the many challenges in implementing such an approach: it requires finding the right tools and successfully integrating them, implementing security in your CI/CD process, and ironing out the many inevitable issues along the way.

Finding Qualified Experts

As the application market continues to grow, there are more and more programmers too. While finding a developer isn’t a problem, it is far more difficult to find an experienced programmer. There is also a lack of trained engineers with both the programming skills and expertise in application security.

Lack of a Centralized Management Tool

Another challenge facing application security teams is that they often do not have access to a centralized tool to manage all testing during the development process. ASTO tools can help security managers and analysts establish effective oversight of build and release cycles, ensuring they find and address all vulnerabilities to prevent breaches.

Application Security Trends 2021

Application security is constantly evolving in order to meet the many new and ongoing challenges in the field. Some of these trends include:

  1. Runtime application self-protection (RASP): this technology enables applications to identify vulnerabilities automatically. Self-evaluating applications can detect, diagnose, and provide protection against attacks in real time.
  2. Backend as a service (BaaS) and functions as a service (FaaS): BaaS (e.g., Google Firebase) and FaaS (e.g., AWS Lambda) solutions are also becoming increasingly popular as serverless deployment models. By reducing the complexity of the backend infrastructure, they make it easier for developers to build and release secure code in cloud environments.
  3. Monitoring tools for public and private cloud Software as a Service (SaaS) applications matured: An increasing number of organizations are now opting to deploy application-level security monitoring for both public and private cloud to facilitate vulnerability detection for the entire application portfolio.
  4. Web application firewalls (WAF): WAF is a specialized tool that can offer protection for web applications by helping to control incoming and outgoing network traffic. Its effectiveness depends largely on the rules (i.e., allow lists and block lists) that are created. These rules should clearly specify which content is allowed and what should be blocked, offering protection from zero days and other vulnerabilities. WAFs can be improved by making sure all attack vectors generated by dynamic testing tools are blocked. The major cloud providers all offer WAF solutions: AWS WAF, Azure Web Application Firewall, and Google Cloud Armor.
  5. FaaS (function as a service) and the serverless model: With the FaaS model, existing applications must be rewritten to a compatible language that FaaS supports. The serverless model offers a solution to this problem. GCP and AWS already offer such solutions. Google Cloud Run uses any Docker image to run as containers on demand by automatically balancing resources. AWS Fargate, offered as a launch type on Amazon ECS (Elastic Container Service), makes resources accessible based on the container processor and memory requirements.

What Are Application Security Controls?

Application security controls add another layer of software protection. By ensuring proper coverage while monitoring the confidentiality, availability, and integrity of the application and associated data, these controls are able to monitor all actions an application performs and thus prevent any unauthorized task execution. Controls may include validity checks, authentication verification, identification management, or input controls. This helps to reduce the attack surface by analyzing behavioral patterns and locking down applications if they attempt to compromise the network. If an application attempts to execute a task outside of known parameters, the control will prevent this and alert security teams.

Enabling Effective Application Security with Snyk

The growing threat of application security breach is one of the greatest challenges organizations face. Delivering fast builds and releases requires effective solutions enabling teams to develop with confidence.

Discover new vulnerabilities faster – signup to check your code or request a demo today.

Check for vulnerabilities in public GitHub repositories

By submitting this form you consent to us emailing you occasionally about our products and services.
You can unsubscribe from emails at any time, and we will never pass your email onto third parties. Privacy Policy

Throughout the discussion, they use various acronyms that they just assume you know the meaning of, yet in reality, they are not terms you’re familiar with. Does this sound familiar to you? Unfortunately, this seems to be a common occurrence in many DevSecOps organizations. In fact, we at Snyk fell into this trap with our recent announcement of the SAST capabilities in Snyk. We received a lot of feedback on social media that people didn’t know what SAST was. So, we thought it would be a good idea to put together a cheatsheet of the top 10 most common security acronyms—and don’t worry, we have included SAST as one of them so keep reading to find out what that’s all about.

Application Security Glossary

security acronyms
  1. SAST—Static Application Security Testing
  2. DAST—Dynamic Application Security Testing
  3. SCA—Software Composition Analysis
  4. OWASP—Open Web Application Security Project
  5. XSS—Cross-Site Scripting
  6. CSRF—Cross-Site Request Forgery
  7. RASP—Runtime Application Self-Protection
  8. DoS—Denial of Service
  9. CSP—Content Security Policy
  10. SSRF—Server Side Request Forgery

Picture this situation: you as a developer are in a meeting where a security practitioner is discussing the results of a recent penetration test or static analysis of code you’ve written. 

Throughout the discussion, they use various acronyms that they just assume you know the meaning of, yet in reality, they are not terms you’re familiar with. Does this sound familiar to you? Unfortunately, this seems to be a common occurrence in many DevSecOps organizations. In fact, we at Snyk fell into this trap with our recent announcement of the SAST capabilities in Snyk. We received a lot of feedback on social media that people didn’t know what SAST was. So, we thought it would be a good idea to put together a cheatsheet of the top 10 most common security acronyms—and don’t worry, we have included SAST as one of them so keep reading to find out what that’s all about.

1. SAST—Static Application Security Testing

Static Application Security Testing, or SAST, is the practice of analyzing the source code of an application, service, microservice, etc. to identify potential security vulnerabilities that exist as a result of insecure coding practices. SAST is most often implemented using automated tools that search source code for use of coding patterns, insecure functions, or insecure objects that could lead to security vulnerabilities. SAST is most commonly used to identify vulnerabilities in newly developed code. It is typically performed during the coding phase or at the point code is being promoted to a test environment.

One of the key advantages of SAST is that it can identify vulnerabilities early in the development process and can find hidden vulnerabilities that might go undetected just by looking at the functionality of the application. Automated SAST tools can analyze large amounts of code very quickly. However, as a result they can also generate a large number of results, often times containing false positives or vulnerabilities that in the context of the application aren’t truly a risk at all. With some tools it can take a significant amount of time to tune it and eliminate these issues. Still the value of such tools is crucial to your security posture.

2. DAST—Dynamic Application Security Testing

Dynamic Application Security Testing, or DAST, is the practice of analyzing a running application or service for security vulnerabilities. DAST is meant to mimic the types of attacks that a malicious user might conduct against the application through the user or application interface. The advantage of this approach is that it can identify complex vulnerabilities that result from specific functionality of the application that might be missed just by analyzing the source code.

In DAST, the interface is analyzed for various indicators of vulnerabilities by inspecting how the application responds to different requests and inputs (often referred to as payloads). Everything from user input fields to HTTP headers are looked at to determine if proper data handling and security countermeasures have been implemented to prevent attackers from manipulating the application or service. 

Automated, semi-automated, and manual tools can be used for conducting DAST. Fully automated DAST tools are typically capable of mapping out the various pages of an application and testing them for a wide variety of potential security vulnerabilities using variants of payloads. These tools often are also capable of testing web services and microservices as well. Other tools used in DAST have more specialized focus for more deeply analyzing one or a few specific types of vulnerabilities. DAST is typically performed in late-stage testing phases just before an application or service is deployed to a production environment.

To learn more about the difference between SAST and DAST, visit our SAST vs. DAST Learn page.

3. SCA—Software Composition Analysis

Software Composition Anlaysis, or SCA, refers to analyzing an application to identify any third-party or open source software components that are included in the software. Typically, SCA includes analyzing those outside dependencies for known security vulnerabilities and possible licensing issues. Automated SCA tools, like Snyk OpenSource, are typically capable of mapping out the entire dependency tree, not just looking at inclusions within the source code of the application but also analyzing the dependencies that each of those dependencies has as well, and so on down the line.

Software Composition Analysis can be run at any phase in the delivery pipeline but it is usually preferable to run it earlier, often in the coding phase, to ensure any issues that come up can be addressed quickly. One of the key reasons for SCA is to not only identify potential security flaws introduced by third party components during the development of an application, but also to ensure that as new vulnerabilities are identified in third-party or open source software, the organization can quickly assess if they are impacted by newly announced vulnerabilities and quickly plan remediation.

4. OWASP—Open Web Application Security Project

The Open Web Application Security Project, or OWASP, is a non-profit group focused on security of software. OWASP is known for their many community-driven projects that are aimed at providing education and guidance on how to produce more secure software. OWASP cultivates a large community of volunteers who propose, develop and manage these projects and educational materials for the benefit of the wider security and software development community.

One of the most well-known projects is the OWASP Top 10 which is a list of the ten most common types of web application vulnerabilities that is updated on a periodic basis via input from the community. When performing SAST or DAST you may hear discussion of the OWASP Top 10 as a guide for the types of vulnerabilities testers may be looking for. While it is not a comprehensive categorization of all possible vulnerability types, it is a good base to begin from. 

OWASP also hosts various security conferences around the globe and has global chapters that meet on a regular basis to share ideas, work on projects, and spread knowledge. Individual projects may also host summits from time to time to bring professionals and project members together to discuss and refine aspects of the projects.

5. XSS—Cross-Site Scripting

Cross-Site Scripting, or XSS, is one type of security vulnerability commonly identified in web applications. It has been included on the OWASP Top 10 since the very first version was released in 2003. XSS is a form of application attack that can allow an attacker to execute malicious script code (most commonly javascript) within a user’s or many users’ browsers. This type of exploit can be used to gather sensitive information that can include user session details or personal data. 

There are three forms of XSS that are typically discussed:

  • Reflected: The attacker causes the user to send a request to the application that contains the attack payload and the application includes it in the response, causing it to be executed within the browser.
  • Stored: The attacker sends the attack payload to the application and it is stored in a value that is returned to other users as part of dynamically constructed pages causing the script to execute within their browser.
  • DOM-based: The attacker sends the malicious script to the user (usually in a malicious link) and it is directly executed in the DOM of the page without going through the application at all.

You can get more information on XSS and how to prevent it on our XSS page on Snyk Learn.

6. CSRF—Cross-Site Request Forgery

Cross-Site Request Forgery, or CSRF, is another common form of web application attack. In a CSRF attack, the attacker is able to take advantage of an already authenticated session between the user’s browser and the application to execute functionality of that application through requests that are embedded in a malicious website controlled by the attacker. CSRF is sometimes also referred to as session riding and some people prefer to pronounce it C-Surf. 

Cross-site request forgery is often exploited by taking a valid request made to the target application and causing it to be replayed within the victim’s browser while they have an active authenticated session with the target application. For instance, the attacker may capture a request from an online banking application that performs a wire transfer. They would then create a malicious site and host that same request in an IFRAME so that anyone who visits the site would submit the same request to the banking application. In this way, if the visitor has an active session (perhaps in another browser tab) with that banking application, the request would be submitted under that active session. To get visitors to the site, the attacker would likely use a targeted phishing campaign to try to trick likely customers of the bank (and therefore likely users of the banking application) to visit the malicious site.

For more information on Cross-Site Request Forgery and how to prevent them, see our CSRF  page on Snyk Learn

7. RASP—Runtime Application Self-Protection

Runtime Application Self-Protection, or RASP, refers to a defensive technique built into an application that allows the application to detect attacks and react to them right away. RASP is most often implemented via third-party tools. RASP tools usually embed themselves in the application and monitor not just incoming requests but also the application’s behavior to spot and prevent attacks. This can be done via packages, libraries, or plug-ins that act as almost a filter on the front of the application to be able to inspect requests and application behavior. The primary benefit of RASP is that it ensures that even if vulnerabilities exist in the application, they cannot be exploited successfully by an attacker (or at least the extent of the exploitation can be significantly limited).

8. DoS—Denial of Service

Denial of Service, or DoS, is  a type of exploit in which an attacker seeks to limit or prevent the availability of an application or service. This is commonly done by causing the application, service, or system to become unresponsive or extremely slow to respond. It can also be done by attacking network infrastructure that provides communication to the application. DoS attacks happen when an attacker can exploit a flaw in the code, system software, or network infrastructure of an application to make it unavailable to others. There are many ways to conduct a DoS attack, but there two specific types of DoS that are often discussed:

  • DDoS: Distributed Denial of Service, is when an attacker uses a large number of systems (usually part of a Botnet) to overwhelm a target with traffic causing it to become unavailable.
  • REDoS: Regular Expression Denial of Service is a specific flaw commonly found in server side javascript apps where an attacker can cause the regular expression engine to consume large amounts of resources rendering the application unresponsive.

9. CSP—Content Security Policy

Content Security Policy, or CSP, is a web application countermeasure that is designed to prevent XSS attacks. It allows application developers to use an HTTP Header to instruct the browser to only load and execute script from specific sources. By preventing script from being loaded from unintended sources, the application developer can prevent script supplied through an XSS attack from actually being executed when it reaches the browser.

Get more resources and information about CSP in our blog.

10. SSRF—Server Side Request Forgery

Server Side Request Forgery, or SSRF, is a form of application attack in which an attacker can cause the front-end application to send requests to arbitrary locations (such as other internal servers, external servers, or even back to itself). It can allow the attacker access to unauthorized data or functions. 

To get more details on SSRF, we recommend this guide from OWASP.

In Summary

Like any industry, security has many different technical terms that are often shortened into acronyms for ease of discussion. This can make it confusing for non-security personnel. For developers, being able to decipher the terms their security partners use can be a powerful tool in building better collaboration in the DevSecOps delivery pipeline.

November 3, 2020
| By Liran Tal