Recently, we have been asked to go through the OWASP TOP-10 2013 checklist in order to validate security and robustness of a Jspresso application deployed as a Docker image. Of course, the answers might not be the same for each and every application but some of them are inherent to the use of the Jspresso framework. Let’s go through them and see how Jspresso can bring minimal security to your developments at no cost.
Let’s review them
« 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 »
« Preventing injection requires keeping untrusted 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. Be careful with APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI provides many of these escaping routines.
Positive or “white list” input validation is also recommended, but is not a complete defense as many applications require special characters in their input. If special characters are required, only approaches 1. and 2. above will make their use safe. OWASP’s ESAPI has an extensible library of white list input validation routines. »
Secure: Jspresso exclusively access its data-store using bind variables. User data is never concatenated into data queries.
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. »
« The primary recommendation for an organization is to make available to developers:
A single set of strong authentication and session management controls. Such controls should strive to:
meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See A3. »
Secure: Jspresso authentication and session management is based on JAAS. A Jspresso application can plug-in any JAAS compliant authentication module (Database, LDAP, Kerberos, …)
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. There are two different types of XSS flaws: 1) Stored and 2) Reflected, and each of these can occur on the a) Server or b) on the Client.
Detection of most Server XSS flaws is fairly easy via testing or code analysis. Client XSS is very difficult to identify. »
« Preventing XSS requires separation of untrusted data from active browser content.
Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications require special characters in their input. Such validation should, as much as possible, validate the length, characters, format, and business rules on that data before accepting the input.
For rich content, consider auto-sanitization libraries like OWASP’s AntiSamy or the Java HTML Sanitizer Project.
Consider Content Security Policy (CSP) to defend against XSS across your entire site. »
Secure: Jspresso uses of the OWASP java-html-sanitizer library in order to expunge any typed-in incoming value from malicious code.
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 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. »
« Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object. »
Secure: Jspresso never use explicit IDs (either synthetic or natural IDs) to communicate with the client. Moreover, the complete application state of a user is kept on the server (stateful architecture). The client can only use actions he has been provided with, that are in coherence with the current state on the server.
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. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc. »
« The primary recommendations are to establish all of the following:
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 passwords used in each environment). This process should be automated to minimize the effort required to setup a new secure environment.
A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. This needs to include all code libraries as well (see new A9).
A strong application architecture that provides effective, secure separation between components.
Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches. »
Secure: Docker allows to see all dependencies and contents, and to run check of images. Images are built once and used on every environment.
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 also usually hard to exploit. »
« The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:
Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
Ensure strong standard algorithms and strong keys are used, and proper key management is in place. Consider using FIPS 140 validated cryptographic modules.
Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data. »
Secure: there is no sensitive data in default Jspresso App. When necessary, developers can encrypt data. as far as password encryption is concerned, the scheme is generally an option of the chosen module.
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 (URLs) or functions exist to attack. »
« Your application should have a consistent and easy to analyze authorization module that is invoked from all of your business functions. Frequently, such protection is provided by one or more components external to the application code.
Think about the process for managing entitlements and ensure you can update and audit easily. Don’t hard code.
The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
If the function is involved in a workflow, check to make sure the conditions are in the proper state to allow access.
NOTE: Most web applications don’t display links and buttons to unauthorized functions, but this “presentation layer access control” doesn’t actually provide protection. You must also implement checks in the controller or business logic. »
Secure: Jspresso has static security easily readable and one central mandatory access point security enforcement (pluggable security plugin).
A8 Cross-Site Request Forgery (CSRF)
« CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action.
Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.
Detection of CSRF flaws is fairly easy via penetration testing or code analysis. »
« Preventing CSRF usually requires the inclusion of an unpredictable token in each HTTP request. Such tokens should, at a minimum, be unique per user session.
The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is more prone to exposure.
The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs a greater risk that the URL will be exposed to an attacker, thus compromising the secret token.
OWASP’s CSRF Guard can automatically include such tokens in Java EE, .NET, or PHP apps. OWASP’s ESAPI includes methods developers can use to prevent CSRF vulnerabilities.
Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF. »
Secure: client / server doesn’t communicate using REST, but only by HTTP POST. Moreover the payload doesn’t use any known object ID but server generated tokens that are unique per session and maintained in a server-side state. This makes it virtually immune to CSRF.
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.. »
« One option is not to use components that you didn’t write. But that’s not very realistic.
Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. So upgrading to these new versions is critical. Software projects should have a process in place to:
Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).
Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component. »
Secure: all java dependencies are versioned and checked in the project descriptors. All OS components are written in the Dockerfiles. After the Docker Image is built and checked, no modification can be done.
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. »
« Safe use of redirects and forwards can be done in a number of ways:
Simply avoid using redirects and forwards.
If used, don’t involve user parameters in calculating the destination. This can usually be done.
If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL.
Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe.
Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust. »
Secure: Jspresso applications are single page applications. No redirect nor forward are even possible from the client.. Moreover, before displaying a screen, Jspresso checks for authorizations.