Frame Injection Fun
Frame injection vulnerabilities, although some people might consider them the same as HTML injection/XSS or even a subset, they really are not the same. Here is why:
- There is no need to inject special control characters such as angle brackets (unlike HTMLi/XSS)
- HTMLi/XSS filtering routines will not project against frame injection since the attacker only needs to insert a URL in the non-sanitized parameter
The best way to explain what I mean is to show an example. Most frame injection issues occur in web applications because dynamic frameset/iframe insertion is not implemented with enough filtering. For instance, say that we have the following URL on the target site:
The previous PoC URL will cause the entered credentials to be submitted to www.gnucitizen.org when clicking on Sign in, so please do NOT submit any real credentials!
pIn short:p The attacker has managed to display a non-legitimate third-party page, while the legitimate domain (mail.google.com in this case) is shown in the address bar.The beauty of frame injection attacks is that the attacker is able to impersonate a trusted entity without needing to bypass XSS/HTMLi filters or even break into the target server.
Needless to say, in real-life the attacker would most likely automate the process of obtaining the harvested credentials by using a tool such as our x.php data-theft script.
if (top.frames.length!=0) top.location=self.document.location;
The first script can be used to secure the page framed...