Countering the OWASP top 10 attacks

The following chapter gives hints on how to counter the top 10 attacks identified by the OWASP organization. The OWASP Top 10 Project is driven by the MITRE Vulnerability Trends and tries to summarize the top web application vulnerabilities and give some advice on how to address them. The OWASP Top 10 Project has been adopted by the PCI Data Security Standard. The table below shows the current Top 10 vulnerabilities.

Note that some of the vulnerabilities listed require no attention since they are solved implicitly by using nevisProxy in the first place.

Attack	Remedy
A1 - Injection "Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws."	Use aModsecurityFilterwith the most actual rules which can be downloaded from http://www.modsecurity.org/. Use the InputValidationFilter for application-based fine-granularity issues that are not covered by the modsecurity rules. Use URL-signing/encryption and/or form-signing to prevent malicious query string injection. Poor error handling within the application makes injection flaws easier to discover. Make sure to use an ErrorFilter to prevent information leakage. * Use also the JsonFilter or the SoapFilter if your application uses these content types.
A2 - Broken Authentication and Session Management "Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique."	User authentication and credential verification shall be delegated to Nevis, implemented by nevisProxy using an IdentityCreationFiler and nevisAuth providing the necessary user authentication workflow supporting strong user authentication and various account management functions, see also chapters: Authentication concepts. nevisProxy uses a secure, true-random session cookie, an TLS session, or a 2-of-3 (session cookie, TLS session, IP address) for session binding. Session binding is renegotiated after successful authentication and/or a configurable interval. The application's session cookies must not be forwarded to the client. Use the CookieManager in the Http(s)ConnectorServlet or a dedicated CookieCacheFilter to store the application cookies within nevisProxy and to prevent them from reaching the client. * Enable brute-force detection for weak authentication methods, see the chapter Attack prevention strategies by mod_qos.
A3 - Cross-Site Scripting (XSS) "XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content."	Use aModsecurityFilterwith the most actual rules, which can be downloaded from http://www.modsecurity.org/. Use the ParameterValidationFilter and HeaderValidationFilter for application-based fine-grained issues that are not covered by the ModSecurity rules. Set thehttpOnlyflag for the session cookie and/or enable secure client session identification, see the table: UserAgent attributes Configure a content security policy, see the chapter HTTP security headers. * Ensure that you have encoded all content within the login page as well.
A4 - Insecure Direct Object References "Applications frequently use the actual name or key of an object when generating web pages. Applications don't always verify if the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified."	Allow access to known resources only. Use a ParameterValidationFilter to restrict user input about how to generate a white list of all URLs. Prohibit exposure of such references by validating output based on regular expressions with aRewriteFilter(e.g. do not allow file paths in a web page). URL-signing/encryption to only allow URLs that appear in the HTML content. Allow access to authenticated users only, see the chapter Authentication concepts. Form-signing prevents from the manipulation of read-only values within HTML forms.
A5 - Security Misconfiguration "Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly."	Allow access to known resources only. Configure known URLs only and/or generate a white list of all URLs, see the chapter URI whitelisting. Allow access to authenticated users only, see the chapter Authentication concepts. Ensure to use an ErrorFilter to prevent information leakage. Access to the backend via nevisProxy forbids all ports/URI not configured in nevisProxy. Deny repeated access violations preventing scanner from detecting unprotected resources, see the chapter Attack prevention strategies by mod_qos. Many attack patterns are implicitly prevented by nevisProxy.
A6 - Sensitive Data Exposure "The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are usually also hard to exploit."	Use HTTPS only and redirect user from plain text ports to HTTPS . Use suitable TLS cipher settings, e.g. Diffie-Hellman based algorithms to allow perfect forward secrecy. Use a HSM to protect your proxy keys. Disable autocomplete within the login page.
A7 - Missing Function Level Access Control "Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages ) to restrict access to certain resources. Allow access to known resources only. Configure known URLs only and/or generate a white list of all URLs, see the chapter URI whitelisting. Use URL-signing/encryption of application URLs to prevent forceful browsing, see the chapter Configuring URL signing and form signing.
A8 - Cross-Site Request Forgery . * Use URL-signing/encryption with a per-session key.
A9 - Using Components with Known Vulnerabilities "Virtually every application has these issues because most development teams don't focus on ensuring their components/libraries are up to date. In many cases, the developers don't even know all the components they are using, never mind their versions. Component dependencies make things even worse."	Ensure to use an ErrorFilter to prevent information leakage. Implement the countermeasures defined for all other OWASP top 10 issues. Implement black list patterns for known security issues of your applications.
A10 - Unvalidated Redirects and Forwards "Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page. Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages."	Use aParameterValidationFilterto restrict user input. URL-signing/encryption and form-signing/encryption.