Why is it always recommended that session_regenerate_id() should be used before the user's session is created.
As per my perception, session_regenerate_id() should be used once the user session id is created, and we need to re-generate it so as to mitigate the session fixation attack by the hacker.
Please suggest!!
I'm not sure where you've gotten recommendation from, but the session_regenerate_id manual shows it being used after session_start, so your assumptions would be correct.
From everything I have read the session_start() has to be called before anything else. The main idea is to create a new id each time so that if a hacker is on the same network, they will not have a static id to use to gain entry to your site. A good explanation of how this is done.
https://youtu.be/8dMsHmlxY0s
and here is an excellent answer that goes into more detail than the video:
https://stackoverflow.com/a/37492488/2654453
Related
Guys i'have a question.
I'm currently buiding a wizard that has 5 step's until being completed.
The user starts by the first step where he generates the entry id.
From there on i start passing the id over the url like this:
host.com/{controller}/{view}/{id}
This is how my url looks like after the step1,
------- currently at view step2 passing the id=120
host.com/{controller}/step2/120
This isn't safe because as you know, anyone can change the id and affect other users's entries. Ofc, it can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Now, my question is... is there a better way to do this?
Any tips for future work?
Is what i'm doing enougth?
(begginer doubt praying for a expert awnser)
Cheers
...It can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Yes, that's true. You should start there.
Here are some other things that you could do:
You could make your entry ids Guids instead, so that a would-be hacker would never try to guess an entry id.
Because using GET for sensitive data is a bad idea, you could, as endyourif suggests, pass the entry ids with hidden fields instead.
If you are truly concerned about the user altering the ID in the URL, then you must spend the additional time adding an "isOwnedBy" like functionality.
As an additional security measure, you could pass it via a hidden variable in the form so it is at least not as easy to change as well.
Edit: I like #LeffeBrune's suggestion of encrypting the idea as well. However, I still suggest that the validation is performed on the function to ensure the user owns the object. It's just good practice.
For one of my project's (weird) requirements, I want to use cookie less sessions. At the same time, "session.use_trans_sid" can not be turned on :(
Does anybody please let me know if is there any other way out ??
Thanks
Manish
Make a custom session manager that identifies the user based on, for example, IP address and user agent and other identifying factors (as IP+UA might not and probably will not be unique). Another (ugly) solution is to just implement the use_trans_sid functionality yourself by adding a session identifier GET parameter to every link by hand (if it's a small site) or with a hidden form (that's non-standard).
If you really want sessions without cookies, you can always put the SID in all your URLs manually. People used to do this quite a bit. :-)
The only other option is to keep the session data on the client and pass it back and forth to and from the server with each request, although technically that would be a sessionless architecture.
That means that for GETs each link has to be rewritten to include all the session variables, and for POSTs they have to be included as hidden fields.
My application uses MVC3 connected to a back end Azure table storage. I use AspProviders for login and logout.
There are times when I can confuse the AspProviders such that I will see the problems listed here
What I would like to know is why does my application even need to store session state. The way my application works is that every page call is independent and it could be sent to any running instance. With this in mind am I adding additional overhead by storing session data and is it really needed?
I hope someone out there can give me some advice.
Thanks,
Jon Wiley
You do not need session state and can even let the application know that, explicitly, that your controller will not be using session at all.
[SessionState (System.Web.SessionState.SessionStateBehavior.Disabled)]
public class MySessionlessController : Controller
{
...
}
Just remember that there are little "gotchas" that you might run into (TempData, for example, relies on session state by default).
Hope this helps.
If none of your application code uses any Session storage, then you can simply remove the Session provider from your web.config
Please also be careful using the AspProviders from the original PDC08 samples - these were never fully QAed to a commercial level.
What is the most common strategy for tracking users with cookies without forcing them to register?
Do I create a guest account, assign a GUID, and then put that GUID value in their cookie? Is there a more generally accepted method of doing this?
Although this is a general web app question, I'm using ASP.NET MVC.
One popular solution, as you write, is to send the GUID to the user inside a cookie.
Obviusly this solution work only if the user has cookies enabled.
Please note that the contents of cookies is perfectly readable by the user who receives it.
Also the session is a good place to store temporary data.
Its duration depends on the configuration of your site and if desired, with a little 'work, it is extremely durable and can have a low impact on server memory (sessions in the db)
A guid in a cookie is one way of doing it.
If the user didn't have cookies enabled, I suppose you could do it another way which which involves creating small hashes (like bit.ly, j.mp et al) and inserting them into the url. All your routes would be populated with this hash (either created at the start of the request, or taken from the url if they already have one).
It's not exactly the cleanest of methods, but it gets around situations where the user doesn't have a cookie enabled and inserts a very small string into the url.
For example http://example.com/fG3Er/Home/Index or http://example.com/Home/Index?guestId=fG3Er where fG3Er is the unique guest id.
Alternatively, you could just append it on to the end of each url as a querystring.
Either way, I definitely favour the guid-based approach, and if the user doesn't want to use cookies on your site, you can always explain to them that their experience will be impaired. You could always find out what proportion of your users disable cookies by creating a test one, and comparing that against the number of actual hits (unless Analytics has a way of determining cookies being enabled - not sure).
As a part of the signup process for my online application, I'm thinking of tracking the source and/or search keywords used to get to my site. This would allow me to see what advertising is working and from where with a somewhat finer grain than Google Analytics would.
I assume I could set some kind of cookie with this information when people get to my site, but I'm not sure how I would go about getting it. Is it even possible?
I'm using Rails, but a language-independent solution (or even just pointers to where to find this information) would be appreciated!
Your best bet IMO would be to use javascript to look for a cookie named "origReferrer" or something like that and if that cookie doesn't exist you should create one (with an expiry of ~24hours) and fill it with the current referrer.
That way you'll have preserved the original referrer all the way from your users first visit and when your users have completed whatever steps you want them to have completed (ie, account creation) you can read back that cookie on the server and do whatever parsing/analyzing you want.
Andy Brice explains the technique in his blog post Cookie tracking for profit and pleasure.