Thilan Dissanayaka Web App Hacking May 17

Common Web Application Attacks

Web applications are one of the most targeted surfaces by attackers. This is primarily because they are accessible over the internet, making them exposed and potentially vulnerable. Since these applications must be reachable to users, they also become accessible to malicious actors from anywhere in the world.

Attackers are free to explore the application, enumerate endpoints, and attempt a variety of attacks, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). They may also try brute-force login attempts, session hijacking, or exploit misconfigurations and outdated software components.

Moreover, modern web applications often integrate with APIs, third-party services, and cloud infrastructure—each of which can introduce additional attack vectors. This wide and often complex attack surface requires organizations to implement a robust security posture, incorporating secure coding practices, regular vulnerability assessments, and runtime protection mechanisms.

In this landscape, understanding and mitigating common vulnerabilities—such as those listed in the OWASP Top Ten—is critical for reducing the risk of exploitation and protecting both user data and system integrity.

Here I wanted to list down most common web application attack types.

SQL Injection
XSS - Cross Site Scripting
CSRF - Cross Site Request Forgery
SSRF - Server Side Request Forgery
RCE - Remote Code Execution
RCE - Remote Command Execution
LFI - Local File Inclusion
RFI - Remote File Inclusion
Click Jacking
Parameter Pollution
HTTP Header Injection
Insecure Deserialization
Open Redirection
IDOR - Insecure Remote Object Reference
XEE - XML External Entity Attacks
Path Traversal Attacks

SQL Injection happens when an attacker manipulates a web application's SQL queries by injecting malicious SQL code. If user inputs are not properly sanitized, attackers can gain unauthorized access to databases, extract data, or even modify or delete records.

Example:

SELECT * FROM users WHERE username = '$username' AND password = '$password';

If an attacker inputs admin' --, it can comment out the rest of the SQL query and log in without a password.

There are multiple types of SQL injections.

SQL Injection Login Bypassing
Union Based / Error Based SQL Injection
Blind SQL Injection
- Boolean Based Blind SQL Injection
- Time Based Blind SQL Injection
Out of Band SQL Injection

Prevention:

Use prepared statements (parameterized queries).
Use ORM (Object-Relational Mapping) libraries carefully.
Validate and sanitize user inputs.
Limit database permissions (least privilege).

XSS attacks occur when an attacker injects malicious scripts into web pages that are then served to other users. The script can steal cookies, session tokens, or perform actions on behalf of the user.

Example:

<script>alert('Hacked!');</script>

Based on the attack type, We can categorize XSS into following three types.

Stored XSS In this type of XSS, the malicious input is permanently stored in the application database. For example consider a user entering a comment on a blog. These comments are stored on the database.
Reflected XSS in this type, The script is not stored on the application but it is injected immediately to the page. For example consider a product searching page. In most cases the search term is included in the URL and it is used to display the content. Lets say

https://hacksland.net/search.php?str=monitor

The page content may be something like Search results for 'product'. If there is no proper input sanitization, we can inject a malicious javascript code into this parameter.

DOM-based XSS For this type of XSS, there is no Backend is interacted. This occurs when the client-side JavaScript application is improperly handling user input.

Prevention:

Escape all user input before rendering it to the page.
Use frameworks that automatically handle escaping (e.g., React).
Implement Content Security Policy (CSP).

CSRF tricks a logged-in user into sending a request to a web application they’re authenticated on — without their knowledge or intention. Since the user is already authenticated (e.g., via a session cookie), the server processes the request as if the user themselves sent it.

Let’s say you’re logged into your online banking website: https://mybank.com

It allows you to transfer money with a simple POST request like this:

POST https://mybank.com/transfer
Content-Type: application/x-www-form-urlencoded
to_account=123456&amount=1000

When you're logged in, this request is authenticated using your session cookie.

An attacker creates a fake website with this hidden form:

<form action="https://mybank.com/transfer" method="POST">
  <input type="hidden" name="to_account" value="999999">
  <input type="hidden" name="amount" value="1000">
  <input type="submit">
</form>
<script>
  document.forms[0].submit();
</script>

