Forms authentication security risk

views:

412

answers:

+1 Q:

Forms authentication security risk

Hello everyone,

I am using VSTS 2008 + C# + .Net 3.5 + IIS 7.0 + ASP.Net. In my understanding of Forms authentication, a session variable (used for authentication identifier -- i.e. when a user passed authentication, the user will have such a session variable, and the session variable is implemneted as a cookie) is established for authenticated user.

My concern of this mode is, each time user access a page in the web site, the session variable will be transferred to server side. It may be sniffered by hacker, and hacker could use such session variable to pretend to be the end user? Is that a security risk?

If it is a security risk, then we have to use https all the time with Forms authentication?

thanks in advance, George

+2 A:

You could refer to this question for some more information. This is a potential security risk and to provide a truly secure connection you would have to use HTTPS.

Robban 2009-09-15 09:40:08

I want to confirm with you each time the same session variable used for Forms authentication will be used each time when used initialize request to a page to the web site? If it is not the same all the time (e.g. each time a random value will be used), I think it is fine.

George2 2009-09-15 09:50:29

+2 A:

Yes, a session id can be stolen by sniffing the traffic, so there is a security risk involved with using the session for identification. It's generally considered to be safe enough for non-critial sites, but if you have a site where the security is critical (banking, et.c) you need to use SSL to be safe enough.

Guffa 2009-09-15 09:40:09

George2 2009-09-15 09:49:44

The session id is an id for the session, not for the user. When you open up the browser and go to the site you get a new session each time. The session lives on the server for 20 minutes (by default) after your last request, after that the session id is no longer valid, and you get a new session when you go to the site.

Guffa 2009-09-15 11:09:55

1. My concern is, suppose legal user A opens browser and the user is assigned with session ID A by server. At the same time and within 20 mins, if a hacker in the middle sniffered the session ID A, the hacker could use this value to pretend to be user A. So, is it a security risk? 2. Could you confirm each time (after authenticated by server using Forms authentication) when we send request to server, the same authentication session variable value will be transferred?

George2 2009-09-15 11:13:02

The hacker would get access to the session information, but not the user information, that is in another cookie, that would also be passed in the browser request and could be sniffed by the hacker.

ck 2009-09-15 13:25:28

@George2: Yes, if someone is at the right place at the right time with the right equipment, they can sniff the network traffic to pick up the cookie, and spoof a request to impersonate the session. Unless all traffic is encrypted (SSL) there is always a risk for this.

Guffa 2009-09-15 13:55:50

@ck, I am confused about -- "but not the user information". I think if the session Id is stolen by hacker, the hacker will pretend to be the user and get access to all the information of the user (suppose there is a user profile page in the site to see all user information after authenticated and logged in). Why do you think hacker can not get user information.

George2 2009-09-15 14:10:34

@Guffa, I am surprised to learn the exact same session cookie value will be passed each time in each request to server. It is a big security risk (previously I think ASP.Net Forms authentication may be smarter to send random value each time to protect from reply attack). How do you think about it?

George2 2009-09-15 14:12:02

@George2: The browser doesn't scramble or encrypt the cookies, what you send to the browser is exactly what you get back. If the browser would scramble the value, the algorithm would be publically known as the server has to be able read it, so it would be pointless. Also, a scrambled value would be just as easy to pick up and reuse as an unscrambled value, so it wouldn't really add any protection.

Guffa 2009-09-15 14:55:30

Thanks Guffa, 1. I want to confirm with you that authentication session cookie (whose name is .ASPXAUTH by default) is different from session ID cookie (whose name is SessionID)? 2. I still surprised to learn each time the same Forms authentication cookie value will be sent. But anyway seems I need to use https all the time after authentication for my application to protect sniffer.

George2 2009-09-15 15:00:06

+1 A:

I've had similar concerns in connection to a request from one of our partners... ( See in details here: http://stackoverflow.com/questions/1367574/rewriting-urls-using-reverse-proxy )

As it turns out this "legitimate" process is actually using a hacking method called the "middle man". It technically pretends to be the user by keeping the cookie ID in its own session context while dealing with the server and keep a sparate one for the client computer.

So, in theory it could be done and it is a threat. Using SSL is the right way to go in my opinion if the data is in any way sensitive.

Funny enough in this Microsoft Support article http://support.microsoft.com/kb/910443 the phrasing makes you believe that it is actually the same for each request...

Forms authentication cookie is nothing but the container for forms authentication ticket. The ticket is passed as the value of the forms authentication cookie with each request and is used by forms authentication, on the server, to identify an authenticated user.

