Web application security

I am testing a web application for security holes and I came across the following 2 cases.

1. Using a proxy, I intercept all requests going through to the application and save all cookies. Using these saved cookies, I am able to recover the session on a different machine and access the user's personal info without any further authentication. I am thinking any admin could pull this sort of thing and gain access to the personal information of all users on the network.

2. Same as case 1, but I am able to recover the session on a diff开发者_如何学编程erent machine even after the original user has properly logged out. i.e the session seems to remain valid on the server even after the original user has logged out and all session related cookies are removed on the client-side.

I am fairly certain that case 2 is a security flaw in the web application. I am wondering if case 1 could also technically be considered a vulnerability in the web application. If so, what are some ways to fix this?

Case 1. It is not really a security flaw that the sysadmin can recover your session, since it's normally possible for the sysadmin to recover password hashes and try to crack them or to create some security flaw to use against their users.

Though it could probably be harmless to consider that a sysadmin could try to recover your session, upstream it may not be so( in the rest of the internet where someone connects) and it's generally considered a good practice to implement all user logins/sensitive activity in HTTPS.

Just to comment on a reply above, when using cookies through HTTPS, IT IS NOT POSSIBLE to recover them externally to the computer(as in a man-in-the-middle).

Case 2. It is not really a security flaw. When considering this case you assume Case 1, which should not happen at the first place(Someone sniff your cookies).

Note: Apart from securing the logins/sensitive activity through HTTPS, it could be wise to encrypt the WHOLE website in the same domain, since it is possible to inject traffic to the client to expose their cookies if some page on the same domain is not encrypted.

It is difficult to remove a user identification from the server when the user does not actively logs out(clicking a button on the webapp which removes the indentification). If the user just closes the page, the server does not know that the user logged of and considers the user identification still valid.

You can associate a user to an ip, which difficults an attacker to sniff the cookies and use them from a different ip but it does not work in normal user subnets, since with NAT all the machines in the subnet have the same external ip.

Note: Using a self-signed encryption has it's dangers. Though it protects the user from external sniffing it is easy for someone to trick a inattentive user to log in a spoofed version of you're application. I've done this with captive portals on WAPs.

SSL will help prevent man in the middle attacks as you describe.

You could store a variable in the session that contains the user's IP, user agent, etc. or a hash of them and check it every request so that if it is hijacked the hijackers would have to fake those. Not perfect but it helps.

I know of only one (1) website that has a session manager in the profile page. You can see where you are still logged in, pick any or all, and log them out.

Some content management systems allow for a maximum logged in time. Depending on how your users use your page (for example: never will a user stay on a page for longer than 3 minutes) you can set this value very low.

It's not a technical vulnerability in the web application. The web application is, however, the appointed party entrusted with solving these problems.

About the question if case 1 is a vulnerability, of course it is. Why? Because its a flaw or weakness in your system's design, implementation, or operation that could get exploited to violate the system's security policy, which is the exact definition of vulnerability.

To solve it, what I usually do is ro record the user agent sent by the succesful login. I encript it and then everytime a user wants anything from the server I check if the current user agent matches the one sent at login.

You could combine this with the IP address and check if these two parameters change betwen requests, if they do then its very probable someone hijacked the cookie.

if ( ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT'])) )
die( "{ 'succes': false , 'text' : 'Please re-log in.' );