XML External Entities (XXE)   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.   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.   How to Prevent Developer training is essential to identify and mitigate XXE. Besides that, preventing XXE 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 'XXE 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 XXE 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 XXE attacks.   Example Attack Scenarios Numerous public XXE issues have been discovered, including attacking embedded devices. XXE occurs in a lot of unexpected places, including deeply nested dependencies. The easiest way is to upload a malicious XML file, if accepted: Scenario #1: The attacker attempts to extract data from the server: Scenario #2: An attacker probes the server's private network by changing the above ENTITY line. Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file     Billion laughs attack The example attack consists of defining 10 entities, each defined as consisting of 10 of the previous entity, with the document consisting of a single instance of the largest entity, which expands to one billion copies of the first entity.

Broken Access Control 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.   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.   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.   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 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.   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.   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.   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.

Cross-Site Scripting (XSS) Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks.   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.   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).   Example Attack Scenario Scenario 1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping: The attacker modifies the ‘CC’ parameter in the browser to:  This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session. Note: Attackers can use XSS to defeat any automated CrossSite Request Forgery ( CSRF) defense the application might employ.   There are two stages to a typical XSS attack: To run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject malicious code (payload) into a web page that the victim visits. After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.

Insecure Deserialization Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code.   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   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.   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";}   Equifax hack A well-known Insecure Deserialization example is the Struts 2 remote execution incident, which gained worldwide attention in 2017 for being the attack vector exploited in the Equifax hack.

Using Components with Known Vulnerabilities While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.   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 (see A6:2017-Security Misconfiguration).   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.   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.   Example Attack Scenarios - Heartbleed Heartbleed a flaw in the OpenSSL cryptographic software library discovered in 2014. This software component, whose main purpose is to protect data on web applications, had a security weakness allowing attackers to steal the information usually protected by SSL/TLS encryption. This bug allowed anyone on the Internet to read the memory of systems protected by the vulnerable versions of the OpenSSL software, compromising secret keys used to identify service providers and encrypt the traffic, names and passwords of users and the actual content. By eavesdropping on communications, attackers could steal data directly or even impersonate the services or users. At the time this issue was discovered, half a million widely trusted websites were vulnerable to the Heartbleed bug. As of early 2017, a great number of companies (about 200,000) were still using a component with a known vulnerability.

Insufficient Logging & Monitoring 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.   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 (see A3:2017- Sensitive Information Exposure).   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.   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.