How to protect GET methods if the cookie is stolen since Antiforgery Token only protects the POST methods? The web application can return sensitive information via GET method.
I am using .AspNetCore claim based identity. I was trying to use Postman to view the content of the GET method, but I cannot get the it to work.
I assume this is theoretically possible. An authorized user cookie can be hijacked by a man sit in middle right?
The site is secured by SSL and I think the .AspNetCore claim based identity is session based cookie. What are the chances to break in to execute the GET methods and get returns values. How to secure the application?
It should never get to that point
Don't use just a cookie to validate a user. You should use several cookies based on each session, such as the device name or id, the device's IP address, a session ID stored in their browser, potentially something stored in their local data (permanently stored even if cookies are deleted) that validates that particular PC etc. There are plenty of other methods of security a user's identity.
However, if you use a session cookie and nothing else to authenticate a user, then you should probably revise how your application secures its users first. Because if that session cookie is stolen, then it's a bad sign for your user.
Related
Instead of using ASP.NET MVC User's system, I'm simply using session, as the following:
When he logs in (username + password), I fetch the corresponding user from the Database and set:
Session["UserId"] = fetchedUser.UserId;
Then, I'm always checking if he is logged in:
if (Session["UserId"] != null && ...)
The problem is that if someone copies the value of ASP.NET_SessionId from a logged in user (eg: user goes to bathroom and coworker who is sitten next to him checks his cookies with chrome inspector), then he will be able to create a cookie in his computer and act as that user.
My questions are:
Why are sessions safer than cookies if the session id is saved in a cookie?
Can I make this safer (and continue using session)?
How does internally ASP.NET User authetication system do it?
A primary reason for not using Session as an authentication mechanism is that it could render your application vulnerable to Session Fixation. For example, a problem could be if a user arrived on your site using the HTTP protocol and receives a session ID that is stored in the ASP.NET_SessionId cookie. The user may later log in, and even though your login pages might be secured under HTTPS the session token has already been generated under HTTP which means it has already been transported using cleartext.
To answer your other points:
Why are sessions safer than cookies if the session id is saved in a
cookie?
The data stored in session is stored server side, so it is more difficult for an attacker to tamper with this data. All the cookie stores is a token for this data, rather than the data itself. Having said that, it is still safer to use the FormsAuthenticationProvider as this creates a new authentication token once login is complete rather than on session start for the reasons of avoiding session fixation as above.
Can I make this safer (and continue using session)? How does
internally ASP.NET User authetication system do it?
The built in provider is already fit for purpose, so it would be desirable to use that rather than fudge another mechanism to meet your requirements. It is also easily extensible so you can customise it to your needs. The ASP.NET User Authentication creates an encrypted ticket and stores it in the cookie rather than storing a reference to a server side variable: http://support.microsoft.com/kb/910443
I would also draw your attention to the signout mechanism and how to secure it. Particularly
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.
Details here: http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.signout.aspx
In addition you may want to set the "secure" flag on your ASP auth cookie to prevent it being leaked over HTTP by a MITM attacker.
My understanding is that ASP generates a cookie to authenticate a session. However, if that cookie is sent back and forth over a non https channel, can't I spoof it simply by spoofing the cookie? Can the cookie be locked to a particular IP or other machine fingerprint?
Sessions in ASP.NET aren't authenticated - authentication is entirely separate. By taking a session cookie and recreating it yes you can hijack the session, and if you lift an authentication cookie then you can authenticate as a user (which is why, by default, authentication cookies expire) - see http://msdn.microsoft.com/en-us/library/ms178581.aspx
The security note is quite clear;
SessionID values are sent in clear text, whether as a cookie or as
part of the URL. A malicious user could get access to the session of
another user by obtaining the SessionID value and including it in
requests to the server. If you are storing sensitive information in
session state, it is recommended that you use SSL to encrypt any
communication between the browser and server that includes the
SessionID value.
At my last job we worked around this by tracking the user's session ID (we appended a guid to the URL as a query string, there are other ways) in a database where we would also store the ip address which made the request. For all subsequent requests (anything with a session ID, a requirement to get any sensitive information) we simply check the session ID and the ip making the request against the values stored when we authenticated and set up the session. Request.UserHostAddress is a little harder to spoof. There is some overhead, but it is way more secure than cookies.
i read few article about Session Hijacking. hacker sniff cookie and get the session id from there. but i think session id is stored in cookie as encrypted value. is not it?
is it possible to decrypt easily?
what other sensitive data is stored in session cookie...please explain. whatever we stored in session variable from server side code that is stored in session cookie...is it right?
please guide me regarding session cookie and what would be best way to protect Session hijacking. thanks
The idea is that they get the session cookie and used it as it is, to send it to the server and server connects the cookie with the victim session. Actually there is no data on session cookie, just an encrypted number of the session id.
Now there is a case that sensitive data stored on cookie and that is the Roles of the currenct user. To avoid a possible decrypt and change on web.config on <roleManager cacheRolesInCookie="false"
Also on the authentication cookie and on role manager always use the requireSSL="true", so its impossible to steal the cookie of authentication, but you must use secure pages for this make work.
How some can stole a critical session. This can be done if the programmer depends the critical data that show to the user, on the session id. For example, if you store the phone number and the name on a session variable and show that to the user, then some one can stole the full web page and read it (if not ssl). If you have connect the backoffice and the access to hidden administrate page with the session id, then if some steal the session cookie and open the pages, then he can gets on that administrators back office pages.
So its up to you not to store critical information's on session data, and always use ssl pages to administrate and to get send cookie critical data.
Now if a hacker steal the session cookie and you there just store what users see in previous pages, a history of products like amazon, then is not big deal because still can not connect this history with the user, but also can anyone sniff the urls that a user see.
Of course its up to you also to not store critical data on any unencrypted cookie !
So you split your data to critical ones, and not critical ones, and always use SSL for page and cookie for the critical ones, and never trust the data that comes from unsecure pages.
You can also read :
Can some hacker steal the cookie from a user and login with that name on a web site?
Hope this helps you.
An ASP.NET cookie stores Session ID and an Authorization Ticket; however, the issue is not whether one can decrypt the cookie, but rather to be able to create one with identical values and trick the server into believing that your copy of the original cookie is the real one.
The HTTP protocol is stateless so client and server don't maintain information about each other. Session Cookies (using the Session ID and Authorization Ticket) is how they keep track of each other. The web server knows which Session ID is attached to which authorization ticket and if you can provide a valid pair of these values, the web server will happily accept it. The Web server encrypts the cookie using a symmetric encryption algorithm and an autogenerated key (default setting). You can tweak these settings, if you want to, by modifying the appropriate sections in the machine.config file.
I have a service (WCF) with which my ASP.NET page will communicate. The WCF service has hashed passwords in its data store (a file actually). The WCF service requires the username and the hashed password on every call.
Nowm the problem I'm encountering is that if I authenticate the user with forms authentication in ASP.NET, a cookie will be saved in the user's computer after the user is authenticated but I would like to save the username and hashed password too so that the user may able to use the WCF service. Where should this information should be saved so that it is safe and secure?
Should I use session variables? If I choose that option that, then should I switch from forms-based authentication and manually authenticate using session variables or use both forms-based autentication for web page access and store the username and hashed password in a session variable? What are the pros and cons of each?
Can you store the username and password (hashed of course) in another cookie? Each time you communicate, grab the cookie and send it along with the username to the WCF service.
On the WCF service end you'll have the username and the hashed username/password combo. If you apply the same hashing you should end up with the same string that you've got stored in the WCF end, if they match the user is valid.
Regards to your edit:
Not sure that there is a much of a distinction between them as you're suggestion. If you use forms authentication a session variable is created and (assuming you're using cookies) a cookie is stored that allows the session variable to be associated with the user. So even if use forms authentication you're still using session variables.
The only question really is if you want to store a hashed version of the password entered by the user in a session/cookie. The pro is that its being stored somewhere and that could potentially pose a security risk.
A completely alternative approach is rather than sending the password and re-authentication upon each request, send an authentication token that doesn't relate to the user's password. Validate this token instead.
The token could be issued upon successful login, and should use the same hashing algorithm as the WCF. Send the username and token as part of the request and validate that it is valid, authorised and still current.
Definitely not on the client side (cookies). Use the cookie to authenticate the user to ASP and for the session ID. This is the ASP.NET default. Than store the username and PW in the session.
Consider using Windows Authentication or other recommended mechanisms, since they will bring more security.
#your edit: I suggest keep using forms authentication along with related controls (or any other preimplemented method in ASP.NET). Reimplementing it on your own would make large effords for no reason - at least if you want to get the same safety as the .NET authentication brings. It really is more than comparing hashed passwords..! Also, use the session, since this is the natural place to store any additional user related data. Again - sessions are easily configured and relatively safe.
I'm working on a website where I get a feed of usernames / hashed passwords from another service. When someone sucesfully logs in I set a forms authentication cookie with FormsAuthentication.SetAuthCookie.
My client doesn't like multiple people logged with the same credentials. They would like a log in to invalidate any currently logged in clients.
There isn't a method on FormsAuthentication to tell the server "invalidate any other cookie under this name". KB900111 suggests the server doesn't maintain a list of valid cookies. So my approach isn't sounding good.
What's the alternative? Time to ditch forms auth?
Not necessarily. Forms auth still provides quite a bit of baked-in functionality you might want. Maybe you can generate and issue a Guid the first time each user logs in, and store that on the server-side, and in a cookie (security ticket preferably). Every time a request is made, you check to make sure the user is using not only the correct credentials, but also the same machine and browser (based on the cookie you issued the user when the user logged in). You would of course have to make sure that your Guid expires at some point, and also make sure you clear it out when the user signs out.