• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


Content Spoofing

Page history last edited by Robert Auger 14 years, 5 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-12



Content Spoofing

Content Spoofing is an attack technique that allows an attacker to inject a malicious payload that is later misrepresented as legitimate content of a web application.


Text Only Content Spoofing

A common approach to dynamically build pages involves passing the body or portions thereof into the page via a query string value. This approach is common on error pages, or sites providing story or news entries. The content specified in this parameter is later reflected into the page to provide the content for the page.





The "title" parameter in this example specifies the content that will appear in the HTML body for the news entries. If an attacker where to replace this content with something more sinister they might be able to falsify statements on the destination website.





Upon visiting this link the user would believe the content being displayed as legitimate. In this example the falsified content is directly reflected back on the same page, however it is possible this payload may persist and be displayed on a future page visited by that user.


Markup Reflected Content Spoofing

Some web pages are served using dynamically built HTML content sources. For example, the source location of a frame <frame src="http://foo.example/file.html">) could be specified by a URL parameter value. (http://foo.example/page?frame_src=http://foo.example/file.html). An attacker may be able to replace the "frame_src" parameter value with "frame_src=http://attacker.example/spoof.html". Unlike redirectors, when the resulting web page is served the browser location bar visibly remains under the user expected domain (foo.example), but the foreign data (attacker.example) is shrouded by legitimate content.


Specially crafted links can be sent to a user via e-mail, instant messages, left on bulletin board postings, or forced upon users by a Cross-site Scripting attack [5]. If an attacker gets a user to visit a web page designated by their malicious URL, the user will believe he is viewing authentic content from one location when he is not. Users will implicitly trust the spoofed content since the browser location bar displays http://foo.example, when in fact the underlying HTML frame is referencing http://attacker.example.


This attack exploits the trust relationship established between the user and the web site. The technique has been used to create fake web pages including login forms, defacements, false press releases, etc.




Creating a spoofed press release. Let's say a web site uses dynamically created HTML frames for their press release web pages. A user would visit a link such as (http://foo.example/pr?pg=http://foo.example/pr/01012003.html). The resulting web page HTML would be:

Code Snippet:

<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" src="menu.html">
<FRAME NAME="pr_content" 


The "pr" web application in the example above creates the HTML with a static menu and a dynamically generated FRAME SRC. The "pr_content" frame pulls its source from the URL parameter value of "pg" to display the requested press release content. But what if an attacker altered the normal URL to http://foo.example/pr?pg=http://attacker.example/spoofed_press_release.html? Without properly sanity checking the "pg" value, the resulting HTML would be:

Code Snippet:


<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" src="menu.html">
<FRAME NAME="pr_content" src=" http://attacker.example/spoofed_press_release.html">


To the end user, the "attacker.example" spoofed content appears authentic and delivered from a legitimate source. It is important to understand that if you are vulnerable to Cross-Site Scripting (XSS) you are likely vulnerable to content spoofing. Additionally you can be protected from XSS and still be vulnerable to Content Spoofing.



[1] "A new spoof: all frames-based sites are vulnerable", SecureXpert Labs



[2] "Chapter 7 of 'Preventing Web Attacks with Apache' ", Ryan Barnett



[3] "Wired.com Image Viewer Hacked to Create Phony Steve Jobs Health Story"



URL Redirector Abuse

[4] http://projects.webappsec.org/URL-Redirector-Abuse


Cross-site Scripting

[5] http://projects.webappsec.org/Cross-Site-Scripting

Comments (0)

You don't have permission to comment on this page.