The cookie could be encrypted, using 3DES encryption. This could be enabled by setting the protection attribute to Validation of the authentication section of the web.config file. Using this setting the server verifies the data on the cookie for each transaction. This adds a little overhead though...

G Berdal 2009-09-15 10:01:24

George2 2009-09-15 10:06:32

I don't think it is the same all the time, but I'll look into it.

G Berdal 2009-09-15 10:51:33

If each request will use a different number, I think it should not be a security risk? Because even if you sniffer session value for this time, next time since value changes, the value sniffered last time will not be useful. Any comments?

George2 2009-09-15 11:02:30

If I was Microsoft I would have done it that way. However, it is worth checking because there could be flaws even in the best systems...

G Berdal 2009-09-15 11:05:23

Thanks G, let me know when you have results about whether the same session variable value for authentication usage will be sent each time we access a new page in the same web site using Forms authentication.

George2 2009-09-15 11:14:12

Thanks for your update, looks like we have to use SSL in order to serve critical application?

George2 2009-09-15 11:18:00

I think I have to agree with others that the best practice is to use SSL if the data is in any way sensitive. SSL has additional values by establishing a much safer way of communication overall.

G Berdal 2009-09-15 12:13:40

It would make no difference if it changed every time, the hacker would just need to use the information before the legitimate user did.

ck 2009-09-15 13:26:43

@G Berdal, I am surprised to learn the exact same session cookie value will be passed each time in each request to server. It is a big security risk (previously I think ASP.Net Forms authentication may be smarter to send random value each time to protect from reply attack). How do you think about it?

George2 2009-09-15 14:22:43

@ck, I think you mean the scenario of man in the middle attack (hacker will get cookie value each time even if cookie value changed)? If yes, I think using pseudo-random value each time will prevent hacker who sniffer only once and take it for granted that cookie vakue will never change, and using pseudo-random value will never prevent man in the middle attack. Any comments?

George2 2009-09-15 14:25:08

Robban mentioned another post above which kind of puts a lid on this can of worms we managed to open... Jeff Prosise is brilliant brain and a recognised author. If he couldn't find an aswer to this, apart from writing his own component then I don't see much chance that I could... However, I'll keep this in mind for future reference and never use Froms authentication without SSL.

G Berdal 2009-09-15 14:48:16

Thanks G Berdal, 1. I want to confirm with you that authentication session cookie (whose name is .ASPXAUTH by default) is different from session ID cookie (whose name is SessionID)? 2. I still surprised to learn each time the same Forms authentication cookie value will be sent. But anyway seems I need to use https all the time after authentication for my application to protect sniffer.

George2 2009-09-15 15:01:17

The ASPXAUTH cookie is used to determine if a user is authenticated.SESSIONID is to identify the user of the session state. If my understanding is right, they must be different.

G Berdal 2009-09-15 15:36:18

Thanks G Berdal! Let me confirm finally, 1. the same session variable value will be sent; 2. we need to use https to protect; 3. authentication session cookie and session identifier cookie are two different session cookies. Let me know if anything wrong or you think I am correct for all of them. :-)Based on your final confirmation on this long discussion, I will mark your reply as answered. :-)

George2 2009-09-15 16:10:04

As of my best knowledge, these conclusions are correct.

G Berdal 2009-09-15 21:55:24

Cool G! I have marked your reply as answered.

George2 2009-09-16 03:36:55

+3 A:

The user's session ID is not used as part of the authentication cookie - the authentication cookie, and the session cookie are separate. So if parts of your web site required authentication then the session ID would not be enough to get in.

Having said that, if a hacker is sniffing traffic then they're going to see the authentication cookie as well, and so could recreate both.

blowdart 2009-09-15 13:19:42

Thanks blowdart, authentication cookie I think you mean ".ASPXAUTH" session cookie? For "user's session ID" you mean?

George2 2009-09-15 14:20:22

Actually in this discussion when I say authenticaion session variable, I mean ".ASPXAUTH". Any comments?

George2 2009-09-15 14:21:13

Why do you think it's a variable?The session cookie, which holds the session identifier is named asp.net_sessionid (although you can change that) It does not hold anything but a guid - no session variables are held in it. The forms auth cookie is more complicated (and signed against tampering). Compromise of a session ID does not authenticate a user, but

blowdart 2009-09-15 17:10:49

Thanks blowdart, sorry for my bad description. My point is, if https is not used, hacker could sniffer them both (since each of them are transfered in each request to web site). Any comments?BTW: I am using a bad word variable, I should say session cookie.

George2 2009-09-15 17:41:14

Yes - this is correct.

blowdart 2009-09-15 20:13:26

ansaurus

tags:

views:

answers:

Forms authentication security risk

related questions