Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The key to this exploit is that JavaScript that is designed to be fetched via XHR and then eval()d can be used by another site to "steal" data by linking to it in a script tag.

An obvious fix would be to send that JavaScript with a content type other than "application/javascript" or "text/javascript"... but considering some browsers execute JS sent with the wrong content type I wouldn't trust that to actually work.

A technique that definitely does work is to have the first line of the JS prevent execution in some way. When the code is fetched by XHR this line can be stripped out before calling eval(). This cannot be done by a malicious page that includes the code using a script tag.

I seem to remember seeing Google use "while(true);" for this exact purpose in the past.



>An obvious fix would be to send that JavaScript with a content type other than "application/javascript" or "text/javascript"... but considering some browsers execute JS sent with the wrong content type I wouldn't trust that to actually work.

I believe all browsers will try to execute. Sniffers

>I seem to remember seeing Google use "while(true);" for this exact purpose in the past.

Not this exact, but relevant. That one was JSON-leaking via redefining Array prototype.


But would this same solution work with this vulnerability? The server sets the first line of the response js to `while (true) ;` and the js handler that does the eval just deletes the first line like so:

     eval( responseJS.replace(/.*\n/, "") )


The exploit occurs when an evil third party site links to your script from a script tag - they can't modify the returned code before it is evaluated. Your own code running on the same domain (which fetches the code using XHR) can make the modification and hence execute the script.


Yes




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: