5 Most Common Web Application Attacks and How to Defend Against Them

Globally, cybercrime was the second most reported crime in 2016, and cybercrime damages are anticipated to cost businesses and organizations $6 trillion annually by 2021. One of the ways that cybercriminals attack businesses is through the use of web application vulnerabilities.

A web application vulnerability is a flaw or loophole in an application’s code that can be exploited by attackers to facilitate cybercrime. Imperva reports that web application vulnerabilities are on the rise. These vulnerabilities increased in 2018 by 23% over the previous year.

As businesses gradually shift to online platforms, it means that they’re handling an enormous number of client requests and are storing massive amounts of data online. To facilitate these processes, they use web applications that are comprised of main three components:

1. A web server that handles client requests;
2. An application that processes the tasks requested by the user; and
3. A database that stores the user data.

Visitors can use web browsers or other devices to interact with the web application on the internet. Now, if any of the above components suffers from a security weakness, attackers can get into the system and exploit it for malicious purposes.

Wondering what the five most common web application vulnerabilities are for businesses? We’ve got you covered:

The Most Common Web Application Vulnerabilities Cybercriminals Exploit

1. Cross-Site Scripting (XSS) Vulnerability

TrustWave reports that cross-site scripting (XSS) constitutes about 40% of all web attack attempts. XSS targets website visitors rather than the website or server. In this type of attack, the cybercriminal injects malicious JavaScript into a legitimate website’s input fields and forms such as comment fields, login fields, emails, registration form, and even product detail pages in marketplace/eCommerce websites. Whenever the user visits the compromised webpage or clicks on such links, the script is executed and may enable a hacker to:

1. Hijack the user’s session or steal their cookies/session data. Now, the hacker can use the website while pretending to be the actual user. This gives the hacker access to everything the user would normally see and do.
2. Redirect the user to another spam website. Sometimes, this other website looks identical to the original. So, users might not differentiate and input their sensitive details like login details or bank details and become the hacker’s victim.
3. Distribute and auto-download malicious programs onto a user’s computer.

As you can see, the hacker doesn’t need to create a copy of the original website in this attack. Instead, they corrupt an authentic website and use it as a medium to attack the website visitor.

How to Address Cross-Site Scripting Vulnerabilities
XSS attacks are so smart that protection against them is a complicated task. Even popular websites such as Facebook, Google, and PayPal have become victims of XSS attacks. However, there are some common tricks by which you can reduce chances of becoming an XSS victim.

1. Validate: Verify any data your website/application receives to ensure it doesn’t contain any malicious code. Use some constraints in your code to prevent users from inputting certain characters in the input fields. For example, if the user writes “HTTP://, ” in a field, your website/application shouldn’t accept it and should show the user an error message.
2. Escape / Sanitize Code: Whenever your website gets any input from a user, your website should scrutinize it before showing it to other users. If there are suspicious characteristics in the input field, such as HTML tags, URLs, or JavaScript entities, your website escapes (or disables) that code before displaying the message/input to other end-users. Web applications can also use an HTML sanitization library to ensure that users aren’t able to pass on scripts in their HTML submissions.
3. Limit the Use of User-Provided Data and/or Use Whitelisted Values: Minimize user-provided data whenever possible. For example, instead of asking users to write their age, country, dates, etc., use a dropdown list and tick mark options.
4. Implement a Content Security Policy. A content security policy (CSP) is a security mechanism that’s supported by many modern web browsers. Correct implementation of a content security policy will help the user’s browser detect and block cross-site scripting attacks.
5. Implement the Right Tools: Use web application security testing tools and attack prevention tools such as a robust web application firewall (WAF) to toughen your defenses.

2. SQL Injection

In this digital era, most websites and application systems deal with a large amount of data. For example: customers’ email addresses, IDs, passwords, phone numbers, addresses, vendor’s details, inventory details, pricing data and a litany of other such data. Managing, analyzing, and using these types of data for decision making can be challenging. To ease this task, SQL was created. Structured Query Language (SQL) is the standard computer language for relational database management systems, which is used to communicate with a database. Most of the websites that deal with databases use SQL to insert, store, update, retrieve, modify and remove the data from the database.

