Reflecting back to the Top 10 Web Application Vulnerabilities, I am going to go through each of the vulnerability and put some IT security advice on how we can improve any web application security. There are total of ten vulnerabilities and I am going to go from the least popular to the most popular one. As this can be quite a technical document, I will not go in depth on how you can have a better web application security to take care of the general readers of my blog. Let’s not waste time and head down and see what are my advices to improve a web application security.
Web Application Security – Tips
10. Unvalidated Redirects and Forwards
Unvalidated redirects and forwards are vulnerability where the user is redirected to another page that is not initially set by the web application. By being able to do so, an attacker can redirect the user to a malicious website and then inject Malware into their system. My advice for to improve the web application security for this vulnerability is:
- Do not use redirect or forward if possible.
- Using redirect or forward solely to redirect a website and NOT passing any user parameters or any sensitive information at all. Just redirect and start all over from there. This is usually do-able and if possible, should not move to the next advice.
- Map all the variables into something else during redirection. This means not to use terms like ‘username’, ’email’ but rather something meaningless.
9. Insufficient Transport Layer Protection
If you login into any banking application or your social network, you will see that your URL changed from HTTP to HTTPS. Why is it so? It is because the transport layer protection had just activated for a better web application security and it is also known as SSL (Secure Socket Layer). The purpose of having SSL is to encrypt all your data along the HTTP transmission layer and if the attacker manage to tap your connection, what they will see is gibberish data because it is encrypted. Hence, you should configure your application to enable SSL protection. Another thing that you should take note here is the algorithm that you are going to use for your SSL protection is at least FIPS 140-2 SSL certificate to ensure you have a good web application security.
8. Failure to Restrict URL Access
In your application, you have roles for each user. Sometimes, you will have the role of ‘End-User’ where they have limited access to your application. When you want to impose this kind of roles management, in every page of your web application, you should do a checking whether the user has the permission to access the restricted page. It is advisable that you perform a check on every page where you can also kick anonymous user that does not login to your page but have the access out of nowhere. Hence, whether it is a restricted page or not, from the aspect of web application security, each of your page should have a function to check the accessibility of the user to prevent them from accessing a restricted site.
7. Insecure Cryptographic Storage
Some developers are smart enough to encrypt all the sensitive data but also careless enough to leave the encryption key on the same server. What does this mean? Instead of the hacker trying to break your encrypted data, the hacker will instead trying some brute force technique to break the password you used to protect your keys. To me, there is no point encrypting your data and it does not make any sense in better web application security where you perform encryption and leave the key there. Let’s put it this way, what is the point of you locking your door where you left your keys under the carpet? Thus, there should not be a practice to store your encryption keys on the same server you kept the encrypted data. It is best you used some hardware devices that act as key containers to store your keys. These hardware devices are known as HSM (Hardware Security Module) but they will not come cheap. As a result, most application does not have the budget for this device and it is advisable not to mix your encryption keys with your encrypted data as the simplest way to give you a good web application security.
To have a better web application security, there are many components that required configuration because web application comes with a lot of components. Configuration such as web server, database server, OS, and other components that you might have. The first rule here is never use the default username and password. For instance if you use the MySQL in XAMPP usually comes with the username ‘root’ and an empty password. Never use that. You should change the root password and create another database user for your application having the restriction to only access his own schema. You should also define the permission at the OS level for all the files and folders especially related to your application server. Lastly, stacktrace message should not be displayed to your users in the application. If you have an error, just tell them ‘The application had just encountered an unexpected error.’ Keep the stacktrace in the log securely. You don’t want to tell the attacker that you had a bad configuration in your web application, do you?
5. Cross-Site Request Forgery (CSRF)
Performing a CSRF attack is quite difficult. Attackers need to do a lot of prediction and guessing in order to successfully launched the attack. While it is hard to make a CSRF, it also result that a CSRF damage can be quite severe. As CSRF is not done at the web application side, it is not easy to prevent this attack. In order for the application server to validate that the next request is from the application itself, the developer can pass some hidden value in the form using “POST” method instead of “GET” method. The hidden value should be a unique authentication token that only the web application at the client side and the server side know. With this, if someone try to inject some CSRF script, the application server can check the unique authentication token first before running the script and this should add up one more point for your web application security.
4. Insecure Direct Object References
In point number 8, we were discussing about the failure to restrict URL access. Some developers did check the permission on every page but neglecting the object sometimes. Preventing the insecure direct object references is more or less like restricting URL access method. The only difference is restricting a page and an object. Thus, during the declaration of an object, the developer should check whether the requester has the permission to use the object or not. By this, it will prevent any anonymous user from using an object in your web application.
3. Broken Authentication and Session Management
Broken authentication and poor session management handling is mainly caused by the poor password creation and this can be one of a critical web application security issue. As a developer, he should impose a strict password criteria to ensure that all the users browsing around the system has a strong password. These passwords should also be encrypted. Developers should also threat the session ID as an important item and not to pass it around on the URL. If a session is stolen, that means an identity is stolen. It is reminded as well that data should be encrypted at all time along the HTTP transmission as mentioned in point number 9. Last but not least, the session should be destroy when the web browser closed. This is to ensure that, the next person who uses the web browser does not have the privilege to use your application as the previous user’s identity.
2. Cross-Site Scripting (XSS)
XSS is a very popular for of attack. An application is easily affected with XSS and at certain level, it is easy to detect as well. It can be checked using some tools to scan but still, not as effective as source code reading. XSS can be very harmful to end user as it it possible to redirect the user to some malicious website and caused them to get infected. To prevent XSS from occurring in your application, the developer should escape all the special characters. You should make the special character such as (> ” ‘ / \) are known as input to your application and NOT as part of their script. Escaping character should also be done at every input box and the parameter pass on the URL. It is also best to restrict your user from using special characters but not very effective as at times, in order to have strong password, special character is needed.
As mentioned before, there are many types of injection around. Injection works the same as XSS, just that the difference is the severity in the web application security. Recap again from last week, when an injection occurred, that means the attacker is at the database layer or also known as final execution layer. To prevent any injection, all the special character should be escaped just like preventing XSS. In addition to protecting SQL injection, it is extremely advisable to all the developers that you should use a ‘prepared statement (known as AddParameter in .NET framework)’ before executing the SQL. This method is very useful to prevent SQL injection and should not be neglect. Another way to prevent SQL injection is to write a stored procedure, but in a low traffic application, usually there is not a necessity to have stored procedure. Injection can caused a severe damage and hence you can see that many developers are trying to research for the best method to prevent this vulnerability.
Web Application Security – Conclusion
Web application is an application that runs 24×7. Users constantly accessed your application and go through your web application security whether you are sleeping, eating or working. To the hacker’s point of view, the best application to hack is the web application as there are many vulnerabilities. As the author of a IT security blog, I would like to advise all the web application developers around to seriously consider the method mentioned above on how to improve a web application security.