Skip to main content

Text Based Injection | Content Spoofing | Low Impact Common Web Vulnerability

Text Based Injection: Text injection or Text-Based Injection(TBI) is an injection in which user input is reflected as it is in the application response as plaintext. This is one of the ways to perform content spoofing also referred to as content injection or virtual defacement which can be used in phishing attacks.

An application is vulnerable to Text injection when it does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, or from the URL only that is reflected back to the user. The user will be presented with a modified page under the context of the trusted domain. 


Attack Type: Client-Side Vulnerability
Severity: Low

Audit Guidelines

Text injection can be easily found where
1) User input via parameter or directly in the URL is reflected in the page response.
2) Content-Type: text/plain
3) Application is giving default error pages

Proof of Concept

If you research little more to understand why it is happening and what is the issue here. You will get an answer for 'what is the issue' that the application is giving a default error page. 

For 'why it is happening', we know the answer, right? 
Anyway, the answer is user input via parameter or directly in the URL is reflected in the page response.

Error Page
URL- https://example.com/captcha 

Error page


Modified Error Page
URL- https://example.com/captcha/SS%2F%20%20%20is%20not%20available.%20Please%20visit%20-%20-%20-%20-%20https://attacker.com%20%20-%20-%20-%20-%20as%20resource%20

 Modified Error Page



How Google Do it
Google handles the error pages really well. Here is the screenshot for your reference.

Good Handling of user-supplied input in URL by Google

Impact

An attacker can use text injection vulnerability to present a customized message on the application that can phish users into believing that the message is legitimate. The intent is typical to tick victims, although sometimes the actual purpose may be to simply misrepresent the organization or an individual. This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely misunderstood as a kind of a bug that brings no impact. 

Recommendations

The application should only accept the values and types that are defined for parameters and should be checked at the server-side whether there is change content, if there is change, then the application should reject that request. Also, never construct and send messages via URL in the page response. Prefer using messages predefined in a property file.

For Default Error pages

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is user-friendly in addition to being a good security practice, and can be done by specifying custom error pages for error codes like 404, 403, 500, etc.

References

https://www.owasp.org/index.php/Content_Spoofing
https://resources.infosecinstitute.com/content-spoofing/#gref
https://www.geeksforgeeks.org/content-spoofing/
https://www.digitalocean.com/community/tutorials/how-to-configure-apache-to-use-custom-error-pages-on-ubuntu-14-04

Security blog of the month

CVE-2018-12234: Reflected Cross Site Scripting(XSS) in Adrenalin 5.4.0 HRMS Software | GeneralInfo [issue 1 of 5]

As a cybersecurity expert, I come across a wide variety of vulnerabilities, ranging from critical severity to low severity and sometimes informative (Classification - CVSS v3). Some time ago, I was performing my security assessment as usual for a (confidential) customer for their HRMS web application, a third-party software whose vendor is " Adrenaline". CVE ID: CVE-2018-12234 Vulnerability Name: Reflected Cross Site Scripting(XSS) Product: Adrenalin HRMS Affected Version: 5.4.0 Source: MITRE Credits:    Rishu Ranjan