I set the HSTS header on my site and i want to test that the different browsers (chrome, Firefox, IE, Opera) do enforce the header.
I set a trusted certificate, connect to the site and I can see the the header at the HTTP response. but i want to validate that the browser do enforce the protocol.
In Chrome it's easy and it works:
- I can query the site at chrome://net-internals/#hsts
- When trying to connect with HTTP i get 0kb response with status 307.
- If i change back self-signed cert i can't connect the site and there is no proceed option.
The other browsers behave differently, i can't query the HSTS list, the response status and size is different and when changing to self-signed cert (after first trusted connection) i do have proceed option.
So how can i validate that the protocol is enforced on each browser?
Although Chrome's ability to query the HSTS cache and see the fake 307 redirect is handy, you can just check whether HSTS is enforce.
HSTS offers you two options:
Automatically load HTTP resources over HTTPS
Prevent click through of cert errors.
You are concentrating on the second option, but why not use the first option as the test? Just load the site up with the HTTP and check whether it is redirected (i.e. loads HTTP URL and so is not using a HSTS rule) or if it just loads HTTPS URL immediately (i.e. is using HSTS).
So in Firefox for example open network tools click on "Persist logs" option (and let's do "Disable Cache" to avoid any confusion). Then go to a site which has an HSTS header over HTTP (e.g. http://stackoverflow.com) and you'll see a 301 redirect if this is your first visit:
Next time you go to it (after it has cached the HSTS header) it should go directly to the HTTPS URL even though you typed the HTTP URL in address bat:
If you've already been on stackoverflow.com then you can clear the HSTS cache to try this again.
Once you've confirmed that HSTS is being used or not, you can then investigate the click-through issue. Browsers should not allow click through when HSTS is in place, including for self-signed certs, but maybe there's a bug, or it's still cached your old cert in some places, or the HSTS policy has expired or something else...
Related
I'm seeing rather confusing behaviour in Chrome. Cookies that I set via a cross-origin AJAX request don't show up in the browser's dev tools inspector. I'm sure they're being set but there's no way of viewing them locally.
I want to use Chrome devtools to view cookies that have been set by my API
My front end is a SPA and hosted on a different server to my (Rails) API. When testing locally, they're merely different ports: one is on locahost:3000 and the other is on localhost:4200. So that I can use cookies with API requests, I've set my serverside CORS policy to allow for withcredentials. On the client, I have set my (Angular) cross-origin requests to have the header withCredentials=true.
I've verified that the server is actually sending the cookie to the browser
When I make a request to the server, the server sets the cookie and I can see it in the response headers:
...but it doesn't shows up in Chrome devtools (or Safari)
I know it's set successfully becuase it shows up in subsequent requests
I would have assumed that the cookie had simply failed to be set but when I inspect the next request to the API I can see the cookie both in the request payload in Chrome:
And it also shows up on the (Rails) server in the request.cookies
pry> request.cookies
=> {
"my_cookie"=>"its value"}
Why can't I inspect this cookie in Chrome?
And is there a way to get around it - either in Chrome or in a different inspector? I just want a way to view and verify these cookies.
Cookies are set on the browser by the client application, from your screenshots, you are inspecting the server on port 4200 instead of your client application running on port 3000
This should show up as a seperate "Cookies" tab when you inspect the XHR request. It's easy to miss because the tab only shows when withCredentials is set to true.
Visit a random site, for example example.com
Open dev tools, application -> cookies
Make sure that it's empty
Open console tab, make a fetch request to a random website, for example fetch('https://api.chucknorris.io/jokes/random')
Open application -> cookies again and notice cookies from the domain from step 4.
Many times a day I clear a website's cookies for debugging purposes. But in Chrome clearing one website's cookies affects clearing other sites' cookies as well and it clears my sessions on other websites, which is not what I want.
Is it a bug or a feature in Chrome? I think that it's a bug and cookies from other domain shouldn't be shown, but maybe I miss something.
P.S. Firefox don't show cookies from other domains.
What I have observed is that the list of URLs under the 'Cookies' entry is the page that made a request to the origin server for the cookies shown. If you look in the network traffic you can see the the URLs in the 'Cookies' list are the referer of the requests to the origin servers, whose response sets the cookie. This is a common method for tracking cookies to be set. A.com in the 'Cookies' URL list will have some page with lots of IMG or Script or iframe elements that make requests to the domains in the list of cookies and the responses from those domains set the cookies. What I found confusing is that the Chrome documentation (https://developers.google.com/web/tools/chrome-devtools/storage/cookies) refers to the list of URLs under the 'Cookies' entry as 'Origins'. They are not the cookies origin as defined in RFC 6265, they are the referer page that made the requests to the cookie origin servers.
I store urls in a database for the users of my webapp and I am not sure whether I need to store whether it was a "http" or a "https" request.
If I don't store the type of the connection and just echo to the users a link with "http", will it in 100% of the cases use a "https" connection automatically (when it is possible)? I don't want to be responsible for a user not using a https connection even though it is possible.
Does the browser (Chrome/Firefox) automatically use https even when you try to use http?
No. If you tell the browser to use HTTP, then it will use HTTP.
Schemes will only be added to a URL automatically under two circumstances:
When it is a relative URL, in which case the scheme will be the same as the one used to load the current document.
When the user types the URL into the browser's address bar and omits the scheme, in which case it will default to HTTP (not HTTPS).
A web server might provide HTTP and HTTPS versions of the same URL with the HTTP version containing a redirect to the HTTPS version and the HTTPS version hosting the content.
A web server might, for that matter, not provide an HTTP version at all… but that is very uncommon.
I am not sure whether I need to store whether it was a "http" or a "https" request.
You should store the full URL. You shouldn't omit bits and hope that you can fill them in by guesswork.
It won't automatically do that, but there are ways to help out:
some users may have the "HTTPSeverywhere" extension, which will attempt to redirect to HTTPS
you can serve HSTS headers, which will make the browser automatically stick to HTTPS if the user has at least once been on HTTPS with your site
Now there are a few problems with these points:
not everyone use the extension
HSTS only works once the user was visiting the URL with HTTPS and it will only work on site with HSTS headers set up, so if links are external, this might not be the case.
That being said: Are the links you store links to your own domain or external links to any web site?
I was doing some research on how Firefox and Chrome are implementing HSTS (HTTP Strict Transport Security) in detail.
Turns out that they have a predefined list with some sites that already implement HSTS. This can be seen here here and/or here.
And these list seems to be somehow linked to the sourcecode itself which makes somehow sense...but how do Firefox and Chrome handle my own HSTS headers? How and where do they store my URL, my max-age and whether I includeSubDomains or not?
I wasn't able to find this in about:config or likewise....
So maybe somebody knows more about this issue than me, I'm just curious (:
Thx!
See http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/netwerk/protocol/http/nsHttpChannel.cpp#l1072 and then http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l249 which calls http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l147
So the data ends up stored in the permission manager, which is the normal place per-host information gets stored in Firefox. The permission manager stores its state in permissions.sqlite, I think.
Sites that want HTTP Strict Transport Security (HSTS) enforced send a header in response - Strict-Transport-Security: max-age=31536000
max age being time for it to expire. It is sent on each request so that it gets updated to that much more time every time it is requested.
Browser (I have tried only Firefox) stores this data with it and will use it every time the site is accessed. This is true even for incognito mode. If you have ever accessed the site before in non incognito mode then the details of that site is saved and used even if you try to open it now in incognito mode.
For firefox this data is stored in a file called SiteSecurityServiceState.txt which is in your firefox profile folder. You can enter about:support in browser and then select "Show in folder" to open your profile folder where you can locate this file.
I am not sure about predefined sites but above is the file where normal site HSTS details are updated for firefox.
More details - Understanding HTTP Strict Transport Security (HSTS)
PS: Above link goes to my personal blog that has more details on HSTS.
Does the checkmark at the Http column of Chrome devtool's Cookie resource panel indicate a HttpOnly cookie?
I can't find docs that confirm this, though I suspect it is the case. I am trying to verify my app is using HttpOnly for session cookies.
Yes. Enter document.cookie in the console, and you'll see that none of the checked cookies are visible.
HTTP = HttpOnly flag, Secure = secure flag.
Yes. Right click on your page or press F12 button. This will open developers tools window. Go to application tab. It'll show as follow :-
Now, typing document.cookie on the tab, you'll see only csrf token being shown.
To specify session cookies to be httpCookie by default, set 'useHttpOnly' attribute in context.xml in tomcat, for java web application. For more information, refer to http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes
So 2 things .
1) HTTP only cookie this name is a bit misleading as we can send HTTPOnly cookie over HTTPS and it works perfectly fine. Main characteristics of HTTP Only cookie is it can't be accessed using JavaScript . In-fact You can't even manually edit this in Chrome's Application tab.
2) So how you can edit HTTP Only cookie ? In chrome You can use extension to edit cookie while development . In production mode there is no way you can adultrate this without man in the middle attack on HTTP connection.
Today (May 2016), googling around for the same reason, I found this question and this page from developers.google.com explaining:
HTTP: If present, indicates that cookies should be used only over HTTP, and JavaScript modification is not allowed.