Web application is exposed to a lot of web application vulnerabilities as it is a public service that run for 24×7 if no interruption occurred. Due to that reason, it gives the attacker plenty of trial and error before the real attempt to take advantage of the web application vulnerabilities. In this entry, I would like to share with you what I understand about web application vulnerabilities and below is a list of them counting down from least popular to most popular. As this can be a long entry, you can grab a cup of coffee or biscuits as well before you start reading. Just joking :).
The Web Application Vulnerabilities
10. Unvalidated Redirects and Forwards
In common, web application usually redirects or forwards users to another page or website and then use the data within to determine where the user should go. If the data is not validated properly, it could redirect the user to some malicious website as the data mentioned is going to determine where the user will go. By accessing the malicious URL, it is highly potential that the user will get his computer infected with Malware. This could potentially lead to a web application vulnerabilities which is phishing attack.
Example of attack:
9. Insufficient Transport Layer Protection
Applications sometimes failed to protect the transport layer well. The transport layer that I mean here is using SSL/TLS as a methodology to protect the web application vulnerabilities specifically on the data when transmitting between client and server or vice-versa. The purpose of this method is of course to encrypt the transmitting data. If the data are not encrypted, it can be easily stolen via man in the middle attack. In addition to this web application vulnerabilities, configuration of this method can be vital. Application should always use a strong encryption algorithm (at least FIPS 140-2) and it should also never use expired or invalid certificate. This is because it will cause the users to force themselves to accept the invalid certificate in order to browse the application. By doing this, it will eventually result in phishing attack easily as the user already have the habit to accept invalid certificates. As a conclusion to this, it is important to protect the transport layer in order to keep the data confidential and secured.
8. Failure to Restrict URL Access
Failure to restrict URL access here means that the application failed to restrict certain users who are not supposed to view restricted page if one of the web application vulnerabilities to be watched. In other words, this means the user might not have the privilege to access or it could also possible that the user did not perform any authentication also able to gain access to the restricted page. If the attacker found out the page is vulnerable to this attack, he can just forge the URL to access the page especially administrator’s page. Once the attacker is there, he can just do whatever settings or actions that supposedly only administrator can perform. Thus, developer should ensure the restricted page is only accessible by the right person to prevent one of the web application vulnerabilities.
7. Insecure Cryptographic Storage
Passwords, credit card information and other sensitive data should be encrypted before storing into the database. If let say the attacker somehow manage to get the data in your database, it is still not completely compromised as it is already encrypted and the attacker will require a long long time to decrypt it. This of course only can happen if you encrypt the data properly with strong encryption algorithm and securely store the encryption key. In certain application, the developer did encrypt the data but left the key together with the data. Hence, the encrypted data can be easily decrypted by running some brute force to crack down the password the encryption key. The encryption key should always be separated from the application server. It is also recommended to use a hardware key container (HSM – Hardware Security Module) in your application to bring the security level of your application to another level.
6. Security Misconfiguration
Having a good security also means having a good security configuration. The security configuration here means that everything under the sky that is deployed to your web application such as web server, application server, database, files and folders, and also framework are all properly configured. This includes as well ensuring all the items mentioned are fully updated as the older version tend to have vulnerabilities that attacker can take advantage of. The usage of default account and password are strictly not recommended. Not only that, the error stack trace should be managed properly in the way that it does not exposed to the user. Attacker will love to see all the stack trace message as it can give them more clue on how to attack your web application. Therefore, only display a very high level message or general error message to the user. Security configuration needed to be planned properly and check carefully before deploying the web application to the public.
5. Cross-Site Request Forgery (CSRF)
The cross-site request forgery is quite a tricky vulnerability. What this web application vulnerabilities does is that it will forge the request through web URL when the victim clicked on any infected image link or even through cross-site scripting (XSS). This will change information that he did not actually requested to as an authenticated user. However, this require the user to be authenticated first by logging into the application and stored his authentication token into the session cookie.
Example of attack:
The user login into the application at www.myapp.com
The user then does his normal web browsing probably googling some image and click on a panda image that he found interesting.
Not realizing that the panda link is actually look like this in the html code:
<img src=”http://www.myapp.com/main?transferfund=1500&destination=hackerAcc” />
Once the image is clicked, the user will immediately perform the transfer to hacker’s account.
The drawback is that the attacker still need to guess the criteria to forge into the URL. Above is just an illustration as transferring funds should not be that simply implemented. However do bear in mind that if the attacker can do something that requires your authentication without him authenticating first, isn’t that sounds dangerous?
4. Insecure Direct Object References
Usually, when a developer developed an application that call for certain object, he does not always verify the person who call the object whether he has the authority to use the object or not. If the beginning of the object does not verify the caller of a particular object, it could lead to revealing sensitive information that are not supposed to reveal. For instance, an object that calls a function to show all information regarding your banking account with the SQL statement:
“select * from account where account_id=(some variable call it ‘X’)”
The object should be anticipating the account_id from the web browser and let say the developer designed in the way the account_id will be pass this way:
The attacker can just modify the URL account_id to something else to see other people’s account information for example:
Object should be treated like any web pages as well and hence it should verify the caller of the object whether he has the authority to access the object to prevent the web application vulnerabilities.
3. Broken Authentication and Session Management
In a web application, usually the developer will write their own authentication and session management schemes. That includes login, logout, session timeout, recover password, secret question and so on. The thing that caused the authentication to break is when they are not managed properly. For example, the credentials are not stored in the encrypted or hashed mode. Or even some application has a weak password management policy that allows a very low password strength to be stored in the system. On the session part, sometimes the developer will pass the session ID through the web URL which is extremely dangerous. In addition to that, session timeout should also be handled properly. This is because some user has the habit of just closing the browser without logging off first. What happened after that, the next user that use that application will immediately login into the system with the previous user credential when viewing that application page. Lastly, sensitive data should also be transmitted via TLS/SSL connection as mentioned in issue number 9 of this entry. Authentication and session control is extremely important and it should be managed properly to prevent identity theft.
2. Cross-Site Scripting (XSS)
We are at number 2 and the second top web application vulnerabilities that we are talking about here is the cross-site scripting (XSS). Based on some web researcher, almost 70% of websites suffered from XSS including large application like Facebook. XSS happened in the way when the input box are not escaping special characters and caused those special characters to be used as part of the source code. By doing so, the attacker stands a very good chance to steal the victim’s identity by sending a script to steal the session token and then send back to the attacker. This type of XSS is a non-persistent XSS. The other type of XSS which is the persistent XSS is a litttle different. This XSS happened when the attacker posted a link on a social website for instance facebook and the URL contained malicious script where when the victim click on the URL, it will trigger the XSS. XSS can be detected with automated tool. However, it will not be able to cover everything and hence, the best method is to do source code reading for this vulnerability.
Injection is the most famous web application vulnerabilities and it does not only covers SQL injection, but also OS injection, LDAP injection and so on. However, the famous one is still SQL injection as it is related to database and usually attacker is very interested to know what is inside the database. The method to launch this attack is quite similar to XSS which is through injecting special characters. It is possible to inject both on the URL or through the input box. The difference between XSS and injection is that, once the injection is successful, the attacker already reached the database layer. While for XSS, upon successful means that the attacker still at the processing layer. Thus, for injection attack, the attacker can perform the SQL query statement since his situation now is a database authenticated user. The result of being attacked by injection could be as worse as the entire host being taken over by the attacker. In addition to that, statistic shows that 20% of all the websites are vulnerable to SQL injection. There is no doubt now that injection stay on top of all web application vulnerabilities as it is dangerous and has a very severe damage to the victim.
Web Application Vulnerabilities – Final Say
After going through the top ten web application vulnerabilities, clearly we can see that a web developer plays an extremely important role in determinig the web application security level. It is quite impossible to produce a web application that completely secure but at least, we can try to minimize the vulnerabilities to the very minimum. I will stop right here and come back to me again next week on how we can solve all these web application vulnerabilities to protect our application.