I am working on a project written in PHP and uses a session handler wrapper to store/read sessions from the database. It works perfectly fine.
The only thing, I have noticed, is that I am able to pass a ?PHPSESSID=[session id] and load up a page as if I were them. Of course, there session would have to be active and I’d have to know the session id.
Couldn’t this be brute-forced though? I mean yes the session id is a long set of random characters but it wouldn’t be impossible to brute force or get in another manner.
What steps can I take to help secure those sessions?
Hey,
check also “session.use_only_cookies” configuration parameter. It should be set to “1”.
I’m trying to think why I might need a session in the URL in the first place. I may need a coffee, but I can’t think of a single valid reason ATM.
As for brute force attacks, IMHO Flood Control should help. I don’t think many bad bots are polite enough to make their HTTP requests in a considerate manner.
The user agent is a value that is provided by the “user”, so yes you are correct. You can not trust the user agent.
The key is to mix multiple values that you are able to fetch from the request, under the right circumstances it will always be possible to hijack a session. The only thing you can do is to make it as difficult as possible for someone to do this. Mixing the users dns information with some more values is a good way to do this. Just keep in mind that dns lookups is also expensive to make.
Thought about the user agent - but isn’t that just as easily hijacked? Everything I’ve come across tends to “steal” the session id and browser agent…
Limited to some other “uniquely identifying” information, unless I am missing something!
Well, the only reason to have the session id in the url would be if the user has cookies disabled. It was very common a few years back to see the session ids in the url, these days its more accepted that if you dont have cookies enabled you wont be able to for example stay logged in on a website.
No one will try to brute force a session id, unless they are trying to get the dumbest criminal award of the year 
There is too many variables to even consider this.
On the note of brute force though, it is no problem to create an application that will apply brute force on a server that can no be “catched” by a Flood Control application as the different requests will not be coming from the same source.
Are you using $_REQUEST to retrieve the PHPSESSID? I assume the PHPSESSID is being stored in a cookie?
You can disable the possibility of using the session id directly from the URL in the php config file. You can also set the length of the session id.
However you can also do exactly the same by setting the session id in the cookie file.
What you are mentioning is what is usually considered as “session hijacking”, there is several ways to do this, the most common ones are either to send someone a session you have initiated (that way you know it) or to steal a session id from someone.
If you have written a custom session handler and session hijacking is still possible, then you have done a poor job (no offense). It is pretty simple to protect against this, just put a few more unique values that you check against in addition to the session id.
With the session handler we use, multiple people can have the same session id at the same time without causing any problems. For the system said people are separate entities and they can not access each others data.
Things you can use is for example the users dns, browser information etc to create a “unique” hash of the visitor. However do not use the IP address as some ISPs can change the IP of a visitor at any time.