I have a website freshly deployed on the internal network of a client. I can test it only by remote desktop on a Windows Server 2012.
The website performs SAML authentication: the browser first receives a session cookie from the website, then is redirected to the SAML identity provider, and comes back to the website with the SAML response, where it also sends back the session cookie. This works fine with Chrome, but for some reason IE11 won't send back the session cookie, which prevents the server from accepting the SAML authentication.
I have no idea why IE11 fails to send the session cookie. I have checked in the Network pane in debug tools, and I do get the cookie (though I can't confirm IE is actually storing it) :
Set-Cookie ASP.NET_SessionId=yzk4rdznlg534so2xuxqmuv4; path=/; HttpOnly
Then I am redirected to the identity provider, but when coming back to the website, it doesn't send the cookie. The cookie is HTTP only so I can't check in the console if it is stored or not. I have used the instructions posted here to see stored cookies, and I can't see a cookie for my website at any time (though redirections happen fast, so it could possibly be added and then removed before I have a chance to see it).
I also believe I have explored all possible security and privacy settings to allow everything, to no avail.
In case it's important, the site URL has no dot (it's https://mmr-pp_sef/)
Any idea how I could troubleshoot what is (or isn't) happening?
Well, turns out that it IS related to the URL used (should have checked myself sooner instead of just pointing out that the URL was weird in my question).
Apparently, IE will not store cookies if there is an underscore _ in the host name. This can be verified by modifying your "hosts" file:
Open the file C:\Windows\System32\drivers\etc\hosts (you'll need admin rights)
Add this line at the end and save the file:
127.0.0.1 test_site
Enter the URL http://test_site in your browser (this assumes your web server listens on 127.0.0.1)
Observe that IE won't store any cookie.
The only workaround I have at this time is to use another host name, that does not contain an underscore, such as test-site.
Related
[SOLVED READ COMMENTS ]
I got a problem with the asp.net core hosted Blazor app.
locally it works like charm, when it is deployed there is a problem related to the cookies, that I don't know how to fix, I did my best, now seeking help :)
The problem is: once the user comes to the login page he gets this message in the console:
Here I found those cookies in response
There is no way to fix this issue in this scenario, I have tried everything, only one thing will work that is SSL certificate.
Chrome version 80 or higher will block all third-party cookies by default. If you use the api using HTTPS, switch the protocol to the HTTPS and check whether the Set-Cookie in the response header contains SameSite=None and Secure.
If it doesn't use HTTPS, Chrome 80 will intercept the login function under the http protocol, causing the entire local deployment service to be unavailable. For this situation, open chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure in chrome, set it to be Disabled.
I am new to web development and don't fully understand how encryption on the web works. I was messing around with Chrome Dev tools on the site hltv.org. I noticed when I log in it sends a post request to /login with my password and username visible in plain text in the body of the request. Is this information visible to anyone who could intercept the post request or is only visible to me? Do I have a misunderstanding of how the information is encrypted in https requests?
The Chrome DevTools shows the local representation of code and traffic, visible to the browser. You're seeing the POST request your browser is making before it gets encrypted and sent to the server (show in plaintext for debugging and development purposes). It is the browser itself that encrypts your data (using the NSS API in Chromium and Schannel in Windows). This happens before the data leaves your machine, meaning that it will be ecrypted before it ends up on any other machine, even in the case of a man-in-the-middle attack.
No-one else can read this data, assuming:
you do not have any malicious plugins actively installed in your browser
you do not have any malware on your computer that can intercept Trusted Root Certificates
I have a rails application and I am using devise for authentication.
When I get logged in successfully on URL http://localhost:5000/,
I try to access http://127.0.0.1:5000/ in the same browser.
I expect to be logged in as soon as I access it on http://127.0.0.1:5000/ but application remains logged out. Whats going on I really cannot understand as I am trying to access both URLs in the same browser?
UPDATE:
my config/initializers/session_store.rb
Rails.application.config.session_store :cache_store, key: '_app'
The fact that you are logged in is store in the session which is stored in a cookie. For security reasons, the browser sends cookies only to the URLs from which the cookie was set.
From the browser's point of view, localhost and 127.0.0.1 are totally different URLs. Therefore the login information stored in the cookie on localhost is not sent to the server running at 127.0.0.1 and therefore the server running at 127.0.0.1 has no information about an existing session on localhost.
UPDATE:
Using the cache_store to store the session doesn't change anything because the information what session in the cache store belongs to the user is still stored in the cookie.
Imaging that your server needs to store all generated sessions somewhere. And if a user comes backs the server needs to know which session belongs to the user. A simplified solution to this problem might be to assign a random number to each session and give the user this number (stored in the cookie). When the user returns the cookie is returned too and that allows the server to load the session by that number.
And a cookie is bound to a domain. This is a security feature of the browser. If it didn't work that way all sessions would be sent to all domains: Google would know if you were logged in to Facebook, every website would know that you have a cookie from your bank...
I'm pretty newbie in https and my project is MVC web application and i've created a self-signed certificate in IIS and set the website's binding to use that certificate and ssl settings to 'require SSL' and I can browse the website over https (although it's not verified and has red x on it).
The part that I don't understand is when I send a request to server (post request), I can still check the network console and see what was the parameter passed.
I can still check the network console
I assume that you mean the information about the send and received data within the browser with "network console". Since the browser is creating and encrypting the data the browser has access to the clear text before encryption and after decryption and thus can show these information.
I'm trying to set the session cookie secure flag to true. I added the following to my environments/production.rb
ActionController::Base.session_options[:secure] = true
In the production mode I don't see the set-cookie header in the server response (I'm using the Tamper Data Firefox tool to view the traffic). I tried removing all cookies, manually setting the domain including the child domain(since domain is shared among many applications, the appache server forwards the requests to the right application and thus the request is always received by the application server as if it's coming from localhost).
I also tried to test it in development mode, I assume the server should at least set the cookie even if the request is over http but the browser won't send the cookie over http but again the server does not send the set-cookie header. The session works just fine if I don't set the secure flag. Am I missing something here?
I found out that in my version of actionpack, session cookies are only set over ssl.
Although by definition, the server can set a secure cookie when the request is over http but the browser will not send it with further requests. In my application I don't enforce ssl on the app level but on the appache level instead so the initial request made by rails is over http and the cookie is not set.