69

Resources are cached by their URL, and the protocol (http:// or https://) is part of the URL. Since the protocol differs, the URL must also differ, and you have two separate cache entries.


62

Any extension that has access to the DOM can read whatever is written to the console by intercepting calls. The console is a JavaScript object; it is simple to proxy calls to console.log, like this example from zzzzBov on Stack Overflow: (function () { var log = console.log; console.log = function () { log.call(this, 'My Console!!!'); log.apply(...


46

It is perfectly fine if a http:// and a https:// resource provide different data, even if everything but the access method is the same. For example access to http:// will today often result in a redirect response while access to https:// provide the real content. A browser will therefore cache these resources independent from each other.


38

One thing Firefox Focus uses this embedded web server for is to detect whether Safari Content Blocking rules were successfully enabled. It seems from this answer and the Focus source code that iOS 10 provides an API for determining whether a Safari Content Blocking extension is enabled, but that in iOS 9 there wasn't such an API. Instead, it was necessary to ...


36

If it was that easy, we wouldn't be using browsers. However, if your browser has a vulnerability, then things like this may happen. Keep browsers up-to-date and run script blockers, like no-script, to prevent this type of attack.


23

So if I wish to open "any" site on a new tab while doing my online shopping, is it safe The same origin policy should prevent other sites from accessing your data in the online shopping site. That is assuming that the shopping site has no vulnerabilities that leak data (CSRF, XSS, XSSI, broken CORS, broken messaging, etc.). Having only one tab ...


18

The Connection is secure badge is in respect to the information transmitted via the network / internet. As you correctly observed, the file:// protocol uses no network connection, neither a mechanism to secure the same (because there is none), hence the badge absent. Note that the browser does not label the file:// protocol as insecure. The browser simply ...


9

If your browser auto-fills passwords, then it is possible that add-ons/extensions/plugins can harvest your credentials even when you're not using it to log in. Additionally, some password managers may have keyed passwords on the URL in the <form action="…"> of a site rather than the URL hosting that page, allowing an attacker to harvest ...


8

Summary: The primary cache key for any standards-compliant browser is an absolute URI The absolute URI begins http: for all insecure requests and https: for all secure requests Consequently, a resource fetched securely can never use the same cache key as a resource fetched insecurely The current standard for HTTP is split across multiple "RFC" documents, ...


8

Not sure whether Firefox Focus actually does this, but some mobile adblockers have a built-in internal web server which answers requests by serving empty content (zero byte text files, 1x1 GIFs, etc). The adblocker redirects blocked requests to this internal server. This generally results in rendered web pages showing nothing instead of the ad, whereas ...


8

"Usually I just close the ad" Well, you think you closed the window. What you did was click on something, which permitted the download. Most everyone just looks for the little "X" to close the window. The scammers know this and manipulate what looks like a window so that you actually click a download button.


8

The only useful thing about your routine is cleaning the cookies. It's not useful in itself, it is just that, this way, you delete your login session and so a new login (which requires inputting a secret like a password) is required to interact with the shopping site. A better alternative (in terms of your user experience and security) would be logging out ...


6

First of all, good job on choosing Firefox and the right plugins, it's really the browser to go privacywise. To extend upon the points that nobody mentioned yet, an important part of you hardening your browser would be the configuration of your Firefox browser! You can do that by typing about:config into the address bar and accepting the risks. Then you ...


5

I think you may have a slight misunderstanding in the premise of your question. If the site does not use HSTS, and the user enters example.com in the address bar of their browser, the browser will default to http://example.com, not https://example.com. See the following questions on security.stackexchange.com, and elsewhere on stackexchange.com, for more ...


4

It is a form of SSRF or CSRF (depending on how it is rendered), if it is not cached, it will need to fetch the image from the URLwhen viewed. By setting the image URL to a URL the attacker control, they can possibly obtain the victim's source IP, referer URL and more from the request received to that URL.


4

I think file protocols are more secure than https protocols. You would be correct, if the file is coming from local storage. What if you are loading a file from an FTP mount (FTP protocol has no security, even passwords are sent as plain text)? Or from a remote (insecure) service over unencrypted wifi? A consumer access point with an attached drive could ...


4

A relative URL as used here will inherit the method and domain and part of the path of the base URL. The base URL is typically the URL you'll see in the browsers URL bar but it might also be changed using the base tag. Thus, if the base URL uses https then the relative URL will too. Note that the base tag might actually specify a different method than the ...


4

tl/dr: This company has no idea what they are doing. If you want to protect your data, the only option is to refuse to do business with them. Privacy and HTTP The first question is whether or not it is possible to communicate privately over HTTP. The answer is generally a solid "NO!". HTTP is a plain text protocol, which means that every server ...


4

Is this a sufficient check? No, your check is flawed. An attacker can bypass the validation via e.g.: https://attacker.example/?https://www.trusted.com/ This URL resolves to the origin attacker.example, but satisfies url.includes('https://www.trusted.com/'). If not, then how might I do it properly? E.g. use URL.origin. If url is the URL string, you ...


4

Is there any way to access the contents of a cross domain iframe Not programmatically (see below for another approach), as the same origin policy will not allow this. If it did, that would be cause for alarm, not just in your situation. An attacker could steal CSRF tokens and perform arbitrary actions, read all data the user has access to, etc. I found ...


4

Indeed the question is pretty interesting. Either way it boils down to a risk assessment plus controls in place of each system. Roughly, we could imagine 2 undesirable consequences of long-life session: Somebody can just open browser with your logged account. Controls: Close all sessions from another device via Account settings if you suspect that your ...


4

Don't blame the browser authors, as they just follow the HTTP protocol. The specification of the Referer header in RFC 7231, 5.5.2 does acknowledge the privacy concerns, but it only forbids sending the URL of a secure HTTPS page over unsecured HTTP channel: The Referer field has the potential to reveal information about the request context or browsing ...


4

When an element is clicked, the link is followed and its URL is resolved. This causes the string to be processed by the basic URL parser. In your example, the parameter is processed in the path state during which TAB (U+0009) characters, along with carriage return and line feed characters, are ignored, and therefore do not form part of the resolved URL.Why ...


3

As you correctly point out, there is no 100% guarantee that you cannot be infected by malware through a browser. I think it would be best to adhere to a multilayered strategy here. How deep you go of course depends on your security and other requirements. The first layer is to be mindful of the websites you visit. If you limit yourself to a few very well ...


3

There's no more risk installing LastPass by sideloading than there is installing/running any other executable that you download. And since LastPass is well-known and trustworthy, it's basically no risk at all. Microsoft is intentionally making it sound much more dangerous than it is in an attempt to strong-arm everyone into their store.


3

No! Service Workers also run in origin context, just as normal JavaScript. So, for a Service Worker registered for a domain cannot really interact with Service Worker registered for another domain. Furthermore, they do not have access to the DOM, unlike JavaScript. And, as long as you visit a site, it doesn’t need SW to track your activities within that ...


3

Doesn't this seem much simpler than the current system of generating, keeping track of, and reading secure CSRF tokens? No, because this measure would only protect against state changing endpoints (e.g. HTTP POST of form data), but the other flavor of CCRF is just having a user click on a maliciously formed link ( e.g. check out this facebook <a href="...


3

TL;DR "System administrators can spot a headless request with ease": NO. They can surely spot some headless requests with ease. But in general, that's not true. Quite obviously, it all depends on how the requests are done (how much effort to disguise them) and how the logs are checked and what countermeasures adopted (how much effort goes into penetrating ...


3

The answer to this is more regarding usability than it is security. It's easier for the developers to build a box that does JavaScript, with rules and restrictions in place for what it is and is not allowed to do. You feed that box JavaScript code, and out comes the result of that code (plus side effects). By implementing a feature like you suggested, you ...


3

... does "weak encryption" have anything to do with whether the browser trust the certificate? Has it got anything to do with the signature algorithm or signature hash algorithm? The weak encryption has nothing to do with the certificate: The hash algorithm used for the certificates signature is SHA-256 which is perfectly fine. The signature is also done ...


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