FH
Frank Heyne
Sun, Feb 12, 2012 7:12 AM
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
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
PU
Pankaj Upadhyay
Sun, Feb 12, 2012 9:18 AM
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:
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
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.de>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
>
--
Thanks,
Pankaj Upadhyay
http://pankajupadhyay.in
PU
Pankaj Upadhyay
Sun, Feb 12, 2012 9:25 AM
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:
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
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.com>wrote:
> 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.de>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
>>
>
>
>
> --
> Thanks,
> Pankaj Upadhyay
> http://pankajupadhyay.in
>
>
>
--
Thanks,
Pankaj Upadhyay
http://pupadhyay.blogspot.com/
FH
Frank Heyne
Sun, Feb 12, 2012 9:33 AM
On 12 Feb 2012 at 14:48, Pankaj Upadhyay wrote:
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.
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
On 12 Feb 2012 at 14:48, Pankaj Upadhyay wrote:
> 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.
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
AH
Achim Hoffmann
Sun, Feb 12, 2012 11:06 AM
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
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
FH
Frank Heyne
Sun, Feb 12, 2012 11:34 AM
On 12 Feb 2012 at 12:06, Achim Hoffmann wrote:
Why would you life with a known vulnerability which can be removed very
easily?
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
On 12 Feb 2012 at 12:06, Achim Hoffmann wrote:
> Why would you life with a known vulnerability which can be removed very
> easily?
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
A
albino
Sun, Feb 12, 2012 1:50 PM
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
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
>
SE
super evr
Sun, Feb 12, 2012 5:47 PM
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:
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
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:
> 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
NN
Nick Nikiforakis
Sun, Feb 12, 2012 8:08 PM
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:
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?
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.de>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
>
PJ
Paul Johnston
Sun, Feb 12, 2012 8:28 PM
Hi,
First consider the case where a script echos back a parameter, e.g.
<?php print $_GET['SEARCH']?>
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:
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
--
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
Hi,
First consider the case where a script echos back a parameter, e.g.
<?php print $_GET['SEARCH']?>
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:
> 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
>
--
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
