Top 10 application security acronyms
Explaining common AppSec acronyms
著者:
0 分で読めます
Cheat-sheet
Top 10 Application Security acronyms explained
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 application security 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, read our SAST vs. DAST article.
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 Open Source, 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.
Read more about SAST vs SCA and how to leverage them to release secure software.
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 the 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 the 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 are 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.