|
|
You're in the
dotnet security
group:ASP.NET Cookie Handling
dotnet security:
can't quite get ironed out. I have two applications. One is Framework 1.1, W2K3 / IIS6, the other is 2.0, W2K3 / IIS6. For both, HTTPS / SSL is enabled, but not forced, because we use redirection to direct users that request HTTP to HTTPS for the sake of usability. The questions are: For persistent cookies, will the client and server use both HTTP and HTTPS for each cookie operation? Everything that I have read points to "yes", unless the cookie employes the "secure" option, in which case only HTTPS will be used. The question is the same for session cookies. Since the cookie is sent as a header, I would think it would be only HTTPS, but I would have thought the same thing about persistent cookies. Are cookie headers sent only via HTTPS in this scenario or will they use HTTP as well? Also, I noticed that both Frameworks seem vulnerable to the issue where browsing to non-HTTPS pages causes the same session ID to be used for HTTP and HTTPS. This isn't fixed in 2.0 / IIS 6? Thanks so much for any help! I've read the rfc docs, cookie specs, and articles on MSDN, but can't quite find a definitive answer. And unfortunetly, it's impossible to tell on the client side. I've used Fiddler to view mixed content pages, but unfortunetly, client-side every object appears as SSL,
Ok, so in my mind I'm tying the word session to an HTTPS session, but really
it's any ASP session, whether encrypted or not. The session is tracked regardless. Is there a secure option for session cookies. If there is, will that force SSL only as with persistent cookies? Sorry, I come from a PHP background and am not that familliar with ASP.NET yet. [quoted text, click to view] "Dominick Baier" wrote:
> Hi, > > the session feature is not designed for such security features - there is > no requireSSL setting e.g. - so session cookies will always be sent - regardless > of SSL. > > You could append the secure attribute manually though. > > --- > Dominick Baier, DevelopMentor > http://www.leastprivilege.com > > > I have some questions about persistent and session cookie handling > > that I can't quite get ironed out. > > > > I have two applications. One is Framework 1.1, W2K3 / IIS6, the other > > is 2.0, W2K3 / IIS6. For both, HTTPS / SSL is enabled, but not forced, > > because we use redirection to direct users that request HTTP to HTTPS > > for the sake of usability. The questions are: > > > > For persistent cookies, will the client and server use both HTTP and > > HTTPS for each cookie operation? Everything that I have read points to > > "yes", unless the cookie employes the "secure" option, in which case > > only HTTPS will be used. > > > > The question is the same for session cookies. Since the cookie is sent > > as a header, I would think it would be only HTTPS, but I would have > > thought the same thing about persistent cookies. Are cookie headers > > sent only via HTTPS in this scenario or will they use HTTP as well? > > > > Also, I noticed that both Frameworks seem vulnerable to the issue > > where browsing to non-HTTPS pages causes the same session ID to be > > used for HTTP and HTTPS. This isn't fixed in 2.0 / IIS 6? > > > > Thanks so much for any help! I've read the rfc docs, cookie specs, and > > articles on MSDN, but can't quite find a definitive answer. And > > unfortunetly, it's impossible to tell on the client side. I've used > > Fiddler to view mixed content pages, but unfortunetly, client-side > > every object appears as SSL, regardless of how it was delivered. > > > >
Hi,
the session feature is not designed for such security features - there is no requireSSL setting e.g. - so session cookies will always be sent - regardless of SSL. You could append the secure attribute manually though. --- Dominick Baier, DevelopMentor http://www.leastprivilege.com [quoted text, click to view] > I have some questions about persistent and session cookie handling > that I can't quite get ironed out. > > I have two applications. One is Framework 1.1, W2K3 / IIS6, the other > is 2.0, W2K3 / IIS6. For both, HTTPS / SSL is enabled, but not forced, > because we use redirection to direct users that request HTTP to HTTPS > for the sake of usability. The questions are: > > For persistent cookies, will the client and server use both HTTP and > HTTPS for each cookie operation? Everything that I have read points to > "yes", unless the cookie employes the "secure" option, in which case > only HTTPS will be used. > > The question is the same for session cookies. Since the cookie is sent > as a header, I would think it would be only HTTPS, but I would have > thought the same thing about persistent cookies. Are cookie headers > sent only via HTTPS in this scenario or will they use HTTP as well? > > Also, I noticed that both Frameworks seem vulnerable to the issue > where browsing to non-HTTPS pages causes the same session ID to be > used for HTTP and HTTPS. This isn't fixed in 2.0 / IIS 6? > > Thanks so much for any help! I've read the rfc docs, cookie specs, and > articles on MSDN, but can't quite find a definitive answer. And > unfortunetly, it's impossible to tell on the client side. I've used > Fiddler to view mixed content pages, but unfortunetly, client-side > every object appears as SSL, regardless of how it was delivered. >
You can set the secure (or http only flag for that matter) on both session
and persistent cookies. If you set the secure option, the browser will only send the cookie on an HTTPS channel, regardless of cookie type. Persistent vs. session for cookies just determines whether the browser will save the cookie to the file system and whether it can be used by multiple browser processes or not. Joe K. -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- [quoted text, click to view] "Aaron Sanders" <AaronSanders@discussions.microsoft.com> wrote in message news:2EFD0358-26CB-48B5-9E8F-EF1AF1340B00@microsoft.com... > Ok, so in my mind I'm tying the word session to an HTTPS session, but > really > it's any ASP session, whether encrypted or not. The session is tracked > regardless. Is there a secure option for session cookies. If there is, > will > that force SSL only as with persistent cookies? Sorry, I come from a PHP > background and am not that familliar with ASP.NET yet. > > "Dominick Baier" wrote: > >> Hi, >> >> the session feature is not designed for such security features - there is >> no requireSSL setting e.g. - so session cookies will always be sent - >> regardless >> of SSL. >> >> You could append the secure attribute manually though. >> >> --- >> Dominick Baier, DevelopMentor >> http://www.leastprivilege.com >> >> > I have some questions about persistent and session cookie handling >> > that I can't quite get ironed out. >> > >> > I have two applications. One is Framework 1.1, W2K3 / IIS6, the other >> > is 2.0, W2K3 / IIS6. For both, HTTPS / SSL is enabled, but not forced, >> > because we use redirection to direct users that request HTTP to HTTPS >> > for the sake of usability. The questions are: >> > >> > For persistent cookies, will the client and server use both HTTP and >> > HTTPS for each cookie operation? Everything that I have read points to >> > "yes", unless the cookie employes the "secure" option, in which case >> > only HTTPS will be used. >> > >> > The question is the same for session cookies. Since the cookie is sent >> > as a header, I would think it would be only HTTPS, but I would have >> > thought the same thing about persistent cookies. Are cookie headers >> > sent only via HTTPS in this scenario or will they use HTTP as well? >> > >> > Also, I noticed that both Frameworks seem vulnerable to the issue >> > where browsing to non-HTTPS pages causes the same session ID to be >> > used for HTTP and HTTPS. This isn't fixed in 2.0 / IIS 6? >> > >> > Thanks so much for any help! I've read the rfc docs, cookie specs, and >> > articles on MSDN, but can't quite find a definitive answer. And >> > unfortunetly, it's impossible to tell on the client side. I've used >> > Fiddler to view mixed content pages, but unfortunetly, client-side >> > every object appears as SSL, regardless of how it was delivered. >> > >> >> >>
Thanks a lot. Like I said, I come from a PHP background, but even that has
been a couple of years and some of the finer details are a little foggy. I think I'm going to recommend putting the "no session" code into our redirect page as well, now that I see that ASP reuses the same session ID. [quoted text, click to view] "Joe Kaplan" wrote:
> You can set the secure (or http only flag for that matter) on both session > and persistent cookies. If you set the secure option, the browser will only > send the cookie on an HTTPS channel, regardless of cookie type. > > Persistent vs. session for cookies just determines whether the browser will > save the cookie to the file system and whether it can be used by multiple > browser processes or not. > > Joe K. > > -- > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services Programming" > http://www.directoryprogramming.net > -- > "Aaron Sanders" <AaronSanders@discussions.microsoft.com> wrote in message > news:2EFD0358-26CB-48B5-9E8F-EF1AF1340B00@microsoft.com... > > Ok, so in my mind I'm tying the word session to an HTTPS session, but > > really > > it's any ASP session, whether encrypted or not. The session is tracked > > regardless. Is there a secure option for session cookies. If there is, > > will > > that force SSL only as with persistent cookies? Sorry, I come from a PHP > > background and am not that familliar with ASP.NET yet. > > > > "Dominick Baier" wrote: > > > >> Hi, > >> > >> the session feature is not designed for such security features - there is > >> no requireSSL setting e.g. - so session cookies will always be sent - > >> regardless > >> of SSL. > >> > >> You could append the secure attribute manually though. > >> > >> --- > >> Dominick Baier, DevelopMentor > >> http://www.leastprivilege.com > >> > >> > I have some questions about persistent and session cookie handling > >> > that I can't quite get ironed out. > >> > > >> > I have two applications. One is Framework 1.1, W2K3 / IIS6, the other > >> > is 2.0, W2K3 / IIS6. For both, HTTPS / SSL is enabled, but not forced, > >> > because we use redirection to direct users that request HTTP to HTTPS > >> > for the sake of usability. The questions are: > >> > > >> > For persistent cookies, will the client and server use both HTTP and > >> > HTTPS for each cookie operation? Everything that I have read points to > >> > "yes", unless the cookie employes the "secure" option, in which case > >> > only HTTPS will be used. > >> > > >> > The question is the same for session cookies. Since the cookie is sent > >> > as a header, I would think it would be only HTTPS, but I would have > >> > thought the same thing about persistent cookies. Are cookie headers > >> > sent only via HTTPS in this scenario or will they use HTTP as well? > >> > > >> > Also, I noticed that both Frameworks seem vulnerable to the issue > >> > where browsing to non-HTTPS pages causes the same session ID to be > >> > used for HTTP and HTTPS. This isn't fixed in 2.0 / IIS 6? > >> > > >> > Thanks so much for any help! I've read the rfc docs, cookie specs, and > >> > articles on MSDN, but can't quite find a definitive answer. And > >> > unfortunetly, it's impossible to tell on the client side. I've used > >> > Fiddler to view mixed content pages, but unfortunetly, client-side > >> > every object appears as SSL, regardless of how it was delivered. > >> > > >> > >> > >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |