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 resides in web applications. It compels application developers and security professionals to mull over them. It is nice to stay update the application regularly, as it can save you from critical bugs.
Cyber crime 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 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 application side. An SQL Injection attack can occur when a user-supplied data is used by web application without proper validation or encoding.
SQL Injection lets an attacker to create, read, update or delete stored data in the database backup.
SQL Injection attack can access confidential information like SSN number, 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)
Due to this attack, the attacker can bypass basic security restrictions and control user’s account of 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 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 which can be accessible by the attacker. To make these stuffs 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 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 attack; 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 list and security mailing lists.
- Implement software development practice, security tests, license policy for component security policy.
- Secure weak part 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 victim to 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 URL’s (list of hosts).
- In specific circumstances, allow internal redirects and forwards.
- Make unused redirects disabled.
- Scan all HTTP requests for the inactive redirect.
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 :