If a legitimate user visit the page while still logged into bank, the hidden form submits automatically using the user session cookie, sending $1000 to the attacker's account.

How to Prevent CSRF

Anti-CSRF Token
The server includes a unique, random token in each form, and validates it on submission.
SameSite Cookie Attribute
Set cookies with SameSite=Lax or SameSite=Strict so browsers don’t send them in cross-origin requests.
Re-authentication for Sensitive Actions
Force the user to re-enter their password before critical actions like transferring money or changing account details.

This way, even if CSRF is attempted, it won’t work without manual authentication.

Remote Code Execution allows attackers to run arbitrary code on a server or application, leading to complete system compromise.

Example: If a web app allows users to upload files without proper validation, an attacker might upload a malicious script and execute it on the server.

Read more about remote command execution here.

Prevention:

Never directly execute user input.
Validate and sanitize file uploads.
Keep software and libraries updated.
Use safe APIs for executing system commands.

Remote Command Injection is similar to RCE, but more specific: command injection involves injecting system-level commands through a vulnerable application.

Example:

<?php system("ping " . $_GET['ip']); ?>

If not sanitized, an attacker could execute:

http://example.com/ping.php?ip=127.0.0.1; cat /etc/passwd

Prevention:

Never concatenate user input with shell commands.

Use APIs that separate code from data (e.g., execFile instead of exec).

Validate and sanitize inputs.

Local File Inclusion (LFI): An attacker includes local files on the server.

Remote File Inclusion (RFI): An attacker includes remote files, possibly from their own server.

Example:

<?php include($_GET['page']); ?>

Prevention:

Validate and sanitize filenames and paths.

Maintain a whitelist of allowed files.

Disable remote file inclusion (allow_url_include in PHP).

Broken Authentication

What it is: When authentication mechanisms are improperly implemented, attackers can compromise passwords, keys, or session tokens.

Example:

Predictable login URLs

Weak password reset mechanisms

Prevention:

Implement strong password policies.

Use multi-factor authentication (MFA).

Secure session management.

Avoid exposing sensitive information.

Security Misconfiguration

What it is: Default settings, unnecessary services, or incomplete setups can expose applications to attacks.

Example:

Directory listings enabled

Default admin accounts still active

Error messages revealing stack traces

Prevention:

Regularly review and harden server configurations.

Disable unused features.

Conduct security audits.

When untrusted data is used to abuse the logic of an application during the deserialization process, leading to RCE, privilege escalation, or replay attacks.

Prevention:

Never accept serialized objects from untrusted sources.

Implement integrity checks (e.g., signatures).

Prefer simple data formats like JSON over complex objects.

Business Logic Vulnerabilities

What it is: Attackers exploit flaws in the logic or workflow of an application (e.g., bypassing payment after purchasing items).

Prevention:

Conduct thorough security testing.

Understand and protect critical workflows.

Implement strict server-side validation.

Open Redirection occurs when a web application redirects users to a different domain without properly validating the redirect URL. Attackers can use this to trick users into visiting malicious sites.

Example:

https://example.com/login?redirect=https://evil.com

User thinks they're clicking a safe link but gets redirected to a phishing page.

Prevention:

Validate redirect URLs against an allowlist.

Never accept full URLs from user input; only use relative paths.

Warn users before redirecting to external domains.

IDOR happens when applications expose internal implementation objects (like database IDs) without proper access control, allowing attackers to access unauthorized data.

Example:

https://example.com/user/12345/profile

Changing 12345 to another user's ID can expose private information.

Prevention:

Implement proper authorization checks for every object.

Avoid exposing predictable identifiers (use UUIDs).

Never trust user-supplied input for authorization.

In SSRF, attackers trick the server into making HTTP requests to internal services that are not meant to be accessible externally (like metadata services).

Example: Accessing AWS metadata server:

http://169.254.169.254/latest/meta-data/

Prevention:

Validate and sanitize all user-supplied URLs.

Implement network layer filtering.

Block requests to internal IP ranges.

Sensitive Data Exposure

What it is: Applications sometimes expose sensitive data like passwords, credit cards, or personal info due to inadequate protection (e.g., no encryption).

