Under the assumption that the user uses an up to date standard browser (eg. FF, Chrome, Edge, Safari, Opera), doesn't have any extensions in his browser, not effected by viruses, etc.: can you by javascript modify standard Request Headers; eg. Referer, Host etc.?
(I'm hoping that the answer will be no :-) )
Related
When hosting a website using HTTP Authentication, if the client has not authenticated, the server will send a 401 Unauthorized response, including a WWW-Authenticate header. An optional directive in this header is realm:
A string describing a protected area. A realm allows a server to partition up the areas it protects (if supported by a scheme that allows such partitioning), and informs users about which paricular username/password are required.
(emphasis mine)
Let's say www.example.com requires authorization and has configured a realm value of Test Area. Back in the day, most web browsers would display a login dialog when receiving such a response, and say something along the lines of "Authorization required. The site at www.example.com says 'Test Area'."
But (at least recent versions of) Chrome, Firefox, and Edge, now all just display a generic message, without including the realm value. Interestingly enough, IE still displays the realm value (screenshots below, all Windows 10 64bit):
Chrome (v93.0.4577.82)
Firefox (v92.0)
Edge (v93.0.961.52)
IE (v11.1411.18362.0)
I'm pretty sure Firefox and Edge used to display it. Chrome may have a while back but seems like it was the first to stop. Since all modern browsers aren't displaying it, I assume there's some reason why..?? I've search all over the internet, and can't figure it out. I have a use-case where it would be helpful to users to have the realm displayed, as it would make it clearer which particular credentials they need to use. I know that you can't force the browser to display it, but it's just annoying. However if there is a valid reason for it not being shown I'll accept that.
The reason is that this could be abused for phishing attacks, by putting some misleading message into the realm. The login dialog for http authentication is part of the trusted browser UI, and giving the server the opportunity to modify that UI - even by just displaying text - is a security risk.
We've came across a strange user-agent string in our server logs. A browser (pretending to be an iOS Safari 9.0) had WalletPasses/1.2.3 at the end of the user-agent HTTP header.
What's that device or software?
A quick Google search reveals https://walletpasses.io. From there:
Wallet Passes allows you to use your Apple® Wallet / Passbook® Passes on Android™
So I'm guessing that they're spoofing the iOS Safari user-agent to make websites offer Apple Wallet to them.
I'm exploring the idea of HTTP Origin checks as CSRF protection for Drupal at https://www.drupal.org/node/1803712
Now I was testing how the Origin header arrives with a POST request, but Firefox does not send the Origin header on the user login form submission. Chromium and Chrome work fine, they send the Origin header.
Firefox version is 36.0.1. I also tested with a clean Firefox installation because I thought maybe some of my browser plugins suppress the Origin header, but no luck - no Origin header there either.
Is there a documentation page that describes when Firefox sends the Origin header and when not?
Is isn't implemented yet. There's a discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=446344
The default on Firefox is not to send HTTP_ORIGIN.
The reason is a bug that causes hangs on some mobile Firefox versions if the network.http.sendOriginHeader configuration variable (accessible via about:config) is enabled. (For details see https://developer.mozilla.org/en-US/Firefox/Experimental_features#Security and the link provided by Marco's comment https://bugzilla.mozilla.org/show_bug.cgi?id=446344.)
There is a proposal to enable FF sending HTTP_ORIGIN by default, but the TODO list is long (see https://bugzilla.mozilla.org/show_bug.cgi?id=1424076).
So it will probably take years until FF will generally send HTTP_ORIGIN even without Javascript code enabling CSRF.
Some FOSS OSes preconfigure their FF ports to send HTTP_ORIGIN by default.
BTW, MS Edge also does not send HTTP_ORIGIN without explicitly enabling CSRF using Javascript.
For this reason I have implemented a security setting of my site which enables the users to disallow POST transactions from browsers that do not provide HTTP_ORIGIN.
Ok, so I get the rule that browsers should not confuse history store and web cache: Clicking back should not send a request to the server. I also get that browsers manufacturers have the poetic licence to break this rule.
What I don't get is the following (please stay with me here)...
OK: Browsing our web site in HTTP, the history buttons did not send requests to server. Great! Behaviour as expected.
NOK: Browsing history on the same site in HTTPS mode, Chrome faired well but IE9/10 and FF did not. They would send the request for the HTML page to the server and then correctly use the store for the static files. Why the difference?
So after a little head scratching and testing, I found that the presence of the Pragma:no-cache header in the responses we were sending was responsible for this behaviour. After removing the header, that should never have been there in the first place, IE and FF faired well when using history buttons in HTTPS - no more sent requests.
Now, how can the presence of a header which should be ignored by modern browsers and only used in requests, be causing this strange issue in browser history navigation?
I am trying to improve the performance of my website by adding cache headers for static content.
So far, I can get the content to cache in Chrome and Internet Explorer, but not Firefox.
Here are the caching-related headers I'm supplying:
Cache-Control:private, max-age=1800
ETag:"809067e0179acb1:0"
Expires:Mon, 20 Dec 2010 21:35:10 GMT
(NOTE: ETag and Expires are variable; Expires is 30 minutes in the future)
I verified the behavior using Fiddler 2. Chrome and IE7 do not request the images, CSS, and JS after the first request, while Firefox requests them every time.
Is there any header I should supply to make Firefox cache these?
UPDATE 2010.12.22
I noticed the same behavior on most websites, including www.yahoo.com. Is there a way to force Firefox to cache?
This would have occurred for SSL content, but it should no longer be the case. FireFox altered the way it caches with the resolution to Gecko bug 531801.
Now, SSL content is cached to disk regardless of the Cache-Control header.