You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The /cors endpoint, as configured currently echo's any params passed to the /attachinary/cors endpoint. This means that unscrupulous users can use this endpoint to trick JavaScript code into thinking that the content coming back is from a safe endpoint.
Example
Let's say I have a route in my SPA that looks like this:
Now if my application, receiving that data renders that into the document without first scrubbing, the result will be a successful XSS attack. Its not unreasonable to think that my application should be returning html safe strings, but the combination of the path traversal hack and the /attachinary/cors endpoint blindly echo-ing input creates an easy vector for XSS.
Is there a reason the cors endpoint should be echoing back params that should be considered unsafe?
The text was updated successfully, but these errors were encountered:
ebenoist
changed the title
CORS endpoint echo's unsafe JSON
CORS endpoint echoes unsafe JSON
Apr 20, 2020
ebenoist
changed the title
CORS endpoint echoes unsafe JSON
CORS endpoint echoes unsafe JSON / Potential XSS
Apr 20, 2020
The /cors endpoint, as configured currently echo's any params passed to the
/attachinary/cors
endpoint. This means that unscrupulous users can use this endpoint to trick JavaScript code into thinking that the content coming back is from a safe endpoint.Example
Let's say I have a route in my SPA that looks like this:
https://mysite.com/products/my-great-product
An unscrupulous user can trick someone into clicking on a link that looks like this:
https://mysite.com/products/../../attachinary/cors?title="<script>alert('foo')</script>"
If my JavaScript code interprets everything after the
products/
as the slug for my application, I may naively make a call with that value:Which will resolve to
https://mysite.com/attachinary/cors?description="<script>alert('foo')</script>"
and return whatever was in the params.Now if my application, receiving that data renders that into the document without first scrubbing, the result will be a successful XSS attack. Its not unreasonable to think that my application should be returning html safe strings, but the combination of the path traversal hack and the
/attachinary/cors
endpoint blindly echo-ing input creates an easy vector for XSS.Is there a reason the cors endpoint should be echoing back params that should be considered unsafe?
The text was updated successfully, but these errors were encountered: