What is a Web Application Attack and How Can You Prevent it?
Jeffrey Edwards
|Cyber Risks & Threats | January 04, 2023
Web application attacks are a significant threat to businesses of all sizes. These attacks can result in data breaches, loss of customer trust, and damage to a company’s reputation. In this blog post, we will take a closer look at the different types of web application attacks and how they can be prevented. We will also discuss the importance of regular testing and maintenance in order to keep web applications secure.
By understanding the risks and taking the necessary precautions, businesses can protect themselves and their customers from web application attacks.
What is a Web Application? Why are They Vulnerable to Attack?
A web application is any application that runs on a web server and can be accessed remotely via the internet using a web browser. When a user accesses a web application, their web browser, i.e., the ‘client-side‘ sends a request to the web server, i.e., the ‘server-side’, which processes the request and returns a response. That response will typically consist of HTML, CSS, and JavaScript code, which is then used to render the web page on the user’s browser.
The call-and-response nature of the web application is a vital building block of the modern internet and of modern computing infrastructure, but it also opens web applications to a unique set of vulnerabilities beyond those common to all applications, such as code vulnerabilities and outdated software. Because web applications are accessible from anywhere–and by anyone–with an internet connection, they are an easy target for remote attackers. And, because web applications often handle sensitive information, such as login credentials and financial data, they’re a very attractive target.
What is a web application attack?
As noted above, developers use a combination of server-side script (ASP, PHP, etc.) and client-side script (HTML, JavaScript, etc.) to develop web applications – a web application attack is any attempt to exploit vulnerabilities on either side, client or server, of that process in order to access sensitive information, perform unauthorized actions, or disrupt the normal functioning of the application.
Attacks may be as simple as an attacker manipulating data in a web page’s URL to force an exploitable malfunction in the application. For example, the two most common web application attacks are SQL injection and cross-site scripting (XXS). Executing an SQL injection exploit may just involve modifying the URL – all that is needed is one additional character to trigger a successful exploit. This can give the hacker control over the application and access to the server, database, and other IT resources.
Common Web Application Attacks
Cross-site scripting (XSS)
A cross-site scripting (XSS) attack is a common web application attack in which an attacker adds or injects malicious code into an existing authorized application. These can either compromise an individual site directly or breach a third-party script to access all the sites on which it runs, all at once. The attacks can see malicious code being sent to other website users, and customers being infected with malware that exposes their confidential information. DOM-based XSS attacks are the toughest to detect as the vulnerability is in the client-side code rather than server-side code, so the server never gets a chance to see the attack taking place.
XSS attacks typically occur when a web application does not properly validate user input before displaying it on a web page. For example, if the comments or reviews section on a product page does not properly sanitize comments before displaying them, an attacker could enter malicious code into the comment field which would then be added to the page, and would be executed by the victim’s web browser. This is known as a ‘stored,’ or ‘persistent’ XSS attack, because the malicious payload is permanently stored on the server-side, causing it to serve the malicious payload to all future users of the application.
For example, an attacker may discover a web application that does not sanitize entries in the comments section of a product page, and can then make entries that will be added directly to the website. In this case the attacker may add a line of malicious JavaScript. From there, the malicious script will appear as source code, and will execute on further visitor’s browsers:
Now the attacker can leverage the script to carry out a variety of attacks, like reading local storage, accessing cookies, including stealing personally identifiable information (PII), phishing, or distributing malware.
To prevent XSS attacks, it is important for web applications to properly validate and sanitize user input before displaying it on a web page. This can be done by using functions that encode special characters in user input, such as < and >, so that they are not interpreted as HTML by the web browser.
It is also important for web applications to set the Content-Security-Policy header, which specifies which sources are allowed to load content into the web page. This can help to prevent attackers from injecting malicious code into the web page from external sources.
SQL Injection Attacks
A SQL injection (SQLI) attack is similar to an XSS attack, in that the attacker injects malicious code into a web application, but rather than targeting client-side execution of said code, the attacker is instead targeting the backend database through its input fields. The goal of this attack is to manipulate the database in order to access sensitive information, such as login credentials or financial data, or to perform unauthorized actions, such as adding or deleting records.
Like XSS attacks, SQL injection attacks occur when a web application does not properly validate user input. For example, consider a web application that allows users to search for products in a database by entering a search term into an input field. The search function might be implemented using the following SQL query:
If the web application does not properly validate the search term, an attacker could enter malicious code into the input field in order to manipulate the database. For example, an attacker might enter the following search term:
OR 1=1; --
This input would modify the SQL query to the following:
SELECT * FROM products WHERE name LIKE '%' OR 1=1; --%';
The resulting query would return all rows in the products table, because the WHERE clause would always evaluate to TRUE. The -- at the end of the input is used to comment out the rest of the original query, so that it does not interfere with the attacker’s malicious code.
To prevent SQL injection attacks, it is important for web applications to properly validate and sanitize user input. This can be done by using prepared statements and parameterized queries, which allow developers to specify placeholders for user input rather than directly incorporating it into the SQL query.
Path Traversal Attacks
A path traversal attack, also known as a “directory traversal” attack, is a variety of web application attack that involves accessing files and directories on a web server that are outside of the web root directory in order to access configuration files or log files or execute arbitrary code on the server.
Path traversal attacks occur when a web application does not properly validate user input that is used to specify the file or directory path. For example, consider a web application that allows users to download files from a restricted directory by entering the file name into an input field. If the web application does not properly validate the file name, an attacker could enter a file name that includes directory traversal characters, such as ../, in order to access files outside of the restricted directory.
A local file inclusion (LFI) attack is a variant of path traversal attack in which the attacker fools a web application into exposing or running files on the web server. As in a path traversal attack, the back actor will utilize directory traversal to discover files on the server, and will then prompt the web server to run the file, opening the door to further attacks and ingression.
Cross-Site Request Forgery
A cross-site request forgery (CSRF) attack involves tricking a user into making unintended actions on a web application that they are previously authenticated on. The attacker’s goal is to perform unauthorized actions, such as transferring funds or changing a password, by sending a malicious request to the web application that appears to be legitimate.
For example, if a user is logged into a banking web application that allows users to transfer funds by filling out a form and submitting it, but that application does not include a unique token in the form that is checked on the server, an attacker could potentially create malicious website that includes a form with the same fields as the legitimate form, and direct the user to that site through social engineering. If the victim is logged into the web application and visits the malicious website, the attacker’s form could be submitted, causing the victim to unknowingly make a fund transfer.
To prevent CSRF attacks, it is important for web applications to include a unique token in forms and to verify the authenticity of requests on the server. This can be done by using a “synchronizer token,” which is a unique value that is generated by the server and included in the form. When the form is submitted, the server checks that the token is valid before processing the request. It is also a good idea to include a “logout” button on web pages that invalidates the synchronizer token, so that it cannot be used for future attacks.
How can you protect your business from web application attacks?
A good starting point for advice is the International Council of E-Commerce Consultants, which says it is important that your web application “is providing trusted data and keeping away untrusted or malicious data from harming your database, web application or end user’s personal data.”
This means it is important you have full visibility of what code is running on your website – whether it is your own or from a third party – and have the ability to control the data they collect and share to prevent data leakage.
You should perform security assessments of web applications regularly and fix any vulnerabilities you find – this testing should happen at every stage of the site development lifecycle. Also, ensure you are not using outdated versions of web servers, operating systems, content management systems, libraries, or other software.
Here are ten best practices for defending against web application attacks:
- Regularly test and scan for vulnerabilities: Use tools such as scanners and penetration testers to identify and fix vulnerabilities in your web application.
- Use input validation and sanitization: Validate and sanitize all user input to prevent attackers from injecting malicious code into your web application.
- Use prepared statements and parameterized queries: Use these techniques to prevent SQL injection attacks.
- Set the
Content-Security-Policyheader: This header specifies which sources are allowed to load content into your web page, which can help to prevent cross-site scripting (XSS) attacks. - Use a synchronizer token: Include a unique token in your forms and verify its authenticity on the server to prevent cross-site request forgery (CSRF) attacks.
- Validate file and directory paths: Properly validate user input that is used to specify file and directory paths to prevent path traversal attacks.
- Disable the processing of external entities: Set the
EntityResolverfor your XML parser tonullor use a parser that does not support external entities to prevent XML External Entity (XXE) attacks. - Use a whitelist of acceptable elements and attributes: Use a whitelist of acceptable elements and attributes in your XML input to prevent attackers from using elements or attributes that are not explicitly allowed.
- Use secure coding practices: Follow best practices for secure coding, such as using secure coding frameworks and following guidelines for secure password storage.
- Keep your servers and software up-to-date: Regularly update your servers and software with the latest security patches to fix known vulnerabilities.
Fighting Web Application Attacks with Client-Side Security
There is no silver bullet against web application attacks–they are an ever-evolving problem that requires a multifaceted solution. The solutions above can help organizations secure their properties against attack but cannot guarantee success.
OWASP recommends a defense in depth posture, also known as layered defense, in which multiple redundant layers of security safeguards and risk-mitigation countermeasures are employed.
To prevent web application attacks, it’s imperative to be aware of all code running on your website, especially third-party code. Security assessments should be performed regularly, systems should be patched, and vulnerabilities should be addressed.
Client-side protection should also be considered to allow you to unilaterally block scripts from unapproved sources, audit new scripts in real-time, and block injection-based attacks.
CHEQ’s Go-to-Market Security platform provides client-side web application protection while enhancing website performance through:
- Allow and block capabilities: Define permissions for approved third-party vendors you choose to allow to access data – or block from receiving any of specific types of data
- Script Auditing: Real-time view of all the technologies running on your website and full privacy risk assessment as web pages are loaded
- Stopping injection-based attacks: Blocking of formjacking and payment card skimming by enabling control over third-party JavaScript, which is given permission to operate within the user’s browser
- Reporting: Comprehensive reporting of site traffic and real-time user activity to identify any suspicious patterns or network requests
Learn how to prevent web application attacks with CHEQ. Book a demo today.
Author
Jeffrey Edwards
Content Marketing Manager
Jeff is the resident content marketing expert at CHEQ. He has several years of experience as a trained journalist, and more recently in his career found a knack for communicating complex cybersecurity topics in an approachable yet detailed manner.