SQL uses queries or commands to interact with the database. Input fields/entry fields/forms and URLs interacting with the database of a website/application are the most vulnerable part of SQL mechanism. Whenever a user submits information via input fields, the data goes into the database. If there are loopholes in the software, hackers can inject malicious SQL commands or malicious code, also known as payloads, into the entry fields. This is called SQL injection or SQLI attacks. SQL injection is the result of the failure to filter untrusted data and passing that unfiltered data on to the SQL server.

A successful SQLI attack may result in the unauthorized:

• Viewing of users’ sensitive data like usernames, email addresses, phone numbers, passwords, etc.;
• Accessing of trade secrets or other confidential information; and/or
• Tampering with existing data (insert/modify/delete), voiding transactions, changing balances and spoofing authentication to gain full control of the website.

SQL injection is one of the most common hacking techniques used by hackers. SQLI has even been linked to the U.S. Election Assistance Commission (EAC) in December 2016, where a hacker offered to sell information on software vulnerabilities on the EAC website that could be used for SQL injection attack. It would have given an attacker access to the entire EAC website and its back-end systems!

How to Address SQL Injection Vulnerabilities
You can secure your website from SQLI attacks by:

• Using prepared statements (with parameterized queries),
• Validating user input,
• Limiting privileges (not giving all the privileges to one admin account),
• Keeping database credentials separate and encrypted,
• Disabling shell and any other unnecessary functionalities,
• Using stored procedures,
• Whitelisting input validation, and
• Escaping all user-supplied input.

Much like with XSS, the key to preventing SQL injections is to be very careful with user input.

You can also use a web application firewall (WAF) to help automate the SQLI protection process and weed out illegitimate user inputs.

3. Session Management Vulnerabilities

Whenever a user visits a website, the website typically creates a session cookie and session ID for each session. These cookies are stored to provide the user with a convenient browsing experience upon their next visit. Session cookies grant users with immediate access to their sensitive data such as usernames, passwords, bank details, etc. so that they don’t have to repeatedly log in during the same session. Once the session has ended, these cookies typically become invalidated (i.e. for each session, the website creates a new session ID, and it is invalidated at the end of each session).

Some security driven websites also specify a maximum time limit for a session ID. So, even if a session is not terminated within that time frame, the session ID will automatically expire and a new session ID will be created for the same session.

However, if a website is poorly coded, it might have vulnerabilities such as:

• Saving cookies for an extended period of time — even after the session has ended. Hence, the user’s sensitive data could be accessed.
• Some vulnerable websites/applications assign the same session ID for each new session.
• Some applications show session IDs in the URL. If an attacker gets a hold of the URL link, they can hijack the session ID and steal the user’s sensitive information.
• Some poorly coded websites may save confidential data in the cookie itself, which makes it even easier for hackers to obtain the data.

Let’s say, for example, that a user is accessing a vulnerable website using a public computer. The sensitive details such as their user ID, password, credit card details, etc. are saved in cookies, and the session ID is not expired when they end the session and leave the computer. If an attacker browses the same website using the same computer, they’ll get access to that sensitive data from the previous user.

How to Address Site Session Vulnerabilities

1. All website owners should follow session management requirements as per the Open Web Application Secure Protect (OWASP) Application Security Verification Standard.
2. A user should check whether a URL contains the session ID before sharing the URL with another person to ensure your URL doesn’t expose any credentials. For example, carefully review the following URL. You’ll notice that it contains a user ID and a session ID. Never share such a URL with anyone!

   http://deals.com/offers/saleitems;userid=1874;jsessionid=8L0OV2omKM0DPFDSWPLME34SCVIUBG/dest=Curtains

3. When you use a public computer, always browse websites that you trust, limit entering sensitive information, and always log out after each session. (To be safe, you should also clear your browser cookies.)

