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

Reflected XSS Issue in "callback" Parameter #112

Closed
thomaskonrad opened this Issue Dec 6, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@thomaskonrad
Copy link

thomaskonrad commented Dec 6, 2013

Hi,

my colleague just found out during a penetration test that the callback parameter (e.g., GET /js/routing?callback=fos.Router.setData HTTP/1.1) is directly reflected into the response. This makes it vulnerable to a reflected cross-site scripting attack (which is, to be honest, hard to exploit).

One could for example issue the following request: GET /js/routing?callback=alert('XSS');// HTTP/1.1. If called directly, the browsers usually do not interpret the response as JavaScript, but one could also insert HTML at the beginning and trick the browser into some content type guessing (which older versions of IE do).

The thing is, I don't really get the point of the callback function being dynamic, as it is statically defined in the /bundles/fosjsrouting/js/router.js file. Is this really necessary? If yes, what could we do to avoid reflected XSS here?

Thanks
Thomas

@willdurand

This comment has been minimized.

Copy link
Member

willdurand commented Dec 6, 2013

Well. Are you up to date? Because this part is handled by the JsonpCallbackValidator lib, and should not let alert('XSS') pass.

@stof

This comment has been minimized.

Copy link
Member

stof commented Dec 6, 2013

The callback being dynamic is the way JSONP works: the JS code knows what it wants to calls, not the PHP code.
and as mentionned by @willdurand, we are validating the callback before using it

@thomaskonrad

This comment has been minimized.

Copy link

thomaskonrad commented Dec 12, 2013

You are right guys, I was on 1.2 and there, the vulnerability was present. It is fixed in the newest version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment