The Open Web Application Security Project (OWASP) "is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted."
The community publishes books, articles, holds events and provides guidance in the furtherance of application security. In relation to this training, it also publishes the OWASP Top Ten project.
The project is an awareness document that provides the current top 10 application security risks identified, along with ways to address the risk and tips specific to different roles in an organization.
The latest guidance, published in 2021, has these top 10 application security risks:
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery (SSRF)
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
Access controls are only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.
- Except for public resources, deny by default.
- Implement access control mechanisms once and re-use them.
- Model access controls should enforce record ownership.
- Domain models enforce unique application business limit requirements.
- Disable web server directory listings.
- Ensure file metadata and backup files are not present within web roots.
- Log and alert on access control failures.
- Rate limit API and controller access.
- Invalidate Stateful session identifiers on the server after logout.
Cryptographic failures occur when sensitive data is exposed or systems are compromised. To ensure a strong cryptographic environment, the protection needs of data in transit and at rest need to be determined. If the data falls under privacy laws, e.g., EU's General Data Protection Regulation, or regulations, e.g., financial data protection such as PCI Data Security Standard then extra protection is required.
- Don't store sensitive data unnecessarily.
- Encrypt all sensitive data at rest
- Use proper key management.
- Enforce authenticated encryption on all data in transit with secure protocols.
- Disable caching for sensitive data.
- Do not use legacy protocols for transporting sensitive data.
- Store passwords using strong adaptive and salted hashing functions with a work factor.
- Initialization vectors must be chosen appropriate for the mode of operation
- Ensure that cryptographic randomness is used where appropriate.
- Avoid deprecated cryptographic functions and padding schemes.
- Verify independently the effectiveness of configuration and settings.
An injection is an application vulnerability where untrusted input is injected into a program. An application is vulnerable to attack when:
- User-supplied data is not validated, filtered, or sanitized by the application.
- Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
- Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
- Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.
- Use a safe API, which avoids using the interpreter entirely, provides a parameterized interface, or migrates to Object Relational Mapping Tools.
- Use positive server-side input validation.
- For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
- Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design”. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.
- Establish and use a secure development lifecycle with AppSec professionals.
- Establish and use a library of secure design patterns or paved road ready to use component.
- Use threat modeling for critical authentication, access control, business logic, and key flows.
- Integrate security language and controls into user stories.
- Integrate plausibility checks at each tier of your application.
- Write unit and integration tests to validate that all critical flows are resistant to the threat model.
- Compile use-cases and misuse-cases for each tier of your application.
- Segregate tier layers and tenants robustly by design throughout all tiers.
- Limit resource consumption by user or service.
Insecure configuration options create vulnerabilities in applications and grant unauthorized access to system data and functionality at any component within the stack. Without a concerted, repeatable application security configuration process, systems are at a higher risk.
- An automated repeatable hardening process.
- A minimal platform without any unnecessary features. Review and update the configurations appropriate to all security notes, updates, cloud storage permissions and * patches as part of the patch management process.
- A segmented application architecture with segmentation, containerization, or cloud security groups.
- Sending security directives to clients.
- An automated process to verify the effectiveness of the configurations and settings in all environments.
Testing and accessing risks as it emerges is a commonly known struggle for every industry resulting in vulnerable and outdated components. You are likely vulnerable:
- If you do not know the versions of all components in use.
- If the software is vulnerable, unsupported, or out of date.
- If you do not scan for vulnerabilities regularly.
- If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion.
- If software developers do not test the compatibility of updated, upgraded, or patched libraries.
Every organization must ensure an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio. There should be a patch management process in place to:
- Remove unused dependencies, unnecessary features, components, files, and documentation.
- Continuously inventory the versions of both client-side and server-side components and their dependencies.
- Continuously monitor sources like Common Vulnerability and Exposures (CVE) and National Vulnerability Database (NVD) for vulnerabilities in the components.
- Only obtain components from official sources over secure links.
- Monitor for libraries and components that are unmaintained, or do not create security patches for older versions.
Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:
- Permits automated or brute force attacks.
- Permits default, weak, or well-known passwords.
- Uses weak or ineffective credential recovery and forgot-password processes.
- Uses plain text, encrypted, or weakly hashed passwords data stores.
- Has missing or ineffective multi-factor authentication.
- Exposes session identifier in the URL.
- Reuse session identifier after successful login.
- Does not correctly invalidate Session IDs.
- Where possible, implement multi-factor authentication.
- Do not ship or deploy with any default credentials.
- Implement weak password checks.
- Align password length, complexity, and rotation policies with National Institute of Standards and Technology (NIST).
- Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
- Limit or increasingly delay failed login attempts.
- Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
- Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login.
Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. Attackers could potentially upload their own updates to be distributed and run on all installations.
- Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.
- Ensure libraries and dependencies, such as npm or Maven, are consuming trusted repositories.
- Ensure that a software supply chain security tool is used to verify that components do not contain known vulnerabilities
- Ensure that there is a review process for code and configuration changes.
- Ensure that your CI/CD pipeline has proper segregation, configuration, and access controls.
- Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without an integrity check or digital signature to detect tampering or replay of the serialized data.
Security logging and monitoring enables an organization to detect and respond to breaches. Without logging and monitoring, breaches cannot be detected.
Developers should implement some or all the following controls, depending on the risk of the application:
- Ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.
- Ensure that logs are generated in a format that log management solutions can easily consume.
- Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.
- Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion.
- Establish or adopt an incident response and recovery plan.
SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list.
Developers can prevent SSRF by implementing some or all the following defense in depth controls:
From Network Layer
- Segment remote resource access functionality in separate networks to reduce the impact of SSRF.
- Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic.
From Application Layer
- Sanitize and validate all client-supplied input data.
- Enforce the URL schema, port, and destination with a positive allow list.
- Do not send raw responses to clients.
- Disable HTTP redirections.
- Be aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions.