Web applications are exposed to a lot of vulnerabilities as they run without interruption. Due to that reason, it gives the attacker plenty of trial and error before the real attempt to take advantage of the vulnerabilities. In this article, I would like to share with you the most common vulnerabilities starting with the least popular ones.
Table of Contents
10. Unvalidated Redirects and Forwards
Generally, web applications redirect or forward 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 phishing attack that often leads to identity theft and credit card fraud.
Example of attack:
· http://www.your-site.com/redirect.jsp?url=phshing-site.com
· http://www.your-site.com/main.jsp?fwd=phishing-site.com
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 a man in the middle attack. The application should always use a strong encryption algorithm (at least FIPS 140-2) and it should also never use an 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 a phishing attack easily as the user already has 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 the restricted page. In other words, this means the user might not have the privilege to access or it could also be possible that the user did not perform any authentication and was 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 the administrator’s page. Once the attacker is there, he can just do whatever settings or actions that only administrators can perform.
7. Insecure Cryptographic Storage
Passwords, credit card information, and other sensitive data should be encrypted before storing it into the database. If let’s say the attacker somehow manages 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 time to decrypt it. This of course can only happen if you encrypt the data properly with a strong encryption algorithm and securely store the encryption key. In certain applications, 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 of 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 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 ensuring all the items mentioned are fully updated as the older versions tend to have vulnerabilities that attackers 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 is not exposed to the user. Attackers will love to see all the stack trace messages as it can give them more clues on how to attack your web application. Therefore, only display a very high-level message or general error message to the user. Security configuration needs to be planned properly and checked 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 as an authenticated user. However, this requires the user to be authenticated first by logging into the application and storing 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 clicks on a panda image that he found interesting.
Not realizing that the panda link actually looks 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 the hacker’s account.
The drawback is that the attacker still needs 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 develops an application that calls for a certain object, he does not always verify the person who calls 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 is not supposed to be revealed. For instance, an object that calls a function to show all information regarding your banking account with the SQL statement:
“select * from the 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 website developer designed here in the way the account_id will be passing this way:
“http://www.myapp.com/account/showaccount?account_id=myaccount”
The attacker can just modify the URL account_id to something else to see other people’s account information for example:
“http://www.myapp.com/account/showaccount?account_id=notmyaccount”.
Object should be treated like any web page 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, recovery 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, the session timeout should also be handled properly. This is because some users have the habit of just closing the browser without logging off first. The next user that uses that application will immediately login to 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 on the 9th point 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 research, almost 70% of websites suffered from XSS including large applications like Facebook. XSS happened in the way when the input boxes were 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 it 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 little 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 clicked on the URL, it would trigger the XSS. XSS can be detected with automated tools. However, it will not be able to cover everything and hence, the best method is to do source code reading for this particular vulnerability.
1. Injection
Injection is the most famous web application vulnerability and it 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 the database and usually the 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 has already reached the database layer. Thus, in the case of the 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, statistics show that 20% of all the websites are vulnerable to SQL injection. There is no doubt now that injection stays on top of all web application vulnerabilities as it is dangerous and has very severe damage to the victim.
Final Say
After going through the top ten vulnerabilities, clearly, we can see that a web developer plays an extremely important role in determining the security level of a web application. It is recommended that developers take part in specialized secure development training and OWASP training. It is quite impossible to produce a web application that is completely secure but at least, we can try to minimize the vulnerabilities to the very minimum.
Read also about how to write a website design RFP on ramotion.
