More and more applications are becoming internet enabled. To optimize operations expenditure, enterprises have started aggressively promoting web sites with self-service capabilities. It could be a simple activity such as gathering information such as case/claim status, submitting claim/service request or paying your bills/buying products online.
More personal/financial information information is available online than ever before. This has lead to a spurt in cyber crimes. Application security is becoming an enterprise priority. Last year in July time frame, I was looking for a mechanism to baseline my product’s security compliance. I found the answer in OWASP’s Application Security Verification Standard. I used 2.0 as reference as 3.0 was not published when i started. However for the purposes of this blog post I am going to refer 3.0 standard.
Let me walk each verification requirement one by one. For each area I will cover the ones I found relevant.
V1: Architecture, design and threat modelling
Requirements 1.1 to 1.5 basically expect you to know your application, its purpose, its technical components(user interface, business layer/logic, data tier, external integration touch points etc). There should be clear delineation between which components are in-house and which ones are 3rd party/collaborating components. This helps establish security zones within your environment.
Requirement 1.6 helps determine different types of users who have access to your application. What aspects of your application can they access? This helps establish application boundaries. Your aim should be to ensure that the end user cannot access anything beyond what he or she is privileged to access. This is easier said than done. My product has a single application catering to our self-service, operations and product configuration users. Ideally I would like to expose only my self-service features on internet and keep the rest within my intranet zone. But we do not live in a perfect world.
Requirement 1.7 lays a solid foundation for simplifying application access control. My application has 3 to 4 locations within its code base for defining access control. This makes the entire access control setup complicated and increases the chances of putting in inadequate or incomplete access control definitions due to oversight.
Requirement 1.10 expects us to ensure that the client side code does not contain any sensitive information. In today’s world of rich client web development or high use of AJAX based applications, the need for functionality could lead to such information being made available within the client side code by oversight.
V2: Authentication Verification Requirements
All requirements are pretty standard authentication requirements. We stored the passwords using one way bcrypt encryption. To provide for multi-factor authentication and other security measures like fraud detection and security questions we used RSA’s Adaptive Authentication.
V3: Session Management Verification Requirements
Most of the requirements are standard ones. I would like to highlight requirements 3.3 and 3.4. Everyone complies to an inactive session timeout requirement, however very few look at absolute session timeout value. The recommended value for active session time out is a matter of debate. I think the value should be set taking into consideration the end user. A self service user will not remain logged in for long. 30 minutes should be an acceptable value. An operations user on the other hand will remain logged in for 8/9 hours at least. So his/her timeout value should be greater, probably 10/12 hours. Alternatively the value could be aligned with their break times, say every 2 hours or every 4 hours.
V4: Access Control Verification Requirements
I found this section the most critical and with the greatest impact as its implementation is completely in the hands of the developer. Requirements 4.1 to 4.8 are standard.
- User access to a particular function as represented by a web URL
- User access to data acted upon by the function
The first can be a generic function implemented in a common function. The second can vary from being very generic to being repetitive to being very specific to a particular web URL. The access control security design should be implemented taking both into consideration. To understand let’s take the following example,
Let’s assume the URL above exposes claim data for claim id = 112. The logged in user will need two kinds of access. One to access the URL /claim/? and also he/she should have appropriate access privileges to view claim data for id = 112.
Requirement 4.10 expects data used for determining user access control privileges should be protected from inadvertent or malicious access. Ideally such data should not be exposed to the end user. In case exposure if unavoidable, I recommend using some kind of encryption mechanism to prevent malicious use.
Requirement 4.11 is similar to 1.7. As discussed for requirement 4.9, some aspects are generic and can be retained in a single location, it will be difficult to keep very specific requirements at a single location.
Requirement 4.12 is important, but i doubt it is adhered to in most applications. Leave alone successful authentication, even authentication failures do not get logged. Logging all application accesses help in forensic analysis in case of a security hack.
Requirement 4.13 states the incorporation of aniti-CSRF token to prevent CSRF hacking. Useful requirement but is extremely difficult to implement in a AJAX intensive application. I had a single web page generating 10 to 20 AJAX calls.
Requirement 4.16 expects all information sent by client to undergo context sensitive validation. For example if I am retrieving claim information by passing claimID from the client side, the server side code needs to validate if the person accessing this information is authorized to view this information. The next step would be to determine what role is associated with the user to determine what the user authorization privileges are. More details on this will come to fore when when cover V5 section.
V5: Malicious Input Handling Verification Requirements
Requirement 5.1 (buffer overflows) is applicable for Java EE applications using native methods or making system calls. Otherwise Java EE applications are safe buffer overflow attacks.
Requirement 5.3 expects request rejection and logging of all server side validation failures. Although a good practice, I have rarely seen this implementation enforced in projects.
Requirement 5.5 expects input validation routines to be put in place at the server side. The rule is very clear and simple however with the advent of rich client side scripting and our tendency to use client side validation to achieve responsive UI, I do think there is a tendency to avoid writing full fledged server side validation routines. We need to put in an exact replica or more (in case certain functionalities are not testable at the client end) to ensure validation to business logic. All inputs received from an external source (normally a browser) should be treated with suspicion. “In God we trust the rest we validate” should be the motto.
Requirement 5.10 expects all SQL queries should be protected using prepared statements and query parameterization. This is an easy requirement to implement except in the case of search like UI. If the UI offers multiple optional items, it becomes necessary to create a query dynamically and typically developers then to avoid prepared statements and leaving a vulnerability open for hackers to exploit. There is no easy way out, because as the number of input search parameters increase so does the complexity and adding a prepared statement with binding parameters option becomes too difficult to implement.
This post can go on and on. At this point I will stop and will update it whenever time and new ideas permit.