Tag Info

Hot answers tagged

12

The basic approach is sound IMO, but there are a few details to take care of: You should support several hashes on a single tag. The browser doesn't need to validate all of them, validating one collision resistant hash is enough. Being able to specify the size seems useful to avoid some kind of DoS where your site is fed a huge resource Unless you're using ...


11

Certain elements of the page are not sent via HTTPS. This means that those elements can be read by anyone sniffing the network, or modified in-transit by an active attacker. This might result in an attacker executing JavaScript on the page. As such, your browser is warning you that the page is, for most intents and purposes, the equivalent of not being ...


9

I would assume your reasoning is something like, "If the person constructing the page chose to send some of its images insecurely, then the browser should respect that this decision was done for a reason and allow it without a warning. The page is as secure as the entity providing it wanted it to be." By contrast, the reasoning of the browser developers is ...


7

The browser doesn't know what type of information an image or other resource is supposed to convey: perhaps it's just a logo, or perhaps it's some piece of UI, or perhaps the image is the whole point of the page you're visiting. There's no way for the browser to know whether a resource is important or not to the user. When the primary (page) URL is loaded ...


4

Short answer: lack of semantic information Long answer In a forum, the user naturally expects stuff to come from "unauthorised" third parties (any registered user, could be anyone really), not only from the webmaster (and authorised authors). The user fully understands that messages do not represent the webmaster opinion, and are not "authorised" in any ...


4

Maybe it's best to explain the problem with mixed content. A lot of websites will store the login state into the session, and if an attacker has the session-id, he can impersonate the logged in user. The session-id must be sent along with each request, so the server can recognize the user, this will usually be done with a cookie containing the session-id. ...


4

Yes, it does add to security and yes it should be done but security is often neglected over usability. For example the Chrome notification is barely even present as opposed to the firefox popup. More importantly, to actually prevent such a threat the browser must not only notify the average user (who would have no idea what's doing on) but also give the ...


3

If you take a look at the page source (e.g. through Chrome's fine 'inspect element' tool), you can see that the style sheet for the page specifies certain image elements. EDIT: bobince is correct, my apologies. The problem is indeed that some of the images are served through http: ...


2

Actually, tylerl, the browser does know what type of information a resource is intended to convey. The obvious risk is that information is exposed in the request (once javascript is injected into the page, it's trivial to inject data into the URL without changing the functionality, e.g. img.src=img.src+'?session=1234'; ) and it can therefore be used for ...


2

To add to the good points from @CodesInChaos: there was a much older mechanism to support signed Javascript. This comes from the days of Netscape 4 and it is still documented, but it is unclear whether this is still supported in Firefox. Internet Explorer never supported it, although the people at Microsoft toyed with the idea. The system piggybacked on the ...


1

Since you have no control over how the browser checks for mixed content you have to have all content load over SSL, otherwise you will get mixed content warnings. You don't have to give up your private keys to a CDN if they already provide an HTTPS endpoint. The only difference is that you don't get your own custom domain. That, I think, is a pretty ...



Only top voted, non community-wiki answers of a minimum length are eligible