Prevention:

Use strong encryption for sensitive data (AES-256, HTTPS/TLS).

Never store passwords in plain text (use salted hashes).

Apply strict access control on sensitive endpoints.

Clickjacking tricks a user into clicking on something different than they intended by overlaying transparent frames or buttons.

Example: An invisible "Like" button over a video player.

Prevention:

Use the X-Frame-Options: DENY or SAMEORIGIN header.

Implement frame-busting JavaScript.

Cross-Origin Resource Sharing (CORS) Misconfigurations What it is: Incorrect CORS settings can allow unauthorized websites to interact with your APIs and steal data or perform actions on behalf of the user.

Prevention:

Always restrict allowed origins (Access-Control-Allow-Origin) to trusted domains.

Avoid using wildcard * unless absolutely necessary (and only for public APIs).

What it is: When an XML parser improperly processes external entities, attackers can read local files, perform SSRF, or execute other malicious actions.

Example:

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>

Prevention:

Disable external entity processing in XML parsers.

Prefer safer data formats like JSON.

Broken Access Control

What it is: Access control issues happen when restrictions on what authenticated users are allowed to do are not properly enforced.

Example: Normal users can access admin endpoints simply by changing the URL.

Prevention:

Enforce server-side access control checks.

Deny by default, allow by explicit permission.

Prototype pollution allows attackers to manipulate object prototypes, affecting the behavior of the whole application.

Example: Sending { "proto": { "isAdmin": true } } in a request.

Prevention:

Use libraries that protect against prototype pollution.

Deeply clone user-supplied objects carefully.

Cross Frame Scripting

LDAP Injection¶ LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection78.

All user inputs that are getting directly appended to any LDAP queries should be filtered through an encoding function that does proper encoding for LDAP9.

Example Incorrect Usage

String grpSearchFilter = searchFilter.replace("?",role);
groupResults = searchInGroupBase(grpSearchFilter,...) Example Correct Usage

String grpSearchFilter = searchFilter.replace("?", escapeSpecialCharactersForFilter(role));
groupResults = searchInGroupBase(grpSearchFilter,...)

HTTP Response Splitting (CRLF Injection)¶ Including unvalidated data in an HTTP header allows an attacker to specify the entirety of the HTTP response rendered by the browser. When an HTTP request contains unexpected CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n) characters, the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks24.

For example, if the below snippet was used to set cookie value, malicious value Wiley Hacker\r\nContent-Length:45\r\n\r\nHTTP/1.1 200 OK\r\n…. can result in generating two HTTP responses25.

String author = request.getParameter(AUTHOR_PARAM); ... Cookie cookie = new Cookie("author", author); cookie.setMaxAge(cookieExpiration); response.addCookie(cookie); HTTP/1.1 200 OK Set-Cookie: author=Wiley Hacker Content-Length:45

HTTP/1.1 200 OK ... Prevention Techniques¶ With regards to WSO2 Carbon 4 based products, Apache Tomcat will handle this internally, by disallowing "carriage return" and "line feed" characters from the header names or values2627.

If HTTP response generation is done in any other component, or any other HTTP transport implementation, it should be reviewed and confirmed to have a mechanism similar to Tomcat 628 and Tomcat 729 that performs necessary filtering. If such a mechanism is not present in transport implementation, a central filter should be used to read all the headers and do the necessary sanitization before passing the response to transport.

Session Prediction

Session prediction attack focuses on predicting session ID values that permit an attacker to bypass the authentication schema of an application. By analyzing and understanding the session ID generation process, an attacker can predict a valid session ID value and get access to the application.

In the first step, the attacker needs to collect some valid session ID values that are used to identify authenticated users. Then, the attacker must understand the structure of the session ID, the information that is used to create it, and the encryption or hash algorithm used by the application to protect it. Some bad implementations use session IDs composed of usernames or other predictable information, like timestamps or client IP addresses. In the worst case, this information is used in clear text or coded using some weak algorithm like base64 encoding.

In addition, the attacker can implement a brute force technique to generate and test different values of session ID until he successfully gets access to the application39.