Is it possible to provide version information to go with an HTTP cookie? I have a cookie which tells the page whether or not to prompt a user for action, based on whether or not the user wants the prompt. On a version upgrade of the page, I need to prompt the user regardless. Can I integrate this into my existing cookie?
A cookie is little more than a string with an expiry time. You can encode whatever information you like into that cookie, including a number representing a version.
Related
I think this is not the first time someone askes this question. But I couldn't get a clear answer.
Is it possible to "hack" a cookie? For example, If someone is logged in, I create an 'user id' cookie, with value 'usr01301', and this is a reference to that user. If this user is loading the webpage, the website will check for cookies. If a 'user id' is available, the user will login with the account connected to the user id.
But, is someone able to write this cookie manually? Or change it to another ID? To be able to login with this cookie.
YES
Session Hijacking is a very real thing, and it is easy to exploit on any website that does not have good security systems in place. Using a username in a cookie is a really, really bad idea.
There are browser plugins that make it easy to edit cookies, but you can even do it using the developer console that ships with many browsers.
For that matter, you don't need a browser at all. wget can perform http requests with cookies from the command line.
predictable cookies are a bad idea. with that, anyone can predict cookie for any user existed on that website. and manually edit also possible ad there are lot of tools available o internet to do it autometically.
https://bugarena.com/single/Y7A7WOZ1520
I have a ASP.NET website where after a specific user action, I have to issue a new AUTH cookie almost identical to the one the user already currently has. I'm having trouble finding out whether the current AUTH cookie is supposed to be persisted or not. Any ideas on how to do this?
If the cookie expiration isn't set, then it's session.
If you are trying to discover it's life via the browser, you can use firebug with the firecookie plugin. Or the web developer tool will also enumerate all the cookies on a page.
Any cookie that is not session will have Expires field. If you send it into feature date - you will get it "permanent" until the time expires. If you want to maintain "permanent" cookie status you would refresh it on next user login and shift it further into the future. One month is usually enough
I've got a site that uses Forms Authentication (with a custom membership provider, but that's not important right now). In the secure part of the website, the customer can purchase goods and pay for them via WorldPay.
Once they come back from WorldPay, if there's a link back into the secure part of the website, can I reasonably expect the forms auth ticket (stored in a session cookie) to have survived (timeout notwithstanding)?
The ticket is set thus:
FormsAuthentication.SetAuthCookie(username, false);
FormsAuthentication.RedirectFromLoginPage(username, false);
The work is part of a redevelopment, and I would rather have a quick "yes/no/maybe" answer before writing lots of code that may not be required - we do not want to have the user log back into the secure part of the site so we recreate their login based on the information returned from WorldPay. Obviously, if the user is going to be remembered, I don't have to write that code - I'm quite lazy ;-)
Thank you for any suggestions,
Mike K.
Forms Authentication uses a cookie.
A session cookie (which is stored in memory) lives as long as the session does not timeout and you do not close the browser.
You may also be able to set the life time of the cookie, then it will be written to disk, and available to all browser instances. In this case you will also be logged out if the session timesout on the server.
If you're calling
FormsAuthentication.SetAuthCookie(username, false);
then the cookie will survive for as long as the value specified in your web.config or until the user logs-out.
If you redirect them to a 3rd-party site during the course of their visit to your site, this cookie will remain. The 3rd-party site won't have access to your auth cookie.
In short, they will still be logged-in on your site when WorldPay redirects them back.
Even shorter: yes.
Hope this helps.
The other answers here seem to point out to this being a non-issue, but I thought I'd just add that if you're posting data to their gateway, any variables which start with MC_ will be returned to you on the other side. I'm not sure if this helps or not!
I am developing my login for my new homepage.
Now I found out, that I must save something like the userID (or another value that i can recognize my user) in the session variable of the browser.
At the moment I use INT for the userID.
So isn't it unsafe to put the userID in the session?
E.g. when I edit my session variable manual from userID 111 to userID 112, than I am logged in as a complete other user?!
Yes, it is unsafe to rely only on user ID.
You may wish to add a unique authentication token generated and remembered by the server. Also a very simple solution, but it will stop manipulating the user ID since the correct value for authentication token for the other user cannot be guessed.
You also need to submit both user ID and the corresponding authentication token at each request to be jointly validated on the server side, prior to performing the requested operation.
P.S. The above applies if you store this information in cookies which are accessible on the client side and can be manipulated. The viewstate (serialized in pages) can also be manipulated. The session collection is a server-side variable that is not available on the client so it cannot be manipulated. In this later case your user ID should be safe.
I would recommend you to implement the dual system: store the user ID and the token both in cookies and in the session and use the same validation logic (for simplicity). Should cookies be disabled you automatically fallback to using the session without changing your code.
The session variable is not stored in the browser, it is stored on the web server. (Typically anyway.)
A token indicating which session variable to use, is stored in the browser.
So storing the userid in the session variable is fine, as the user has no access to this directly.
If the user were to change the session token, to another one, that would be a problem, but they'd need to know the other token first. (I'm not sure how to do that myself.).
(You can further diminish this by using encryption, or other identifies like IPAddresses etc, it's really a case of how secure do you need your website to be?).
Also, if your site needs the user to log in, it's advisable to use https/SSL.
As Bravax says, the user does not have access to the Session variables (Cookies they do have access to).
If you are worried at all I would use a GUID instead as they are not sequential and nearly impossible to guess.
Also, have you looked at the built in stuff in .Net for authentication? Look at FormsAuthentication.
HTH,
Arry
I've got an existing site I'm taking over, and right now it stores, in a session variable, the id of the currently logged in user (if logged in at all -- otherwise I'm sure it is empty string or null or something).
The client now wants, after someone is logged in, to "keep" them logged in on that computer for an indefinite amount of time.
ASP.net Sessions have a maximum idle time of 1 day, I believe. The website isn't written all that well in the Flash portion (whole front end is flash) and the flash will process a login, then, as long as the flash isn't reloaded, assume that the user is still "logged in".
I think my solution is to ALSO store a client side cookie with some GUID value and hold in the database the associated user id...sort of like a session that never expires. So, when the page is loaded, I can check my cookie, use that to select the userid out of the database, and if we find one, then set the session value that says user 23 is logged in.
Does anyone see any issues with this perspective? Would you recommend something different? I really don't want to refactor a bunch of the existing code, but just slip this in on top...
PS -- security is not really a concern. The only reason they have people log in is so we can track orders by a person, but no money changes hands through this website. There is also no personal information that a user can view or edit, either.
This is how I do it. I actually have a cookie that holds their login and password, this way I can automatically log them in should they not be logged in. I expire the cookie after a couple of days of inactivity. The downside is that everyone forgets their password because the only time they really have to enter their password is when they come back from extended time-off.
This is for an internal application, with the same customer demands that you have and this works ... and makes the customer happy.
One thing we may end up doing is just using Windows authenication, might actually work better in this circumstance.
That's the way I do it, but the problem with it (at least I think its a problem) is that when you store the username and password in a cookie there is not any encrypting when you add the cookie. If you look at the cookies in your browser the username and password are displayed there plain as day. Is it possible to get some kind of encrypting on the cookies you store? Or how would you handle this?
Check this blog posting out http://timmaxey.net/archive/2009/03/06/asp.net-cookie-auto-log-in.aspx basically you needs to save the cookie with a guid a series, and a token, the token, in my case, changes all the time, the series is something that is generated based on something, like the guid and id combo or whatever, then the guid is always stored with the user. There is a cookie table to stored this info etc... pretty secure, not 100%, but pretty good... Tim Maxey
I recommend using the Enterprise Library Crypto App Block to store an encrypted cookie which is nothing more than a GUID. Get the GUID, and use a session table in the database to track user info.
At the session start event, get the user info and cache it.
Using the session object is not recommend for user info because it won't work on a web farm, unless you use a database for session state.
You're basically rolling your own session state at that point, and I'm fine with that. However, I would not go the route of storing the username/password in a cookie (even if encrypted). There's no way to expire that from the server-side. You can always remove your row in the table to force a user to log in again, but if they hold the username/password they hold the keys to the kingdom.