4. Lack of Transport Layer Protection

Any data transferred between a user’s browser and a website’s server is generally in plain text. Any man-in-the-middle (MitM) can easily read it just by exploiting some basic vulnerabilities. However, if the data is encrypted using public key infrastructure (PKI), only the intended receiver can decrypt, read, and interpret its contents. Even if the hacker gets the data, they can’t decrypt it without the unique private key. In PKI, each website has its own unique private key that’s safely stored in its server and is unlikely to get compromised.

To encrypt the data transferred between two systems, websites and applications need to have SSL/TSL (secure socket layer/transport layer protection) certificates installed on their servers. Unlike free SSL certificates, most paid SSL certificates come with a warranty for their encryption. In the unlikely event of encryption failure, the certificate authority (CA) will pay the damages — up to the warranty amount — to the victim(s).

How to Address Transport Layer Vulnerabilities
Always install an SSL certificate to encrypt data in transit. Make sure your SSL certificate is installed correctly, is not expired, has the highest (256-bit) encryption strength, and carries a generous warranty amount.

Set up redirects to force all websites to be served via HTTPS. If there is no error in the SSL certificate installation process and the certificate is not expired, the browser will activate HTTPS:// and a padlock sign before your domain name in the address bar. Inexpensive SSL certificates are offered from SectigoStore (formerly known as Comodo CA), that starts from $10 per year.

5. Cross-Site Request Forgery

Cross-site request forgery — also known as CSRF, a one-click attack, session riding, sea-surf, or XSRF — is a type of hacking attempt where a website gets unauthorized commands from the user it trusts.

Unlike XSS attacks (where a genuine website is misused to hack the visitors), in CSRF attacks, a genuine user’s browser is misused to exploit the website/application. Here, the attacker tricks the website visitor in a way that the visitor unknowingly sends instructions to the website/application to perform certain tasks.

For example, when a user is logged into his bank account, the hacker manages send an email to the user that looks exactly like the bank’s official email. It contains a link asking for some mandatory service charges of $10. However, the link is embedded with a malicious script that sends the banks commands to transfer $1,000 instead to the hacker’s account. Here, the user has unknowingly instructed the bank’s website to send money when he clicks the link. The bank can’t suspect any fraud because the request is coming from its genuine customer using the authenticated login credentials and session ID, and so it transfers $1,000 to the hacker’s account.

Some prestigious organizations and companies have become victims of CSRF attacks. In 2006, Netflix was such a victim when an attacker got access to perform tasks such as changing email addresses, passwords, shipping addresses, and adding movies to customers’ rental queues. ING Direct, YouTube and McAfee were also vulnerable to CSRF at different points.

How to Address Cross-Site Request Forgery Vulnerabilities

For Users
Users are highly vulnerable to CSRF attacks when they’re logged in to an application. So, avoid simultaneously browsing other websites when you’re logged into a sensitive application such as a bank account. Session cookies and sessions IDs are used for CSRF attacks. So, always log out from the website after completing your work.

For Site Owners
An anti-CSRF token, or a synchronizer token, is commonly used to prevent CSRF attacks. The web server generates a challenge token that is linked to a particular user. The token is statically set as a hidden attribute in every form field. When the user sends a request/command to the application using such a form, the secret token is included with that request. The application compares the token value it received from the user with the token value generated and stored by itself. The application accepts the request only when the token values match. If these tokens don’t match or have missing values, the request is rejected. The token must also expire after a set amount of time and after the user logs out. Here, the attacker needs to guess the token value to send a valid request on a user’s behalf. These token values must be generated using a strong algorithm so that no one can easily guess them. They should be cryptographically secured, too.

Some prestigious websites are also enabling a two-factor verification process before accepting any requests from the user.

About the Author

Medha Mehta is working as a Content Marketing Specialist for SectigoStore. She is a tech enthusiast and writes about technology, cryptography, cyber security, data protection, WordPress and SEO. She’s previously held management consultant roles in range of organizations.