Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-site-scripting error #1018

Closed
CycoPH opened this issue Feb 25, 2016 · 1 comment
Closed

Cross-site-scripting error #1018

CycoPH opened this issue Feb 25, 2016 · 1 comment

Comments

@CycoPH
Copy link

CycoPH commented Feb 25, 2016

I tested my restify server with this:
https://localhost:3000/no5_such3_file7.pl?%22%3E%3Cscript%3Ealert(73541);%3C/script%3E

The returned data contains "<script>alert(73541);</script>" which some browsers will execute.

Simple solution is to change the ResourceNotFoundError at the end of the Router.prototype.find to something like this:

callback(new ResourceNotFoundError('%s does not exist', url.parse(req.url).pathname));

@smcpeak
Copy link

smcpeak commented Aug 7, 2019

Are you sure this is fully fixed? In restify 8.4.0 (latest), if I modify lib/router.js to revert the fix in commit a015067 (by passing req.url instead of pathname to ResourceNotFoundError), then supply the proof of concept URL above, I get back:

{"code":"ResourceNotFound","message":"/notfound?a=b&c=d%22%3E%3Cscript%3Ealert(73541);%3C/script%3E does not exist"}

Ostensibly, "some browsers will execute" this, although mine (FF 68.0.1) does not.

With the fix applied, the same URL produces:

{"code":"ResourceNotFound","message":"/notfound does not exist"}

But also with the fix, if I merely replace "?" with "/" in the POC URL, I get back:

{"code":"ResourceNotFound","message":"/notfound/a=b&c=d%22%3E%3Cscript%3Ealert(73541);%3C/script%3E does not exist"}

To me, this looks functionally identical to the original, supposedly dangerous response. Could it really be the case that the "some browsers" that will execute the JS in original response will not execute the code in that last response?

Or, said another way: the original fix seems to presume that the "pathname" portion of the URL is safer than the "query" portion, but I don't think that is true. I suspect that either there never was a real bug to begin with, or the purported fix is inadequate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants