I am trying to secure the cookies returned from my ASP.NET application.
I set requireSSL="true" my web.config but it looks like the cookies are only secure sometimes. I will check the request in Firebug or Chrome dev tools and the cookie will be secure sometimes (it look like it is usually the first time I visit the page but subsequent visits they are not secure).
Screen shot of Chrome dev tools: http://i.imgur.com/jII0KDI.png
Does anyone have an idea why this might be happening?
Thanks for the help!
Web.Config Settings
<system.web>
<httpCookies httpOnlyCookies="true" requireSSL="true" />
</system.web>
It could well be working.
Chrome dev tools only show cookies marked as HTTP Only and Secure in the Response and not the Request, so your setup might be working. It seems like it could be a bug in Chrome dev tools or that it is only showing what is provided in the request (the fact that they are secure or HTTP only is not indicated in an actual HTTP request, only the value is sent to the server). Either way I think it should show N/A in these columns to show that they do not apply to HTTP requests.
To verify that your cookie has been set correctly you could try the Edit This Cookie extension. This will indicate for each cookie whether it has the Secure or HTTP Only attributes applied.
can you please elaborate what you mean by secure ? if sslonly flag is set then offcourse all cookies will be sent over encrypted connection only. but that doesn't prevent you from seeing in debugger
Related
I have an ASP.NET webforms/mvc hybrid app deployed on IIS 10. I have two bindings for this app one with just a localhost:portNo binding and another with DNSDomainName:portNo binding. Both are Http bindings. SSL is turned off. I get the error
"This attempt to set a cookie via a Set-Cookie was blocked because it had the "Secure" attribute but was not received over a secure connection."
when I test the DNSDomainName:portNo binding (it is failing to set sessions). The localhost:portNo binding works without any issues. Why is this happening? and how do I fix this?
Your cookies are configured to require an HTTPS connection. When you try to set them on a non-secure connection, they will be rejected.
Check your web.config file settings for:
<httpCookies requireSSL="true" />
Change that setting to false, and your session cookies should start working.
NB: Once you publish your site, it should only ever be served over HTTPS, and this setting should be changed back to true.
Secure Cookie Attribute | OWASP Foundation
The localhost binding works because most browsers have special-case code to treat connections to that host name as "secure", even if they don't use HTTPS.
Locally-delivered resources such as those with http://127.0.0.1 URLs,
http://localhost and http://*.localhost URLs (e.g.
http://dev.whatever.localhost/), and file:// URLs are also considered
to have been delivered securely.
Secure contexts - Web security | MDN
I've been using Postman in my app development for some time and never had any issues. I typically use it with Google Chrome while I debug my ASP.NET API code.
About a month or so ago, I started having problems where Postman doesn't seem to send the cookie my site issued.
Through Fiddler, I inspect the call I'm making to my API and see that Postman is NOT sending the cookie issued by my API app. It's sending other cookies but not the one it is supposed to send -- see below:
Under "Cookies", I do see the cookie I issue i.e. .AspNetCore.mysite_cookie -- see below:
Any idea why this might be happening?
P.S. I think this issue started after I made some changes to my code to name my cookie. My API app uses social authentication and I decided to name both cookies i.e. the one I receive from Facebook/Google/LinkedIn once the user is authenticated and the one I issue to authenticated users. I call the cookie I get from social sites social_auth_cookie and the one I issue is named mysite_cookie. I think this has something to do with this issue I'm having.
The cookie in question cannot legally be sent over an HTTP connection because its secure attribute is set.
For some reason, mysite_cookie has its secure attribute set differently from social_auth_cookie, either because you are setting it in code...
var cookie = new HttpCookie("mysite_cookie", cookieValue);
cookie.Secure = true;
...or because the service is configured to automatically set it, e.g. with something like this in web.config:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
The flag could also potentially set by a network device (e.g. an SSL offloading appliance) in a production environment. But that's not very likely in your dev environment.
I suggest you try to same code base but over an https connection. If you are working on code that affects authentication mechanisms, you really really ought to set up your development environment with SSL anyway, or else you are going to miss a lot of bugs, and you won't be able to perform any meaningful pen testing or app scanning for potential threats.
You don't need to worry about cookies if you have them on your browser.
You can use your browser cookies by installing Postman Interceptor extension (left side of "In Sync" button).
I have been running into this issue recently with ASP.NET core 2.0. ASP.NET Core 1.1 however seems to be working just fine and the cookies are getting set in Postman
From what you have describe it seems like Postman is not picking up the cookie you want, because it doesn't recognize the name of the cookie or it is still pointing to use the old cookie.
Things you can try:
Undo all the name change and see if it works( just to get to the root of issue)
Rename one cookie and see if it still works, then proceed with other.
I hope by debugging in this way it will take you to the root cause of the issue.
I have a web site. URLs com/default.aspx form should appear. But when I click on the URL (com/(S (the hito5tqogutqn21tcn2mozjrr))/default.aspx) as it seems. How do I fix it. URLs with a random number itself is changing.
Check this: https://msdn.microsoft.com/en-us/library/aa479314.aspx
This is happening probably because (unless, you have specified explicitly to use the uri for session id management, which I think, is not the case) the browser does not allow cookies (either for your web site or for all) and Asp.Net detects this and appends the session id to the uri because otherwise your site would not be able to support sessions.
In fact, this is the most secure approach, allowing session state to be available even if the user had disabled cookies.
You can change this behaviour by specifying the following in your web.config file:
<system.web>
<sessionState cookieless="UseCookies" />
</system.web>
After that, you will not see the session Id in the Uri, but users whose browsers do not accept cookies from your web site will not be able to have a session state.
At this point, defining a privacy policy for your web site might help your cookies to be accepted by the browsers:
https://msdn.microsoft.com/en-us/library/ms178194.aspx
In my ASP.NET Web application, i have made the below changes to make the ASP.NET_SessionID and .ASPXAUTH Cookies Secure by adding the below entries to web.config
<httpCookies httpOnlyCookies="true" requireSSL="true" />
and adding the below tag
<forms requireSSL ="true" />
But my issue here is that, the Cookies received from Server(Network->Cookies->Direction Column has a value of received) has Secure and HttpOonly flag set to true. Found the information when i debug using IE 11 Developer tools, but the cookies data sent to Server(Network->Cookies->Direction Column has a value of Sent) does not have any Secure or HttpOnly flag set to true.
Is this the default behaviour? If so, why the data sent to server is not having the Secure and HttpOnly flag set? How to set it other than the above changes made to the config file.
Cookie flags, like Secure and HttpOnly, are only sent from the server to the client. You won't ever see them in traffic going the other way. If you want to make sure that a cookie is Secure, have the browser make a request over HTTP (instead of HTTPS) and see if the cookie is still present (it shouldn't be). If you want to make sure a cookie is HttpOnly, open your site in the browser and then check the value of document.cookie using the JS console in the dev tools; you should see any non-httponly cookies you have but no httponly cookies.
Cookies are an inherently client-side thing. They are a way for a server to tell the client "every time you make a request to me, include this bit of info". The Secure flag modifies that to say "Every time you make a request to me over a secure connection, include this bit of info (but don't ever divulge it over insecure connections)". A conforming user agent - that is to say, a web browser - is supposed to obey those directives. However, there are no equivalent directives the other way; servers don't have to do anything at all with cookies the client sends them, and there is no "client sets a cookie on the server" equivalent of the way servers can set cookies on the client. Directives (including Secure, HttpOnly, Domain, Expires, etc.) are only used when setting a cookie.
Afternoon Folks,
I was wondering if anyone could give me a heads up with regards to this problem that I'm having. I'm not positive on what I should be seeing I suppose is the main issue that I'm having.
I have changed the web.config to use the following:
<httpCookies requireSSL="true" />
All works fine for the general cookies defined when I make a request over http (as opposed to https) in that they don't appear, however the asp.net_sessionid cookie ( ASP.NET_SessionId=epg3ebjv1hheqe45kgp0j055) still appears. Is this correct behaviour, should it not be missing?
UPDATE:
While doing a bit more trawling through the internet I discovered that this is only applicable to forms cookies. It doesn't apply to session cookies. Sickner! However, the following link suggested a fix for it: How to secure the ASP.NET_SessionId cookie?
Which did not sort out my issue unfortunately, the cookie still appears in the request.
The cookie will always appear. If it's secure the content will be encrypted (and it will be transmitted in an encrypted fashion if you're using SSL.
That session ID has to be sent somehow. If you'd rather not have it stored as a cookie, you may want to look into cookie-less sessions. In that case, the session will be part of the URL construct.
Maybe try setting a custom cookie name and using the workaround you found?