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. |

| Subject: | Re: Importing large code piece into Javascript context without SCRIPT SRC=... |
|---|---|
| Date: | Mon, 17 Oct 2005 10:52:27 +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/).
Come to think of it, I have another idea. The attacker can use the document.location itself to provide the payload to its bridge-head. That is, the attacker can add an unexpected parameter to the URL, populate it with the payload, and access it in the bridge-head. In fact, it can be even better: the attacker can use the fragment trick (discussed in my "DOM Based Cross Site Scripting" paper - http://www.webappsec.org/projects/articles/071105.shtml) to totally conceal the payload from the application. So the attack URL will look like: http://target.site/vulnscript.cgi?injectme=<script>eval(document.location.search.substr(69))</script>#...JS payload here... This method has two downsides though: 1. It is less inconspicious - the victim sees a large payload in the URL (this may be solved by an innocent looking URL that redirects to the attacking URL). 2. It is restricted by the maximum URL size the browser is willing to handle. However, unlike the original posting, it does not require to inject another object (IFRAME, in the original example) and reference it. -Amit
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: (clarification) GET and POST Methods Accepted, Greg Skouby |
|---|---|
| Next by Date: | Re: (Quite a few!) volunteers needed for Turkish translation of OWASP Guide v2.0, kerem . kusmezer |
| Previous by Thread: | Importing large code piece into Javascript context without SCRIPT SRC=..., Amit Klein (AKsecurity) |
| Next by Thread: | MySpace XSS Istanbul now Cross-Stantinople, Evans, Arian |
| Indexes: | [Date] [Thread] [Top] [All Lists] |