XSTE... Catchy title, right? truth be told, it's a fancy name that a collegue of mine and I gave to a Content Spoofing attack we conducted on a penetration test last week. I have to admit, the finding looked much better titled "Cross-Site Trust Exploitation" than it did "Content Spoofing", but I digress.

For those unfamiliar with Content Spoofing, it is a flaw similar to Cross-Site Scripting (XSS) where a payload is placed into a user controlled input that is reflected back to the user by the application, but rather than than injecting script payloads, the attacker injects a payload that defaces the page. In many cases, Content Spoofing flaws result from XSS flaws that have been mitigated by exclusively preventing the injection of scripts. Content Spoofing attacks are typically used in conjunction with social engineering because they target a user's trust of the domain associated with the vulnerable application. Let me explain.

Let's say you come across a web page that looks something like this.

When I see something like this, I immediately think XSS. The page has clearly reflected something we control back to us.

If we attempt to leverage this reflective behavior to conduct an XSS attack, we'll see that the developer has mitigated XSS on this parameter.

• Payload

https://172.21.9.71:8000/<script>alert(42)</script>

• Result

In this case, HTML output encoding was used to mitigate XSS. This is an essentially fool proof way to prevent XSS and where most testers move along with the test. But there is still danger lurking here. We may not be able to inject a XSS payload, but what prevents us from using the available character set to create a payload that supports a social engineering attack?

• Payload

https://172.21.9.71:8000/en-US/secure_login'' was not found \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Security Alert!!! This Splunk Server Is Currently Under Attack. The Server's Secret Key May Be Compromised. Please Authenticate Through The Backup Proxy @172.22.22.199:8000 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ The path ''/en-US/secure_login

• Result

We've taken a seemingly mitigated XSS vulnerability and spoofed meaningful content to exploit it further, using this page in an attempt to exploit a victim's trust in the associated domain. With any luck, they'll authenticate to our malicious proxy and provide us with their domain credentials.