Frank,

Forged Referers are used for business promotion and marketing as well.
Spammers use some open websites which allow them to visit the pages they
want but with a forged referer. Those websites keep a track of person
visiting them so basically they keep a list of all  the HTTP referers which
could be used to perform XSS in case of improper validation.

Coming to your code snippet, its a clearcase of XSS. You can create a page
which will hit this application but with a fake referer. So if victim
clicks on your link, in turn your link will execute a XSS on this website.

for more reference:
1 - http://www.mustap.com/phpzone_post_62_how-to-bypass-the-referer-se
2 - See Firefox addon - refcontrol

On Sun, Feb 12, 2012 at 12:42 PM, Frank Heyne fh@rcs.urz.tu-dresden.dewrote:

--
Thanks,
Pankaj Upadhyay
http://pankajupadhyay.in

one more via flash
http://www.securityfocus.com/archive/1/441014

On Sun, Feb 12, 2012 at 2:48 PM, Pankaj Upadhyay mr.p.upadhyay@gmail.comwrote:

--
Thanks,
Pankaj Upadhyay
http://pupadhyay.blogspot.com/

On 12 Feb 2012 at 14:48, Pankaj Upadhyay wrote:

I don't think so?
If victim clicks on this link, its browser will send the address of the faked
page as referer to the vulnerable server, right? But this is not a faked
referer, its the real one?

Frank Heyne

All modern browser no longer allow to set the referer i.e. using JavaScript.
So there is no simple way to exploit this XSS except by the user itself.
However, if there is another exploitable vulnerabilty, such as a proxy
or insecure transport (http instead of https), then attacking the user
remotely is possible.

I.g. every known vulnerability should be removed!
Why would you life with a known vulnerability which can be removed very
easily?

Achim

Am 12.02.2012 08:12, schrieb Frank Heyne:

On 12 Feb 2012 at 12:06, Achim Hoffmann wrote:

No I don't want to life with it, but I had a discussion that it would be
impossible to exploit the bad programming style in this special case, and that
it is no xss at all therefore.

All I need for this discussion is some example that it really can be exploited
by a remote attacker.
Pankaj Upadhyay pointed me to http://www.securityfocus.com/archive/1/441014 by
Amit Klein, which will not work with current browsers and current Flash.
players.

Frank Heyne

This is exploitable in internet explorer and occasionally in other
browsers; just direct the victim to a page with the XSS in the URL, then
load the target page in an iframe so the XSS gets transferred into the
Referer. There are plenty of articles on the topic.

albino

On Sun, Feb 12, 2012, at 08:12 AM, Frank Heyne wrote:

Not sure what exactly you mean by "page which is ONLY presented back
to the user." unless you first check the REFERER before giving access
to the page. If that's not the case...

XSS on HTTP_REFERER shouldn't be too hard. Attacker can host a web
page at http://attacker.host/<script>alert(1)</script>.html, and have
that page redirect them to your sites search result page at
/search.html?q=cats which would set the REFERER to
"http://attacker.host/<script>alert(1)</script>.html", which will get
written to the page for XSS.

On Feb 12, 2012, at 1:06 AM, Frank Heyne fh@rcs.urz.tu-dresden.de wrote:

Hi Frank,

If your victim uses Internet Explorer the exploitation is pretty
straightforward. You first
have your victim visit a page that you control, in which you have
JavaScript in its GET
parameters. That page then can redirect the user automatically to the
vulnerable page
thus forcing the victim's browser to add the attacker-controlled URL (the
one that includes
the malicious JavaScript) in the victim's referrer. I made a proof of
concept here:

http://people.cs.kuleuven.be/~nick.nikiforakis/kittens.html?<img src="hackerKittyfoofoo.jpg" onerror="alert(document.domain+': XSS')">

Once you click on the link on that page (with IE) you should see an alert
box from the
domain hosting the vulnerable script. You need IE because the other
browsers (I tested
it with FF and Chrome) URL-escape any special characters from the URL
before copying
it into the Referer header.

Regards
Nick Nikiforakis

On Sun, Feb 12, 2012 at 8:12 AM, Frank Heyne fh@rcs.urz.tu-dresden.dewrote:

Hi,

First consider the case where a script echos back a parameter, e.g.

This absolutely is a vulnerability. You might say a user can only XSS
themselves, but that is not the case. If an attacker can persuade the
victim to click on a link they control, the attacker can inject
JavaScript into the victim's browser. The impact is the same as for
stored XSS, although it is somewhat more difficult to perform a
successful attack. This is called reflective XSS and is well studied.

Now, considering your question, which is around the referer. In a stored
XSS scenario, the attacker can set the Referer header to whatever they
like, using a tool like Burp. So, absolutely this is a problem.

In a reflective XSS scenario it's a bit harder, because the referer is
generated by the victim's browser. I just did a quick test of this, and
with recent Firefox/IE it is not possible. If the URL contains something
like <script> those browsers URL encode the current URL before putting
it in the referer header. However, with IE 6 you can do XSS in this manner.

In my book, if the app is vulnerable with IE 6, it needs to be fixed. In
fact, I would report the vulnerability with the same severity as if it
was vulnerable with all browsers.

Paul

On 12/02/2012 07:12, Frank Heyne wrote:

--
Pentest - When a tick in the box is not enough

Paul Johnston - IT Security Consultant / Tiger SST
Pentest Limited - ISO 9001 (cert 16055) / ISO 27001 (cert 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

Exploitable via a MitM attack...which based on that, means you could do more malicious stuff than just XSS...

so just to summarize the other posts:

1. modern browsers do not allow to set the referer
2. modern browsers send the URL itself and the referer url-encoded properly
3. there still exist plugins (flash, java) which can be used to set the referer
4. there may exist additional vulnerabilities outside your application
   (HTTP Request Smuggling, HTTP Response Splitting, ..., stored XSS)

Conclusion:
a) just counting 1. and 2. you're safe
b) if there is at least one user using improper browser (like IE6), then it's
definitely and very easy remotly exploitable
c) if any system in your topology (reverse proxy, cache, whatever) sends the
headers url-decoded, the exploit is as simple as b) for any browser
d) if -in a dearanged situation- your developer changes the code from
print $_SESSION['HTTP_REFERER']
to
$ua=urldecode($_SESSION['HTTP_REFERER']);
print $ua;
it's exploitable for any browser
e) keep in mind that there is also $_SERVER['HTTP_REFERER']

Or in short: it is remotly exploitable.

If your controller talks about probability and risk, let him sign that he is
personal liable for any damage unlimitted, may be this changes his mind  SCNR

Am 12.02.2012 12:06, schrieb Achim Hoffmann:

I did not intend to imply a mitm attack, you might want to try
reading some of the articles on the topic for a clearer
description.

albino

On Sun, Feb 12, 2012, at 09:56 PM, steve jensen wrote:

Exploitable via a MitM attack...which based on that, means you
could do more malicious stuff than just XSS...

this case?

other

URL, then

into the

search

used for XSS?

user can only

a faked

unfiltered

by

http://www.linkedin.com/e/gis/83336/4B20E4374DBA

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.web
appsec.org

http://www.linkedin.com/e/gis/83336/4B20E4374DBA

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.web
appsec.org

Hi Frank,
You can check it on your own in several ways.

One way is by doing the following:

1. Create the vuln testcase, ref.php:

2. Create the attack testcase iframe.php:

3. open all your browsers and go to:

http://127.0.0.1/iframe.php?<img src=test onerror=alert(1)>

You'll see that IE doesn't encode the referrer.

Bottom line: Yes it's exploitable.

Cheers,
Stefano

Il giorno dom, 12/02/2012 alle 08.12 +0100, Frank Heyne ha scritto:

--
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

Web: www.wisec.it
Twitter: http://twitter.com/WisecWisec
..................

Hi folks,

Sorry about nit-picking, but in case you don't have short_tags enabled in
php.ini, as not all websites do, write: <?php echo
$_SERVER['HTTP_REFERER']; ?> instead.

On Mon, 13 Feb 2012 19:36:26 +0100, Stefano Di Paola
stefano.dipaola@wisec.it wrote:

XSS?

unfiltered

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org