Hi, Anarag, there are a number of issues with this technique. Your
first line says if the referer is not non-existant (love those double
negatives) forbid the JS content. Often times referring URLs are not
there, in the case of a number of client side security products, and it
can also be forced to disappear by using a META Refresh. That does
require that the user is forwarded to the page or clicks on it from a
link in an email or something else, but it certainly isn't bullet proof.
The second condition is that it is a certain URL. Flash can help to
spoof referrers. Again, I wouldn't rely on that.
Thirdly you are saying *.js followed by nothing, but I believe you can
include a query string to evade that. Either way, a .js extention is
not a requirement for embedded JavaScript. It can literally be named
anything (.html, .jpg .whatever, etc...).
Lastly, .js files are not normally the cause of XSS (calling them
anyway). Generally it's output validation problems on your system. So
this really should be written to protect .aspx, .dll, .php or whatever
files, that are called by the client that return the XSS. Not that I
think this is a technique that has a lot of merit, but if you want to
continue on the path, you should think about protecting the dynamic
content more than the static content (I'm making an assumption that your
.js file is not JSON but rather a static include), unless you are
concerned about DOM based XSS in static .html files or something.
So although this may provide some small value for people who are
leaching your JS files, it won't do a lot to protect against XSS.
Sorry.
On Mon, 8 Jan 2007, Anurag Agarwal wrote:
I was wondering if we add the following lines to the .htaccess files, will it protect us from XSS attacks (assuming there is no external javascript on the website)?
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mysite.com/.*$ [NC]
RewriteRule \.(js)$ - [F]
If we want to use external javascript files (for ex. google analytics, etc),
then we can add trusted host in the lines above.
1. Is this approach useful at all?
2. Disadvantages/Limitations of using this approach?
Cheers,
Anurag Agarwal
SEEC - An application security search engine
Web: www.attacklabs.com , www.myappsecurity.com
Email : anurag.agarwal@yahoo.com
Blog : http://myappsecurity.blogspot.com
-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
-------------------------------------------------------------------------
Sponsored by: Watchfire
Testing web application for security vulnerabilities? Try AppScanB.. F
eatures that include Privilege Escalation Testing, Complex Authentication
Support and Validation Highlighting and Reasoning are just some of the
reasons more security professionals trust AppScan than any other solutions.
Change the way you think about application security testing -
download AppScan today!
https://www.watchfire.com/securearea/appscancamp.aspx?id=701500000008fHZ
--------------------------------------------------------------------------
