Web application security is crucial because we have sensitive data to protect, such as personally identifiable information and internal documents. Data theft, interruptions in business continuity, and other cyber attacks can be costly to the point of being unaffordable. Prevention and preparedness increase the survivability of an entity with an online presence.
1. Cross-Site Scripting (XSS)
Cross-site scripting is when an attacker inserts malicious scripts into a web application (such as the comment field on a web form), which can then target other website users. These can be used to steal information from other users or steal session cookies.
Cross-site scripting comes in three forms; persistent, reflective, and DOM-based.
Persistent: A user is able to store input on the target server (such as a message in a forum or a comment field in a form). In this case, other visitors to the site will be affected by the malicious script.
Reflective: This script is not stored and has an immediate response. In order to properly pull off this attack, the attacker must trick a user into sending the malicious script to the site themselves. This is usually accomplished by designing a link that, when clicked, would input the script as the user is sent to the site. The script is executed in the user’s browser.
DOM-Based: This attack takes advantage of the “Document Object Model.” In a DOM-based XSS attack, the server is never affected; everything takes place in the victim’s browser (similar to reflective XSS). The attack is possible if the application writes data to the DOM without proper sanitization.
All of these attacks can be prevented by
- Properly sanitizing user input (for example, not reading user input as code)
- Using output encoding (translating special characters into an alternative, such as translating the < character into the < string)
- Using a Content Security Policy
2. Cross-Site Request Forgery (CSRF)
This involves tricking a user into carrying out an action on a web application. An example might be crafting a link that includes a change in login credentials or a transfer or funds. In cases like this, the victim is authenticated to the site and has the right to make the requested changes to their account - they simply aren’t aware that the requested action has been embedded in the URL.
This is different than a reflected XSS attack. The CSRF attack uses a victim’s authentication on a target website. The request is made elsewhere (through a malicious link), but the vulnerable website believes the request was made internally (on its own site). Hence cross-site request forgery.
A required condition for these attacks to be successful is that the application relies only on cookies to identify the user, ignoring the origin of the request. CSRF tokens prevent this attack, as they provide a unique identifier to each request. Without the token, the attacker cannot craft a valid request to the server.
3. Insecure Direct Object References (IDOR)
Here, an attacker manipulates an application to gain access to data. This is possible when the application does not perform authorization checks, and exposes internal object references.
For example, if a bank used URLs such as, “www.bank.com/account?id=1234567” where “1234567” is the actual account number, an attacker could replace that number in the URL with any random bank account. If the application isn’t performing proper checks, the attacker can gain access to information they should not otherwise have.
The same applies to any type of internal object reference, such as filenames or user profiles.
Using strong access controls, indirect object references, and validating input can prevent these types of attacks.
4. Security Misconfigurations
These can often be as simple as using default credentials/settings, incorrect settings, or outdated software.
If an attacker can identify a system and the version, they have the ability to look at the default settings, default logins, installation and configuration documentation, and try and find weaknesses and easy-wins.
Follow the advice offered by the application designers and documentation to ensure you are using the correct settings, changing credentials, and turning off unnecessary features which could be abused. And always update to the latest versions and apply security patches as they become available.
5. Sensitive Data Exposure
This is not the same as a data breach. Sensitive data exposure occurs when the data on a server is not properly secured, or an application exposes this information unintentionally.
Some examples would include PII (Personal Identifiable Information), such as social security numbers, being stored on a server in plain text (without encryption). An attacker who gains access to the system will have access to this information without performing any kind of brute force or decryption.
Another example would be a login that uses weak or no encryption. That username and password could be intercepted by an attacker who could view, copy, or modify the information in transit to gain access.
These attacks can be avoided by encrypting sensitive data at rest (where it is stored) and using proper encryption and security measures to access that information (SSL, TLS, etc.).
6. Broken Authentication
This allows attackers to gain unauthorized access to sensitive data or impersonate legitimate users. Some examples of broken authentication include
- Allowing weak passwords which can easily be guessed or brute-forced
- Session fixation - when an attacker sets the session ID of a user before they log in
- Session hijacking - when a web application does not properly validate session IDs or uses IDs that are predictable; an attacker can steal or “hijack” the session of a legitamite user using the same ID
- When an application has no policy in place to limit login attempts (either the number of failed attempts per user account or per IP address), attackers can attempt to brute force entry
7. Insufficient Logging and Monitoring
Without keeping logs and actively monitoring activity, attacks will not be caught and can continue their attack for extended periods. This allows attackers to set up persistence and continue gathering information or pivoting to other systems unchecked.
This can be prevented through the use of automated monitoring systems, alerts, and regular reviews.
8. Insecure Deserialization
When an application deserializes (reconstructs an object from a stream of bytes) from untrusted sources and without proper sanitization, an attacker can have the application execute malicious code. This can lead to any number of attacks, including remote code execution and denial of service.
For example, if a web application creates an object from user input, such as filling in credentials, and does not properly validate the information, the input could be malicious and thus the object it constructs could grant access to the attacker or damage the system.
9. Using Components With Known Vulnerabilities
Using third-party applications with known and established vulnerabilities opens your system to attack. Even small plugins or depenancies can have known flaws which can be exploitable.
There are several tools available to scan and audit your applications for such vulnerabilities.
10. Server-Side Request Forgery (SSRF)
Server-side request forgery abuses the trust relationship between web applications, servers, or other internal or external resources.
If a server is vulnerable, an attacker can send a malicious request through the web application to that server, which will then request a resource or action from the back-end resources it interacts with. The back-end trusts the vulnerable server and processes the request.
This is primarily used to access resources and documents, or check for open ports. A typical SSRF attack would look like this:
A normal request is made by the attacker to a webpage, such as changing the on screen language, checking stock at a retail location, etc. The request is intercepted and manipulated by the attacker to ask for something different from the server. The language change, for example, may be replaced with a call for the /etc/passwd file. The server trusts the web application and so discloses the information.
Using an SSRF attack, information that sits behind a firewall, requires administrator privileges, or is otherwise not directly accessible can be discovered.
Input Validation and Sanitization
Remove or modify characters and elements which could be harmful, such as characters used in scripts:
< ! -- etc.
Ensure input meets the expected format. This can protect against XSS, IDOR, and SSRF attacks.
Changing dangerous characters into a safe equivalent so it cannot be read as an element and executed by the application. This is a great prevention against XSS attacks.
Content Security Policy
By restricting the sources of content that can be loaded to an application, injection attacks such as XSS become much more difficult. This might mean setting a policy that content can only be loaded from the same origin as the web page.
CSRF Tokens and SameSite Cookie Attribute
CSRF tokens are unpredictable values assigned to a session. When a request is made, the token in the session is compared with the one on the server to ensure the request has been made from the correct origin. This prevents crafting a malicious command in advance as the attacker does not have the CSRF value that will be assigned. The SameSite cookie attribute tells the browser to only send cookies in requests coming from the same site.
Robust Access Controls
IDOR and Sensitive Data Exposure can be prevented by properly securing data and setting strict rules as to who can access the information.
Secure Password Storage and Multi-Factor Authentication
Securing passwords using hashes and salting techniques can protect passwords in case of a data breach. So long as the passwords themselves are complex, properly hashing them can make any kind of cracking very difficult and time-consuming.
Requiring multi-factor authentication to access secure information adds a layer of protection against attackers. With MFA, a password is not enough. Attackers would need access to a user’s phone, hardware token, biometrics, or other authentication method.
Encryption for Data at Rest and in Transit
Encrypting sensitive data means that in the event of a breach, the stolen data is still secured so long as the encryption remains in tact. Proper use of encryption can make it nearly impossible to crack without having the key. Using protocols such as HTTPS and TLS for data in transit ensures even if it is intercepted, it will be unreadable to the attacker.
Regular Security Audits and Dependency Management
Monitoring your resources, looking for anomalies, using appropriate tools and vulnerability scanners, following security best practices, and ensuring all third-party applications are both reputable and up-to-date can protect against security misconfiguations and known vulnerabilities.
Building Security Into Application Design
Don’t leave securing your applications until the end. Instead, consider security to be an integral part of the design phase and plan accordingly. Examine all code throughout development and evaluate any third-party applications or libraries you intend to use before integration.
Documentation and Log Review
Keep detailed documentation of how applications have been designed and how they are expected to operate. Use automated tools to watch for anomalies and set alerts. Establish a baseline behaviour to check against. Keep up to date on new vulnerabilities that may affect your applications.