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?
Related
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 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
I've run into a problem where login on my site is not working consistently in IE8. It works fine in Firefox/Chrome/Safari but not IE8.
On first login everything is fine. After logging out and trying to log back in it usually fails for a while. It will end up redirecting to the login page against after authentication.
So the authentication is successful, it returns true, but it seems IE8 is not accepting the new value for the session id which we set by returning:
Set-Cookie SESSIONID=........; Path=/
in the response header. But obviously this works with a clear cache and I can get in fine. But after its already there it fails to reset, so after authenticating and attempting to go to a new page it sees this is an old session id being sent from the browser and redirects to the login page.
I haven't found anything here or elsewhere that really solves this (besides clearing the cache). Most references to IE8 cookie problems are language/framework specific and don't answer this problem.
Is there something special I might need to do with the set-cookie to make this work?
UPDATE:
I've set IE8 to prompt before accepting any cookie. When the login works fine it prompts as expected. When it does not work there isn't even a prompt to except the cookie..
UPDATE 2:
I should have mentioned that the cookie is expected to be set after an ajax call:
$.get(authenticate_url, ....)
The url it requests a response from returns the header that sets the session id, then in the callback function the user is redirected to the main page -- assuming login is successful.
Is it a first party cookie or a 3rd party cookie. If the latter, ensure you're sending a P3P header.
Are you setting the HTTPOnly attribute?
Are you sure that the domain for the cookie is always the same? E.g. if you set the cookie when visiting "example.com" and tried to change it from "www.example.com" then you'll encounter problems.
I've hit similar symptoms when I have cookies set for both www.example.com and example.com. If there's no domain explicitly set, then session cookies get set for both.
However, higher-level domain cookies take precedence over the lower domian. So, if www.example.com tries to set a cookie, but example.com already has, then the example.com cookie stays in place and continues to apply for www.example.com.
There are two ways to approach this problem. One is not to allow access both with and without the www subdomain. Redirect one to the other. The second is to explicitly set the cookie domain, so that there aren't two versions lying around.
Of course, that might not actually be your issue. Experiment and find out :)
This may or may not be a programming question, but one or two users of my website have got some strange strings being inserted into their address bar.
The address should be:
http://URL/Couple of Folders/page.aspx
but occassionally the same thing becomes:
http://URL/(X(1)F(qHfgTf50ahMY47b-lnz3ovk89OA4AbMN4S-sYVZCgCULL))/Folders/Page.aspx
The string is also in the action field as so:
<form name="aspnetForm" method="post" action="/**(X(1)F(qHfgTf50ahMY47b-lnz3ovk89OA4AbMN4S-sYVZCgCULL))**/<Page>.aspx" onsubmit="javascript:return WebForm_OnSubmit();" id="aspnetForm">
I'm no server/IIS expert, so please excuse me if this is a dumb question, but what is the strange string and do I/my clients need to worry?
Looks like you have cookieless sessions set to auto in your web config.
If a user allows cookies, their sessionID is stored in an in memory cookie. If they don't, ASP.Net pushed the sessionID into the URL, and this is used to identify which user is making the request. The strange string of characters you are seeing are sessionIDs for those people who have cookies switched off.
There's not really anything to worry about here, although it does make session hijacking a little easier... Probably wouldn't stress about this though.
Hope it helps...
Please check your sessionstate node settings in web.config. The cookieless attribute in sessionstate node must be set to false as shown in the following settings.
<sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="number of minutes"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"/>
Paul is correct about the sessionID being pushed into your URL's for cookieless users. This is not a problem for human users but poses a potentially significant challenge to bots (most significantly Googlebot's spider) who are crawling your site to index and rank your site in search engines.
Bots will be identified as cookieless by your ASP.NET framework which causes a couple of 302 redirects from the ://URL/autocookiesupportdetect then to the URL/(sessionID)/folders... This 302 redirect is bad enough but, to make matters worse, Googlebot receives a sessionID each time it crawls your site and views each URL with the sessionID as a duplicate page to index. This hurts the pagerank for each page Google crawls with the session ID in the URL.
The fix is add a definition file to your site to identify bots as accepting cookies thus serving them a cookie (vs. a cookieless) session. You then will not have to require that your human visitors have cookies enabled and your bot vistors will be happy to see your pages without the sessionID in your URL's.
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.