Missing Elements in Creating Secure Web Applications
Today’s world web applications are dynamic with a lot of sensitive data and business critical data that continually moves from browser to server and back to browser. A security flaw in your application can lead to data theft. Today, application developers are more focused on creating web applications that provide increased security. Architects recommend implementing static code analysis tools like fortify, which will scan your code for security loop holes. Organizations feel proud to use tools like fortify, hoping it will fix all security loop holes in their web applications. There are many cases where your static code analysis tools are not good at catching security loop holes. This blog talks about different cases where security vulnerabilities are not caught by static code analysis tools and highlight the importance of having a security focused design, security focused code reviews and security focused testing.
Case 1: Flaw in validating user credentials
See code below:
From the above code, a user is valid if the given user id and password exists in the database or else becomes an invalid user. There are basic security flaws in this code. Exception handling is abused with empty catch block. While executing this piece of code, if the database is down or there is an exception while executing Line 3, then the program control will move from line 3 to empty catch block and then out of catch block, unless the treating user has logged in successfully . This kind of security flaw which arise out of poor coding practices cannot be detected by your static code analysis tools like fortify. The only way to catch this kind of security flaw is to have security focused code reviews.
Case 2: Proceeding to checkout
The process of placing an order involves the following stages:
- Step 1 – Browse the product catalog and add items to the shopping basket.
- Step 2 – Return to the shopping basket and finalize the order.
- Step 3 – Enter payment information.
- Step 4 – Enter delivery information.
As part of the designing checkout process, developer’s team came out with a strong front end validation to disallow users from accessing any step without completing previous steps. With strong front end validation, the design looks complete, but there is a basic security flaw in this design.
Hackers can easily attack this kind of design. Hackers will complete Step 1, Step 2 and collect the session id that is used for Step 1 & Step 2. Using this session id, hackers will prepare an http request for Step 4 and send it to the server without performing Step 3. As there is no back end validation to check whether Steps 1 , 2 & 3 are executed before performing Step 4. Step 4 will execute without performing Step 3, ultimately leading to a serious security flaw where one can buy items without making payments.
This kind of design scenario is common where we have strong front end validations without any back end validations, leading to security loop holes. Static code analysis tools are not effective at identifying this kind of security flaw and one should have strong knowledge on security focused design.
Case 3: Beating a business limit
There is a requirement to prevent users from transferring money greater than $10,000. Any transfer larger than this requires a senior manager approval. To fulfill this requirement, the code below has been written:
The developer assumed that this transparent check was bulletproof. No transaction greater than the configured threshold could ever escape the requirement for secondary approval.
The developer’s assumption was flawed because he had completely overlooked the possibility that a user would attempt to process a transfer for a negative amount. Any negative number will clear the approval test, because it is less than the threshold. However, the banking module of the application accepted negative transfers and simply processed them as positive transfers in a opposite direction. Hence, any user wishing to transfer $20,000 from account A to account B could simply initiate a transfer of -$20,000 from account B to account A, which had the same effect and required no approval. The anti-fraud defenses built into the application could be trivially bypassed!
These kinds of issues are well caught with security focused testing and not with static code analysis tools.
Case 4: Logging sensitive information
Hackers hunt for active session id's. Hackers prepare http requests and send to the server along with the active session id. The server will not stop processing this request as the request is holding an active session id. Where do hackers get an active session id in the first place?
Application developer’s mistakes assist hackers to get active session ids. It is very important not to log passwords and session ids in log files. Static code analysis tools will not catch mistakes like logging sensitive information. This kind of mistakes can be avoided only through security focused code reviews.
Case 5: Using default passwords
When I joined prokarma, I was given a new mail id and a default password for my mail box. When I logged in with my default password, the mail box didn’t force me to change to a new password. Since changing a default password is created, optional users have a tendency to ignore it. Any user who knows your mail id can try with a default password and be successful in accessing your mail box. Later we migrated to “office 365”, which forces users to change their default password and we don’t have this design mistake in office 365.
Security focused design is required to avoid this kind of security loop holes when creating web applications.
In all above cases, static code analysis tools fail to detect security flaws. One should follow a security focused design, security focused code reviews and security focused testing to detect these kind of security flaws before going to production. Security focused design and security focused code reviews are often overlooked by architects and developers. They are vital and crucial in enterprise java architecture.