Is your Web Application vulnerable? Developers plan and develop web applications by considering security in mind but at some point, hackers find a way to exploit the flaw that resides in web applications.
It compels application developers and security professionals to mull over them. It is nice to stay updated on the application regularly, as it can save you from critical bugs.
Cybercrime raises-up day by day and hackers have been exploring sophisticated techniques that take advantage of web application vulnerability. In this article, we will go through the top seven web application vulnerabilities and prevention tips.
1. SQL Injection
SQL injection is an insertion of a SQL query through input data made from the client to the application side. An SQL Injection attack can occur when user-supplied data is used by web applications without proper validation or encoding.
SQL Injection lets an attacker create, read, update or delete stored data in the database backup.
SQL Injection attack can access confidential information like SSN numbers, credit and debit card numbers etc.
- Validate user input with proper input validation technique against a set of standard rules for length, type, and syntax.
- Limit the database access to users and ignore the use of system administration account.
- Create application-specific database user accounts and remove all stored process that is not in use.
- Use parameterized query APIs with a placeholder substitution marker at the time of addressing stored procedures.
2. Cross-Site Scripting (XSS)
Cross-Site Scripting or XSS is executed on a client-side, which means in the user’s browser. This flaw appears in client-side scripting languages (HTML and JAVA) of a web application.
Due to this attack, the attacker can bypass basic security restrictions and control the user’s account of the web application or the victim’s browser.
- Many web applications do not require client-side scripting, so users can disable scripting in their browsers before use. It will protect users from the injection of a malicious client-side script.
- All user input should be sanitized.
- Developers should use XSS Me (Firefox) and Dom Snitch (chrome) extensions to self-test for XSS vulnerability.
- A site can link with browser cookie credentials to prevent abuse of user’s cookies.
3. Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) happens when a malicious website is already authenticated by a user in that case an attacker will send a request to a web application and gain access via the user’s authenticated browser. Such web applications include social media, banking, browser, email clients applications.
The attacker finds how the web application deals with authentication. Attackers must be logged in to perform this attack. Remember, the vulnerability resides in a web application, not in the user’s browser.
- Add an unpredictable challenge token (cryptographic value) to each request and connect them to the user’s session. It allows that the request made is valid and not raised by an unknown source. It creates a burden on the server as every token’s validity is being checked.
- Many websites use CAPTCHA or two-factor authentication, it requires also user’s interaction.
- Users should use the RequestPolicy Add-on of Firefox to prevent CSRF vulnerability.
- Never use Remember Password option in web browsers and kindly log out from the application once the task is completed.
4. Broken authentication and session management
Every application has to be authenticated, but sometimes functions related to the application and session management are not implemented correctly. It allows cyber culprits to gain access to passwords, session tokens, and private keys. Attackers could exploit other flaws to guess users’ identities.
For example, a user participating in social media or online forums is likely to affect by this type of attack. Attackers mimic the victim on the base of information that they gather from the other users on the same platform. Attackers ask for information from the victim and in return, it leads to account hijacking, ID theft, and other issues.
- Define the website’s policy for the safety of users’ credentials. Keep complex passwords includes alphabetic, numeric, symbols, etc.
- Users should be limited to a number of wrong login attempts and the repeated login efforts should be recorded in a database with an IP address. Do not log failed login attempts by users, as hackers can gain access of log and reveal the password. The system should inform users about their last login date and time.
- There should be a single mechanism for password change and users must have to provide their old and new passwords at the time of password change.
- All passwords should be kept in an encrypted or hashed form.
- A user’s entire session should be secured via SSL to prevent potential security damages.
- Users should have limited access to the list of other users’ account lists.
5. Insecure Cryptographic Storage
This type of vulnerability occurs when sensitive data is not stored properly. Due to improper storage, users can read registry, temporary files, and hidden files that can be accessible by the attacker. To make this stuff secure, there should be limited access to proprietary algorithms and encryption keys.
- Identify the confidential data and encrypt it when it is placed on a hard drive.
- Make sure that, the encrypted data cannot be easily overwritten.
- When the unused data is placed in memory locations, kindly overwrite the memory locations.
- Run Security scanning tools to check insecure cryptography or algorithms.
- Weak algorithms like (RC4, RC3, and MD5) could welcome potential attacks; therefore, salted hashes should be used.
6. Using components with known vulnerabilities
When certain components of your website like framework, libraries, URL redirect are vulnerable, the attacker could use it to damage the server and it can cause a data loss. Applications that use such vulnerable components can invite a mass level of attack.
Unfortunately, when any vulnerability found in open source software does not reveal the version infected of a component. Even all libraries do not have a comprehensible version number system. Components usually work with the full right of the application, so any flaw in a component can be severe.
- You should check all versions of components, including all dependencies (plug-in).
- Keep up-to-date components by checking them in public databases, project mailing lists, and security mailing lists.
- Implement software development practice, security tests, license policy for component security policy.
- Secure weak parts of components by adding a security layer.
7. Invalid forwards and redirects
Invalidated forwards and redirects happen when a web application accepts untrusted input and that induces the web application to redirect to an untrusted URL. An attacker can modify this URL and may launch a phishing attack.
The server name is identical in the modified URL; users generally believe it trustworthy and become victims of such attack. Such invalidated redirect and forward can bypass the application’s access control to gain privilege controls.
- Avoid redirects and forwards if it is not necessary.
- Make a whitelist of trusted URLs (list of hosts).
- In specific circumstances, allow internal redirects and forwards.
- Make unused redirects disabled.
- Scan all HTTP requests for the inactive redirect.
8. Insecure Direct Object References
A Direct Object References means an internal data file or database key is revealed or exposed to the user. Attackers can take advantage of this situation and perform an enumeration attack to access files and keys.
In such a case, authentication is broken or not implemented. It is an access control vulnerability that is done via URL parameters by modifying data keys in a serial number. Static files can be modified to get confidential information. The below example shows how a web application shows URLs for transaction details with simple IDs.
An attacker can change parameter value with a similar value like
In the above case, the changed value may pertain to another user. When a developer made such mistakes and allows an attacker to see the transaction value, the attacker can modify it.
- Strict access control is required.
- Developers should renowned frameworks to develop web applications.
- Currently, Ruby on Rails and Django have no issue with the Insecure Direct Object Reference attack.
- A developer should keep long and hard to guess object identifiers.
- Moreover, indirect object reference maps should be used with external ID, which is hard to imagine.
9. Security misconfiguration
Security misconfiguration can be a result of unpatched software, unused webpages, vulnerable files, unsecured directories, software in debug mode, needless services running on the server, unchanged keys, and passwords, opened unnecessary ports, unused accounts left with rights.
- A proper security audit should be performed for breaches or any misconfiguration.
- There should be limited access to the admin interface.
- Disable debugging especially for a production environment.
- Keep new passwords for a newly installed device as well as implement password policy across the company.
- A minimum number of persons should have access to login credentials.
- Directory listing should not be enabled on deployed applications and proper approval is set for files and folders.
- Always keep software updated with the latest patches.
10. Sensitive data exposure
Information that is in transit or stored, which is left unencrypted can cause sensitive data exposure. Vulnerable information can cause security attacks like Man-in-middle attack, data spying and data theft.
Credit and debit card information should not be left unencrypted and passwords should be hashed. The encryption keys should be the latest as per web security standards. Moreover, session IDs and confidential data should not be included in URL parameters.
- HTTPS and perfect forward secrecy (PFS) should be implemented to encrypt the data passing between the client and the server. It will secure incoming data to the site.
- Moreover, always disable data caching as it may hoard confidential information.
- There should be the elimination of outdated data or unnecessary data as it will save you from data exposure.
- Never accept any request made on insecure HTTP.
11. Missing function level access control
Missing function level access control is a vulnerability caused by server misconfiguration. It means proper authorization is not done on the server side.
Attackers target front-end UI configuration and find vulnerability by forging the request to the hidden functionality. However, users can not see the admin function, but an attacker can send malicious requests and find vulnerabilities if the authorization is not there.
- A server-side authorization is required and properly configured.
Web application security and network security problems, both are serious but web application security has received significantly less consideration so far. Attackers have set out to revolve around the weakness of web application security and are vigorously building up tools and techniques for finding and harnessing them.
Related Posts :