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
Related
First of all, I'd like to preface this post by stating that I know this is a terrible user experience...
I have a client who would like to prevent site visitors from sharing login credentials.
Because this is a corporate marketing site, social login is not an option.
The client claims that there is a site where upon registration, a cookie is dropped onto the user's device and the user is also given a unique password that will only work on that specific device.
Does anyone know how to make this work using Wordpress? (I'd like to avoid using third party plugins)
This sounds like the use of Single Sign On (SSO) or 2 factor Authenticaton (2FA) will be needed. The SSO Wikipidea page references a cookie based solution for TCP/IP networks https://en.wikipedia.org/wiki/Single_sign-on so perhaps that's how this came up from your client.
Once you identify what your options are with that, based on what your client is using for authentication, then set up may be a bit easier. I think a plugin would save you a lot of time, since this is a pretty elaborate task. This one may do the trick https://wordpress.org/plugins/miniorange-saml-20-single-sign-on/
Regardless it's pretty challenging to prevent the sharing of credentials. SSO may be a deterrent if that gives access to something else that user doesn't want to share. 2FA doesn't prevent a user from sharing the pin thats generated too. Perhaps the only real way is to require an IP match on a device with bio-metric authenticaton.
I've been reading around and noticed that WordPress 4.0 has a CSRF vulnerability in the wp-login.php file (https://wpvulndb.com/vulnerabilities/7691). It allows users that make the authenticated user visit a HTML file change the password for the authenticated user. As I've been running WordPress 4.0 for a while myself, I have now upgraded it and put it on localhost to try and test this vulnerability as I wanted to see how hard it actually would be to get in.
Now I have struggled across two questions: There is always a key generated at the password reset, how is that even bypassed? Plus, wouldn't I receive an email to confirm the password change?
I've tried to 'exploit' or use this vulnerability to reset the password of my own account. I created a post form, but that didn't work - always getting "you must be authenticated" - no matter what I do.
Can someone direct me to the right direction? Or provide an example? That would be really appreciated, as I don't see a way to create that on my own. I just want this for testing purposes to know the impact and if it would work at all.
I've just come across an interesting fact, apparently a website can have up to 20 seperate cookies.
Ok - fair enough.
But why on earth would you store more than say "UserID", and why would you possibly need 20 cookies?
If you offer the user a way to customize your site you need to store their settings somewhere.
You might need cookies for:
user settings
the session id
the contents of a shopping basket
the last item viewed
the user login
Some that I can think of:
persistent login cookie
session cookie
user-independent settings
user-tracking-cookie
It's a choice. If you don't need 20 cookies, it doesn't mean somebody else won't.
Agree with PiedPiper and thejh. If you are storing user info and customizing the behaviour of your site based on users actions, then very soon you will run out of storage limit of single cookie.
A site can have multiple pages, and a lot of those pages may have some information that might in turn be stored in cookies. It is ironic that you ask WHY you may want to use a lot of cookies where as I have seen a lot of people complaining why ONLY 20!!!
It is a good practice to ensure that you DO NOT create a lot of cookies, simply because IE has 20 cookie limit. Other browsers may have more [or less]!
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'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).