Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

I want to transmit sensitive information in say the index.html which should only be accessible from JavaScript during the load time of the page. Afterwards the JavaScript on the page should not be able to access that data.

I can easily remove the sensitive data from the DOM on load but I also need to prevent the page being loaded using XMLHTTPRequest or by scraping it from an IFrame.

I can block the IFrame using the X-Frame-Options header and other frame busting tricks but how can I block the page from being loaded using XHR?

The best solution I came up with is to serve the index.html with a CSP header that doesn't include self in the connect-src directive but then I can't XHR to any URL on my server and I need to white list all other possible connect targets. There must be a better way to do it.

share|improve this question
    
Can you provide minimal example of both page and script? –  Petr Abdulin Aug 8 '13 at 10:40
2  
I'm curious where the untrusted script, running on your domain, that you seem to expect is coming from. –  Marijn Aug 8 '13 at 10:44
    
Assume I want to protect an CSRF token from being "stolen" by an XSS attack. I could keep my code and the token in a closure and would be fairly safe but how do I get the token in there? –  Fabian Jakobs Aug 8 '13 at 10:49
    
@FabianJakobs One can't send AJAX requests to other domains (unless you configure CORS for the attacker in the right way), but the attacker could include your page in a <script> tag. –  ComFreek Aug 8 '13 at 18:51
    
Your entire premise is flawed. You really, really can't prevent this in any remotely secure way. The entire idea of what you're trying to do is antithetical to the nature of the Internet. –  meagar Aug 8 '13 at 19:02

3 Answers 3

Assume I want to protect an CSRF token from being "stolen" by an XSS attack.

If you have an XSS vulnerability you have completely lost. At this point the attacker essentially has access to read and control all the same information in that origin (typically everything hosted under that hostname:port combination) that the user can. The attacker has little to gain by targeting the CSRF token at this point, they already have a deeper level of compromise.

Trying to block XMLHttpRequest, framing and cookie-reading (httponly) can make an attacker's life slightly more annoying but they cannot effectively prevent access.

The Same Origin Policy is about all you have to rely on, so you should direct your efforts into avoiding that successful XSS attack.

share|improve this answer

It might be a better idea to load the sensitive data via Ajax / POST after page load and handle security with session cookie or username/password protection.

share|improve this answer

I think your best bet would be checking the X-Requested-With header for a value of XMLHttpRequest as most clientside frameworks/libraries send that header when accessing your site with XHR.

However, doing so will not block every attempt to load the page with XHR as it is not a mandatory XHR header and can be spoofed.


I don't see how setting a CSP header would help in that case as it should protect your app/site from accessing malign content instead of protecting your app/site from being accessed.

"Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources"

Source: Content Security Policy 1.1


On a sidenote: If your JavaScript removes the sensitive information from the DOM, users can still access it through the console or by checking the page source.

What's the actual use case?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.