SJ
steve jensen
Mon, Feb 13, 2012 3:56 AM
Exploitable via a MitM attack...which based on that, means you could do more malicious stuff than just XSS...
From: albinowax@gmail.com
To: websecurity@lists.webappsec.org
Date: Sun, 12 Feb 2012 13:50:40 +0000
Subject: Re: [WEB SECURITY] Is XSS via HTTP_REFERER possible in this case?
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:
Hello,
On a page which is ONLY presented back to the user (lets say search
results), a
web application does something stupid like:
<?php print $_SESSION['HTTP_REFERER'] ?>
There are people who say this would be an XSS vulnerability.
Sure this is not clean code, but I wonder how this could be used for XSS?
There is no way to present this page to other users, so the user can only
shoot
into his own foot, which is not XSS in my opinion.
For XSS an attacker would need to make the users browser send a faked
referer,
which is impossible I think?
Before answering, please read the first sentence again ;-)
We only speak about pages presented back to the user. Showing unfiltered
referer on feedback pages, for instance, which will be viewed by
different
users, is XSS for sure, I know.
Any opinions regarding the classifying of this special case?
Frank Heyne
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Exploitable via a MitM attack...which based on that, means you could do more malicious stuff than just XSS...
> From: albinowax@gmail.com
> To: websecurity@lists.webappsec.org
> Date: Sun, 12 Feb 2012 13:50:40 +0000
> Subject: Re: [WEB SECURITY] Is XSS via HTTP_REFERER possible in this case?
>
> 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:
> > Hello,
> >
> > On a page which is ONLY presented back to the user (lets say search
> > results), a
> > web application does something stupid like:
> > <?php print $_SESSION['HTTP_REFERER'] ?>
> >
> > There are people who say this would be an XSS vulnerability.
> > Sure this is not clean code, but I wonder how this could be used for XSS?
> > There is no way to present this page to other users, so the user can only
> > shoot
> > into his own foot, which is not XSS in my opinion.
> > For XSS an attacker would need to make the users browser send a faked
> > referer,
> > which is impossible I think?
> >
> > Before answering, please read the first sentence again ;-)
> > We only speak about pages presented back to the user. Showing unfiltered
> > referer on feedback pages, for instance, which will be viewed by
> > different
> > users, is XSS for sure, I know.
> >
> > Any opinions regarding the classifying of this special case?
> >
> > Frank Heyne
> >
> >
> > _______________________________________________
> > The Web Security Mailing List
> >
> > WebSecurity RSS Feed
> > http://www.webappsec.org/rss/websecurity.rss
> >
> > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> >
> > WASC on Twitter
> > http://twitter.com/wascupdates
> >
> > websecurity@lists.webappsec.org
> > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
> >
>
> _______________________________________________
> The Web Security Mailing List
>
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
> websecurity@lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
AH
Achim Hoffmann
Mon, Feb 13, 2012 8:34 AM
so just to summarize the other posts:
- modern browsers do not allow to set the referer
- modern browsers send the URL itself and the referer url-encoded properly
- there still exist plugins (flash, java) which can be used to set the referer
- 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:
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:
Hello,
On a page which is ONLY presented back to the user (lets say search results), a
web application does something stupid like:
<?php print $_SESSION['HTTP_REFERER'] ?>
There are people who say this would be an XSS vulnerability.
Sure this is not clean code, but I wonder how this could be used for XSS?
There is no way to present this page to other users, so the user can only shoot
into his own foot, which is not XSS in my opinion.
For XSS an attacker would need to make the users browser send a faked referer,
which is impossible I think?
Before answering, please read the first sentence again ;-)
We only speak about pages presented back to the user. Showing unfiltered
referer on feedback pages, for instance, which will be viewed by different
users, is XSS for sure, I know.
Any opinions regarding the classifying of this special case?
Frank Heyne
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:
> 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:
>> Hello,
>>
>> On a page which is ONLY presented back to the user (lets say search results), a
>> web application does something stupid like:
>> <?php print $_SESSION['HTTP_REFERER'] ?>
>>
>> There are people who say this would be an XSS vulnerability.
>> Sure this is not clean code, but I wonder how this could be used for XSS?
>> There is no way to present this page to other users, so the user can only shoot
>> into his own foot, which is not XSS in my opinion.
>> For XSS an attacker would need to make the users browser send a faked referer,
>> which is impossible I think?
>>
>> Before answering, please read the first sentence again ;-)
>> We only speak about pages presented back to the user. Showing unfiltered
>> referer on feedback pages, for instance, which will be viewed by different
>> users, is XSS for sure, I know.
>>
>> Any opinions regarding the classifying of this special case?
>>
>> Frank Heyne
A
albino
Mon, Feb 13, 2012 9:29 AM
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 is exploitable in internet explorer and occasionally in
browsers; just direct the victim to a page with the XSS in the
load the target page in an iframe so the XSS gets transferred
Referer. There are plenty of articles on the topic.
albino
On Sun, Feb 12, 2012, at 08:12 AM, Frank Heyne wrote:
Hello,
On a page which is ONLY presented back to the user (lets say
results), a
web application does something stupid like:
<?php print $_SESSION['HTTP_REFERER'] ?>
There are people who say this would be an XSS vulnerability.
Sure this is not clean code, but I wonder how this could be
There is no way to present this page to other users, so the
shoot
into his own foot, which is not XSS in my opinion.
For XSS an attacker would need to make the users browser send
referer,
which is impossible I think?
Before answering, please read the first sentence again ;-)
We only speak about pages presented back to the user. Showing
referer on feedback pages, for instance, which will be viewed
different
users, is XSS for sure, I know.
Any opinions regarding the classifying of this special case?
Frank Heyne
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn
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...
> From: albinowax@gmail.com
> To: websecurity@lists.webappsec.org
> Date: Sun, 12 Feb 2012 13:50:40 +0000
> Subject: Re: [WEB SECURITY] Is XSS via HTTP_REFERER possible in
this case?
>
> 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:
> > Hello,
> >
> > On a page which is ONLY presented back to the user (lets say
search
> > results), a
> > web application does something stupid like:
> > <?php print $_SESSION['HTTP_REFERER'] ?>
> >
> > There are people who say this would be an XSS vulnerability.
> > Sure this is not clean code, but I wonder how this could be
used for XSS?
> > There is no way to present this page to other users, so the
user can only
> > shoot
> > into his own foot, which is not XSS in my opinion.
> > For XSS an attacker would need to make the users browser send
a faked
> > referer,
> > which is impossible I think?
> >
> > Before answering, please read the first sentence again ;-)
> > We only speak about pages presented back to the user. Showing
unfiltered
> > referer on feedback pages, for instance, which will be viewed
by
> > different
> > users, is XSS for sure, I know.
> >
> > Any opinions regarding the classifying of this special case?
> >
> > Frank Heyne
> >
> >
> > _______________________________________________
> > The Web Security Mailing List
> >
> > WebSecurity RSS Feed
> > http://www.webappsec.org/rss/websecurity.rss
> >
> > Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> >
> > WASC on Twitter
> > http://twitter.com/wascupdates
> >
> > websecurity@lists.webappsec.org
> >
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.web
appsec.org
> >
>
> _______________________________________________
> The Web Security Mailing List
>
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>
> Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
> websecurity@lists.webappsec.org
>
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.web
appsec.org
SD
Stefano Di Paola
Mon, Feb 13, 2012 6:36 PM
Hi Frank,
You can check it on your own in several ways.
One way is by doing the following:
- Create the vuln testcase, ref.php:
<?=$_SERVER["HTTP_REFERER"]?>
- Create the attack testcase iframe.php:
<iframe src="/ref.php"></iframe>
- 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:
Hello,
On a page which is ONLY presented back to the user (lets say search results), a
web application does something stupid like:
<?php print $_SESSION['HTTP_REFERER'] ?>
There are people who say this would be an XSS vulnerability.
Sure this is not clean code, but I wonder how this could be used for XSS?
There is no way to present this page to other users, so the user can only shoot
into his own foot, which is not XSS in my opinion.
For XSS an attacker would need to make the users browser send a faked referer,
which is impossible I think?
Before answering, please read the first sentence again ;-)
We only speak about pages presented back to the user. Showing unfiltered
referer on feedback pages, for instance, which will be viewed by different
users, is XSS for sure, I know.
Any opinions regarding the classifying of this special case?
Frank Heyne
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.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:
<?=$_SERVER["HTTP_REFERER"]?>
2. Create the attack testcase iframe.php:
<iframe src="/ref.php"></iframe>
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:
> Hello,
>
> On a page which is ONLY presented back to the user (lets say search results), a
> web application does something stupid like:
> <?php print $_SESSION['HTTP_REFERER'] ?>
>
> There are people who say this would be an XSS vulnerability.
> Sure this is not clean code, but I wonder how this could be used for XSS?
> There is no way to present this page to other users, so the user can only shoot
> into his own foot, which is not XSS in my opinion.
> For XSS an attacker would need to make the users browser send a faked referer,
> which is impossible I think?
>
> Before answering, please read the first sentence again ;-)
> We only speak about pages presented back to the user. Showing unfiltered
> referer on feedback pages, for instance, which will be viewed by different
> users, is XSS for sure, I know.
>
> Any opinions regarding the classifying of this special case?
>
> Frank Heyne
>
>
> _______________________________________________
> The Web Security Mailing List
>
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
> websecurity@lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>
--
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer
Owasp Italy R&D Director
Web: www.wisec.it
Twitter: http://twitter.com/WisecWisec
..................
M
MaXe
Mon, Feb 13, 2012 9:54 PM
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:
Hi Frank,
You can check it on your own in several ways.
One way is by doing the following:
- Create the vuln testcase, ref.php:
<?=$_SERVER["HTTP_REFERER"]?>
- Create the attack testcase iframe.php:
<iframe src="/ref.php"></iframe>
- 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:
Hello,
On a page which is ONLY presented back to the user (lets say search
results), a
web application does something stupid like:
<?php print $_SESSION['HTTP_REFERER'] ?>
There are people who say this would be an XSS vulnerability.
Sure this is not clean code, but I wonder how this could be used for
There is no way to present this page to other users, so the user can
only shoot
into his own foot, which is not XSS in my opinion.
For XSS an attacker would need to make the users browser send a faked
referer,
which is impossible I think?
Before answering, please read the first sentence again ;-)
We only speak about pages presented back to the user. Showing
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:
> 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:
> <?=$_SERVER["HTTP_REFERER"]?>
>
> 2. Create the attack testcase iframe.php:
>
> <iframe src="/ref.php"></iframe>
>
> 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:
>> Hello,
>>
>> On a page which is ONLY presented back to the user (lets say search
>> results), a
>> web application does something stupid like:
>> <?php print $_SESSION['HTTP_REFERER'] ?>
>>
>> There are people who say this would be an XSS vulnerability.
>> Sure this is not clean code, but I wonder how this could be used for
XSS?
>> There is no way to present this page to other users, so the user can
>> only shoot
>> into his own foot, which is not XSS in my opinion.
>> For XSS an attacker would need to make the users browser send a faked
>> referer,
>> which is impossible I think?
>>
>> Before answering, please read the first sentence again ;-)
>> We only speak about pages presented back to the user. Showing
unfiltered
>> referer on feedback pages, for instance, which will be viewed by
>> different
>> users, is XSS for sure, I know.
>>
>> Any opinions regarding the classifying of this special case?
>>
>> Frank Heyne
>>
>>
>> _______________________________________________
>> The Web Security Mailing List
>>
>> WebSecurity RSS Feed
>> http://www.webappsec.org/rss/websecurity.rss
>>
>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>> WASC on Twitter
>> http://twitter.com/wascupdates
>>
>> websecurity@lists.webappsec.org
>>
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>>
