OWASP TOP10
Injection
1.1. (OWASP Top 10) A1
Insecure Deserialization
3.8. (OWASP Top 10 Attack Vectors) Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code.
Using Components with Known Vulnerabilities
3.9. (OWASP Top 10 Attack Vectors) While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit
Insufficient Logging&Monitoring
5.10. (OWASP Top 10 Impacts) Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to Nearly 100%. In 2016, identifying a breach took an average of 191 days - plenty of time for damage to be inflicted.
XML External Entities (XXE)
5.4. (OWASP Top 10 Impacts) These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. The business impact depends on the protection needs of all affected application and data.
Broken Access Control
5.5. (OWASP Top 10 Impacts) The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record. The business impact depends on the protection needs of the application and data.
Using Components with Known Vulnerabilities
5.9. (OWASP Top 10 Impacts) While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.
Insufficient Logging&Monitoring
1.10. (OWASP Top 10) A10
Broken Authentication
1.2. (OWASP Top 10) A2
Sensitive Data Exposure
1.3. (OWASP Top 10) A3
XML External Entities (XXE)
1.4. (OWASP Top 10) A4
Broken Access Control
1.5. (OWASP Top 10) A5
Security Misconfiguration
1.6. (OWASP Top 10) A6
Cross-Site Scripting (XSS)
1.7. (OWASP Top 10) A7
Insecure Deserialization
1.8. (OWASP Top 10) A8
Using Components with Known Vulnerabilities
1.9. (OWASP Top 10) A9
Insecure Deserialization
2.8. (OWASP Top 10) _____ often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
XML External Entities (XXE)
4.4. (OWASP Top 10 SecurityWeakness) By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. SAST tools can discover this issue by inspecting dependencies and configuration. DAST tools require additional manual steps to detect and exploit this issue. Manual testers need to be trained in how to test for XXE, as it not commonly tested as of 2017.
Cross-Site Scripting (XSS)
6.7. (OWASP Top 10 How to Prevent) Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by: • Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework's XSS protection and appropriately handle the use cases which are not covered. • Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet 'XSS Prevention' has details on the required data escaping techniques. • Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet 'DOM based XSS Prevention'. • Enabling a Content Security Policy (CSP) is a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
Injection
5.1. (OWASP Top 10 Impacts) _____ can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. _____ can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data.
Broken Authentication
5.2. (OWASP Top 10 Impacts) Attackers have to gain access to only a few accounts, or just one admin account to compromise the system. Depending on the domain of the application, this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information.
Injection
2.1. (OWASP Top 10) _____ flaws, such as SQL, NoSQL, OS, and LDAP _____ , occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Insufficient Logging&Monitoring
2.10. (OWASP Top 10) _____ , coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems,and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Cross-Site Scripting (XSS)
3.7. (OWASP Top 10 Attack Vectors) Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks
Injection
4.1. (OWASP Top 10 SecurityWeakness) _____ flaws are very prevalent, particularly in legacy code. _____ vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. _____ flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws.
Insufficient Logging&Monitoring
4.10. (OWASP Top 10 SecurityWeakness) This issue is included in the Top 10 based on an industry survey. One strategy for determining if you have sufficient monitoring is to examine the logs following penetration testing. The testers' actions should be recorded sufficiently to understand what damages they may have inflicted.
Broken Authentication
2.2. (OWASP Top 10) Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.
Sensitive Data Exposure
2.3. (OWASP Top 10) Many web applications and APIs do not properly protect _____ , such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. _____ may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
XML External Entities (XXE)
2.4. (OWASP Top 10) Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
Broken Access Control
2.5. (OWASP Top 10) Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc.
Security Misconfiguration
2.6. (OWASP Top 10) _____ is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.
Cross-Site Scripting (XSS)
2.7. (OWASP Top 10) _____ flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. _____ allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
Using Components with Known Vulnerabilities
2.9. (OWASP Top 10) Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a _____ is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
Injection
3.1. (OWASP Top 10 Attack Vectors) Almost any source of data can be an _____ vector, environment variables, parameters, external and internal web services, and all types of users. _____ flaws occur when an attacker can send hostile data to an interpreter.
Insufficient Logging&Monitoring
3.10. (OWASP Top 10 Attack Vectors) Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.
Broken Authentication
3.2. (OWASP Top 10 Attack Vectors) Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.
Sensitive Data Exposure
3.3. (OWASP Top 10 Attack Vectors) Rather than directly attacking crypto, attackers steal keys, execute man-inthe-middle attacks, or steal clear text data off the server, while in transit, or from the user's client, e.g. browser. A manual attack is generally required. Previously retrieved password databases could be brute forced by Graphics Processing Units (GPUs).
XML External Entities (XXE)
3.4. (OWASP Top 10 Attack Vectors) Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.
Broken Access Control
3.5. (OWASP Top 10 Attack Vectors) Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.
Security Misconfiguration
3.6. (OWASP Top 10 Attack Vectors) Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.
Broken Authentication
4.2. (OWASP Top 10 SecurityWeakness) The prevalence of _____ is widespread due to the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all stateful applications. Attackers can detect _____ using manual means and exploit them using automated tools with password lists and dictionary attacks.
Sensitive Data Exposure
4.3. (OWASP Top 10 SecurityWeakness) Over the last few years, this has been the most common impactful attack. The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm, protocol and cipher usage is common, particularly for weak password hashing storage techniques. For data in transit, server side weaknesses are mainly easy to detect, but hard for data at rest.
Broken Access Control
4.5. (OWASP Top 10 SecurityWeakness) Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers. Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs PUT, etc), controller, direct object references, etc.
Security Misconfiguration
4.6. (OWASP Top 10 SecurityWeakness) Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Automated scanners are useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services, legacy options, etc.
Cross-Site Scripting (XSS)
4.7. (OWASP Top 10 SecurityWeakness) XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two-thirds of all applications. Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET.
Insecure Deserialization
4.8. (OWASP Top 10 SecurityWeakness) This issue is included in the Top 10 based on an industry survey and not on quantifiable data. Some tools can discover deserialization flaws, but human assistance is frequently needed to validate the problem. It is expected that prevalence data for deserialization flaws will increase as tooling is developed to help identify and address it.
Using Components with Known Vulnerabilities
4.9. (OWASP Top 10 SecurityWeakness) Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. Some scanners such as retire.js help in detection, but determining exploitability requires additional effort.
Sensitive Data Exposure
5.3. (OWASP Top 10 Impacts) Failure frequently compromises all data that should have been protected. Typically, this information includes sensitive personal information (PII) data such as health records, credentials, personal data, and credit cards, which often require protection as defined by laws or regulations such as the EU GDPR or local privacy laws.
Security Misconfiguration
5.6. (OWASP Top 10 Impacts) Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. The business impact depends on the protection needs of the application and data.
Cross-Site Scripting (XSS)
5.7. (OWASP Top 10 Impacts) The impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim's browser, such as stealing credentials, sessions, or delivering malware to the victim.
Insecure Deserialization
5.8. (OWASP Top 10 Impacts) The impact of deserialization flaws cannot be understated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible. The business impact depends on the protection needs of the application and data.
Injection
6.1. (OWASP Top 10 How to Prevent) Preventing injection requires keeping data separate from commands and queries. • The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs). Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec(). • Use positive or "whitelist" server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications. • For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software. • Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
Insufficient Logging&Monitoring
6.10. (OWASP Top 10 How to Prevent) As per the risk of the data stored or processed by the application: • Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis. • Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions. • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar. • Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion. • Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later. There are commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.
Broken Authentication
6.2. (OWASP Top 10 How to Prevent) • Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks. • Do not ship or deploy with any default credentials, particularly for admin users. • Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords. • Align password length, complexity and rotation policies with NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies. • 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. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
Sensitive Data Exposure
6.3. (OWASP Top 10 How to Prevent) Do the following, at a minimum, and consult the references: • Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs. • Apply controls as per the classification. • Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen. • Make sure to encrypt all sensitive data at rest. • Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management. • Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS). • Disable caching for responses that contain sensitive data. • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2. • Verify independently the effectiveness of configuration and settings.
XML External Entities (XXE)
6.4. (OWASP Top 10 How to Prevent) Developer training is essential to identify and mitigate ___ . Besides that, preventing ___ requires: • Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data. • Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher. • Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet '___ Prevention'. • Implement positive ("whitelisting") server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes. • Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar. • SAST tools can help detect ___ in source code, although manual code review is the best alternative in large, complex applications with many integrations. If these controls are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block ___ attacks.
Broken Access Control
6.5. (OWASP Top 10 How to Prevent) Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. • With the exception of public resources, deny by default. • Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage. • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. • Unique application business limit requirements should be enforced by domain models. • Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots. • Log access control failures, alert admins when appropriate (e.g. repeated failures). • Rate limit API and controller access to minimize the harm from automated attack tooling. • JWT tokens should be invalidated on the server after logout. Developers and QA staff should include functional access control unit and integration tests.
Security Misconfiguration
6.6. (OWASP Top 10 How to Prevent) Secure installation processes should be implemented, including: • A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment. • A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks. • A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see A9:2017-Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions). • A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups. • Sending security directives to clients, e.g. Security Headers. • An automated process to verify the effectiveness of the configurations and settings in all environments.
Insecure Deserialization
6.8. (OWASP Top 10 How to Prevent) The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of the following: • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering. • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable. • Isolating and running code that deserializes in low privilege environments when possible. • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions. • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize. • Monitoring deserialization, alerting if a user deserializes constantly.
Using Components with Known Vulnerabilities
6.9. (OWASP Top 10 How to Prevent) 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 (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use. • Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component. • Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue. Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.
Injection
7.1. (OWASP Top 10 Is the Application Vulnerable?) 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 contextaware 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, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures. Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs. Organizations can include static source (SAST) and dynamic application test (DAST) tools into the CI/CD pipeline to identify newly introduced injection flaws prior to production deployment.
Insufficient Logging&Monitoring
7.10. (OWASP Top 10 Is the Application Vulnerable?) Insufficient logging, detection, monitoring and active response occurs any time: • Auditable events, such as logins, failed logins, and high-value transactions are not logged. • Warnings and errors generate no, inadequate, or unclear log messages. • Logs of applications and APIs are not monitored for suspicious activity. • Logs are only stored locally. • Appropriate alerting thresholds and response escalation processes are not in place or effective. • Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts. • The application is unable to detect, escalate, or alert for active attacks in real time or near real time. You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker.
Broken Authentication
7.2. (OWASP Top 10 Is the Application Vulnerable?) Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application: • Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. • Permits brute force or other automated attacks. • Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin". • Uses weak or ineffective credential recovery and forgotpassword processes, such as "knowledge-based answers", which cannot be made safe. • Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure). • Has missing or ineffective multi-factor authentication. • Exposes Session IDs in the URL (e.g., URL rewriting). • Does not rotate Session IDs after successful login. • Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren't properly invalidated during logout or a period of inactivity.
Sensitive Data Exposure
7.3. (OWASP Top 10 Is the Application Vulnerable?) The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws, e.g. EU's General Data Protection Regulation (GDPR), or regulations, e.g. financial data protection such as PCI Data Security Standard (PCI DSS). For all such data: • Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. Verify all internal traffic e.g. between load balancers, web servers, or back-end systems. • Is sensitive data stored in clear text, including backups? • Are any old or weak cryptographic algorithms used either by default or in older code? • Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing? • Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing? • Does the user agent (e.g. app, mail client) not verify if the received server certificate is valid?
XML External Entities (XXE)
7.4. (OWASP Top 10 Is the Application Vulnerable?) Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if: • The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor. • Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet 'XXE Prevention'. • If your application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable. • If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework. • Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack.
Broken Access Control
7.5. (OWASP Top 10 Is the Application Vulnerable?) 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 of the limits of the user. Common access control vulnerabilities include: • Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool. • Allowing the primary key to be changed to another users record, permitting viewing or editing someone else's account. • Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user. • Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation • CORS misconfiguration allows unauthorized API access. • Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.
Security Misconfiguration
7.6. (OWASP Top 10 Is the Application Vulnerable?) The application might be vulnerable if the application is: • Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services. • Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges). • Default accounts and their passwords still enabled and unchanged. • Error handling reveals stack traces or other overly informative error messages to users. • For upgraded systems, latest security features are disabled or not configured securely. • The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values. • The server does not send security headers or directives or they are not set to secure values. • The software is out of date or vulnerable (see A9:2017-Using Components with Known Vulnerabilities). Without a concerted, repeatable application security configuration process, systems are at a higher risk.
Cross-Site Scripting (XSS)
7.7. (OWASP Top 10 Is the Application Vulnerable?) There are three forms of XSS, usually targeting users' browsers: Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim's browser. Typically the user will need to interact with some malicious link that points to an attackercontrolled page, such as malicious watering hole websites, advertisements, or similar. Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk. DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs. Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user's browser such as malicious software downloads, key logging, and other client-side attacks.
Insecure Deserialization
7.8. (OWASP Top 10 Is the Application Vulnerable?) Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks: • Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization. • Typical data tampering attacks, such as access-control-related attacks, where existing data structures are used but the content is changed. Serialization may be used in applications for: • Remote- and inter-process communication (RPC/IPC) • Wire protocols, web services, message brokers • Caching/Persistence • Databases, cache servers, file systems • HTTP cookies, HTML form parameters, API authentication tokens
Using Components with Known Vulnerabilities
7.9. (OWASP Top 10 Is the Application Vulnerable?) You are likely vulnerable: • If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies. • If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries. • If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use. • If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities. • If software developers do not test the compatibility of updated, upgraded, or patched libraries. • If you do not secure the components' configurations
Injection
8.1. (OWASP Top 10 Example Attack Scenarios) Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; Scenario #2: Similarly, an application's blind trust in frameworks may result in queries that are still vulnerable, (e.g. Hibernate Query Language (HQL)): Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); In both cases, the attacker modifies the 'id' parameter value in their browser to send: ' or '1'='1. For example: http://example.com/app/accountView?id=' or '1'='1 This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data, or even invoke stored procedures.
Insufficient Logging&Monitoring
8.10. (OWASP Top 10 Example Attack Scenarios) Scenario #1: An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue. Scenario #2: An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password. Scenario #3: A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank.
Broken Authentication
8.2. (OWASP Top 10 Example Attack Scenarios) Scenario #1: Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid. Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication. Scenario #3: Application session timeouts aren't set properly. A user uses a public computer to access an application. Instead of selecting "logout" the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.
Sensitive Data Exposure
8.3. (OWASP Top 10 Example Attack Scenarios) Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. Scenario #2: A site doesn't use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer. Scenario #3: The password database uses unsalted or simple hashes to store everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.
Broken Access Control
8.5. (OWASP Top 10 Example Attack Scenarios) Scenario #1: The application uses unverified data in a SQL call that is accessing account information: pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); An attacker simply modifies the 'acct' parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user's account. http://example.com/app/accountInfo?acct=notmyacct Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page. http://example.com/app/getappInfo http://example.com/app/admin_getappInfo If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw.
Security Misconfiguration
8.6. (OWASP Top 10 Example Attack Scenarios) Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren't changed the attacker logs in with default passwords and takes over. Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application. Scenario #3: The application server's configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable. Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.
Insecure Deserialization
8.8. (OWASP Top 10 Example Attack Scenarios) Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the "R00" Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server. Scenario #2: A PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state: a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} An attacker changes the serialized object to give themselves admin privileges: a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Using Components with Known Vulnerabilities
8.9. (OWASP Top 10 Example Attack Scenarios) Scenario #1: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are: • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches. • While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices). There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from the Heartbleed vulnerability that was patched in April 2014.