Content spoofing (also known as content injection) is one of the most common web security vulnerabilities. It allows the end user of the vulnerable web application to falsify or modify the actual content of the web page.
Requirements:
- Domain – A domain to perform the tests
- Programming – Advanced programming skills
Responsibility:
In this tutorial, we will use hacking techniques for educational purposes only. We do not promote their use for profit or improper purposes. We are not responsible for any damage or harm that may be caused to the systems used. The user of this tutorial is solely responsible.
Knowledge:
- Linux – Not applicable
- Programming – High
- Kali Linux – Not applicable
- Windows – Not applicable
- Networking – Low
Overall tutorial level: Intermediate
Ideal for: Systems engineers, security engineers, pentesters
The user can exploit security vulnerabilities on the website to inject the content they want into the target website. When an application does not properly handle the data provided by the user, an attacker can supply content to a web application, usually through a parameter value, which is reflected back to the user.
There are two basic types of injection possible here:
- Text Injection
- HTML Injection
Text Injection
Text injection is a subcategory in which the user can only inject plain text into the page. In other words, it is not possible to inject executable JavaScript content, shell commands, or HTML content. In most cases, the user can only change part of the text content that is already on the website.
Text Content Injection
In some cases, the actual content to be displayeden la interfaz de usuario, se pasa a través de parámetros de solicitud. Por ejemplo, un simple formulario de acceso pasará la solicitud como se indica a continuación,
https://www.testsite.com/loginAction?userName=test123&password=test123/
You can have client-side validation to check whether the username and/or password are empty or not as expected, and based on that, you can display a message in the UI that these fields cannot be empty. The problem occurs when this message is attached as a request parameter like this.
https://www.testsite.com/loginAction?errorMsg=PasswordEmpty
Once the user sees this request, they can modify the message as they wish and it will be displayed on the screen. This type of injection can be performed anywhere on the site if a message is passed through request parameters. The greater the visibility of the injected text, the greater the chance that the site will be affected when someone exploits the vulnerability.
The site could be a credible website, and the user could add offensive content and spread the link, making it appear to the victim that the site owner has published offensive content.
HTML Injection
HTML injection is similar to text injection and, as the name suggests, allows HTML content to be injected. This is a relatively serious type of content spoofing vulnerability, as it is possible to make offensive content more visible with HTML than with plain text.
HTML content injection
Some sites also pass HTML content in request parameters. For example, in pop-ups or banners on the site, sites pass the actual HTML content in the parameters and place it inside a div tag, such as:
https://www.testsite.com/setAdContent?divMessage=<h1>ClickHere</h1>
And the value of the divMessage parameter is placed inside a div and rendered as unfiltered HTML. This is a serious vulnerability, and it is obvious that if exploited, it could further damage the credibility of the site.
It can be modified as follows:
https://www.testsite.com/setAdContent?divMessage=<marquee><h1>Don't Use this site</h1><marquee>
and your own site will have a scrolling message saying not to use it.
XSS via HTML injection
This could be even more serious when the parameter message is rendered directly without any encoding/filtering. In that case, it leads to an even more serious vulnerability of XSS aka Cross-site scripting where the user might be able to inject executable JavaScript that compromises the security of the website completely.
It will be something like this:
https://www.testsite.com/setAdContent?divMessage=<body onload=javascript:alert(1)>>
and your site is prone to cross-site scripting.
Security measures:
- Never construct and send error messages through request parameters.
- Prefer to use predefined messages in a properties file.
- Avoid passing HTML content through request parameters.
- If it is necessary to pass HTML content, encode/filter it before rendering it as HTML.
- Pass internal message keys to obtain predefined message values or unique IDs to identify the content to be displayed.
