Application Security Threats: The OWASP Top 10
There are countless security threats that affect software applications. However, the Open Web Application Security Project (OWASP) Top 10 list compiles the application threats that are most prevalent and severe, and most likely to affect applications in production.
AppSec initiatives must focus at least on these high profile threats to modern applications:
- Injection—code injection involves a query or command sent to a software application, which contains malicious or untrusted data. The most common is SQL injection, but it can also affect NoSQL, operating systems, and LDAP servers.
- Broken Authentication—many applications have inadequate or malfunctioning authentication and authorization functions. This can allow an attacker to steal user credentials, or easily gain access without appropriate credentials.
- Sensitive Data Exposure—applications and APIs may openly expose sensitive data belonging to the organization or its customers, including financial or payment details and personally identifiable information (PII).
- XML External Entities (XXE)—attackers can make malicious use of external entity references in XML documents, due to vulnerabilities in old XML parsers. These can be used to gain access to internal files, scan ports, and execute code remotely.
- Broken Access Control—restrictions for authenticated users are not implemented correctly. An attacker could use this to gain access to unauthorized functions or data, access another user’s account, view sensitive files, or change permissions for other users.
- Security Misconfiguration—even if an application has security features, they can be misconfigured. This commonly occurs because no-one changed the application’s default configuration. This includes failure to patch operating systems and frameworks.
- Cross-Site Scripting (XSS)—allows an attacker to run a malicious script in a user’s browser. This can be used to steal their session, redirect users to malicious sites, or perform defacement of websites.
- Insecure Deserialization—faults in the way code is taken from a file and constructed into an object. This can enable malicious code execution, privilege escalation, and replaying activity by authorized users.
- Using Components with Known Vulnerabilities—multiple vulnerability databases report known vulnerabilities in software components. Software that uses a vulnerable component (even just as a dependency of one of its components) is exposed to attack.
- Insufficient Logging & Monitoring—many applications may not have means of identifying or recording attempted breaches. This can mean that breaches go undetected, and attackers may perform lateral movement to compromise additional systems.
A basic AppSec process involves the following stages:
- Defining corporate assets
- Determining how each application affects these assets
- Creating a security profile for each application
- Identifying and prioritizing potential threats
- Recording security incidents and attempts at mitigation
Application Security Testing Tools
There are three primary categories of tools in the AppSec toolset: SAST, DAST, and IAST.
Static Application Security Testing (SAST)
SAST tools enable white box testing. They evaluate application code, scanning it to identify bugs, vulnerabilities or other weaknesses that can create a security issue. SAST can run on compiled code, non-compiled code, or both.
SAST analysis can identify issues like:
- Race conditions
- Path traversals
- Missing input validation
- Numerical or data type errors
- Unsecure references or pointers
Dynamic Application Security Testing (DAST)
DAST tools use black-box testing methods to test running applications for security issues. They perform dynamic analysis of source code while it is running. DAST commonly uses fuzz testing, which involves hitting the application with a large number of random, unexpected requests.
DAST can detect conditions that indicate security vulnerabilities, such as:
- Non-secured or vulnerable interfaces
- Anomalous requests and responses
- Data or code injection
- Session anomalies
- Authentication issues
Interactive Application Security Testing (IAST)
IAST is a hybrid approach that combines SAST and DAST. The interactive approach to security testing combines static and dynamic analysis—this makes it possible to identify known vulnerabilities, and also see if they are actually used in the running application and can be exploited.
IAST tools gather detailed information about application execution flow and data flows, and can simulate complex attack patterns. As it performs a dynamic scan of a running application, it can check how the application responds, and adjust its testing accordingly. This can be used to automatically create new test cases, and so on (much like a human penetration tester).
Due to this approach, IAST tools can deeply investigate suspected security issue, which reduces the number of false positives. They also fit much more naturally into an agile development process with rapid releases.
Rule Based Web Application Firewall (WAF)
A WAF is a solution deployed at the network edge, which inspects traffic flowing into and out of the network, and attempts to identify and block malicious traffic.
Traditional, rule-based WAFs are a high-maintenance tool that require organizations to meticulously define a rule set that matches their specific traffic and application patterns. In addition, rule-based WAFs have limited coverage of constantly changing attack vectors.
In addition, traditional WAFs cannot automatically protect new microservices, because each new microservice deployed requires a significant overhead of defining new rules and policies. In practical terms, this means new systems deployed by the organization will in many cases not be protected.
Application Security Best Practices
Here are some best practices you can use to effectively implement AppSec in your organization.
Start with a Threat Assessment
Investigate what are the main entry points attackers can use to breach your applications, what security measures are in place, and whether they are adequate. Set reasonable goals, and milestones over time, for the level of security you want to achieve against each type of threat.
Shift Security Left
Security testing must be fully integrated with the software development lifecycle (SDLC), from the planning stage, through to development, testing and deployment to production.
Use automated tools to ensure applications are tested as early as possible in the process, and in multiple checkpoints throughout the CI/CD pipeline. For example, when a developer commits code and triggers a build, that code should automatically undergo some form of security testing, enabling the developer to immediately fix security issues in their code.
That same code should be tested again, more comprehensively, when promoted to a testing and production environment.
Application security will result in discovery of vulnerabilities in your applications—and you won’t be able to fix all of them. Prioritization is very important to ensure that critical vulnerabilities are remediated fast, without hurting developer productivity.
Your security testing process should include automated metrics showing vulnerability severity and exploitability, and if necessary, a manual evaluation indicating whether the vulnerability really poses a business risk. Vulnerable components that are not running in production are not a priority.
Ensure developers know they are working on real, high profile vulnerabilities, and have the time to remediate them wherever they occur in the SDLC.
Track AppSec Results
An AppSec program requires a major investment in time and resources, as well as cultural and organizational changes. It’s important to understand the impact of the program on security to justify the program and ensure it is supported by management.
Important metrics you can track and share to demonstrate AppSec success—a weekly or monthly trend can show the impact of introducing application security measures:
- Number of violations of internal AppSec policies
- Number of compliance violations
- Number of security defects found in testing environment
- Number of security defects found in production
- Number of security incidents
Everything related to an application security program is sensitive data that could be extremely useful to an attacker. Make sure you carefully manage:
- Documentation of policies and processes
- Access to security tools
- Access to CI/CD and development tools
Use the principle of least privilege, and ensure each user only has access to data and systems they absolutely need to do their job. Use zero-trust principles between integrated systems, ensuring each system has only the minimal permissions it needs to function.
AppSec with Check Point
Check Point’s CloudGuard includes a zero configuration application security solution which provides:
- Precise prevention – protection against sophisticated attacks like OWASP top 10, without generating false positives
- Zero-policy administration – auto adapts to application changes and updates
- Flexible, fast deployment – with deployment to protection in up to 48 hours
Powered by a patent pending contextual AI engine, CloudGuard Application Security is fully automated and can be deployed on any environment.