Vague Security bug? In SMF

Started by !wooha, March 15, 2009, 12:25:07 AM

Previous topic - Next topic

cflforum

Quote from: regularexpression on March 27, 2009, 05:29:03 PM
Theres always risk in anything.
SMF has done pretty much all it can to reduce the risk as much as possible.

I apologize as obviously I didnt ask a proper question to which you could reply.
I guess what I should ask is, the scenario described above, where an injected script either from SMF or embedded Javascript/Flash, parse out the session code and use it for anything useful or is it one of those hypotethical risks?

I understand that the session code protects functions by 'proving' the originator of a request -if that value is not secret, then actions can be taken that are otherwise rejected.

I ask this because there is often a lot of FUD on these 'security' reports - most are conceptual and unworkable. I just wanted to know if this was a 'real' possibility or not, thanks. I see that your title is 'developer' so I guess you are the best qualified to speak to this?

thanks for your time.

karlbenson

As you'll note from the humorous responses above, there isn't much else that can done which wouldn't reduce functionality of a forum. (eg going back to the dark days of static html pages with no functionality/interactivity)

aldo

I thought SMF also hashed your session id as well? As in the session id SMF outputs on the page isn't really your true session... So even if someone were to get a hold of it, they would need to unhash it, which I think SMF hashes it with SHA-1 :P

A moderately practical idea to prevent someone from stealing your session would be doing something such as before allowing the use of the session data, you check the cookie information against what is in the session data. Basically, get the cookies information which would contain the member id and the password (hashed and what not), and compare it to the member id and the password inside the session data... if its the same, let them use it, if its not, don't :)

It works, I do it sometimes. It makes sense... even if someone were to steal your PHPSESSID, they would need to have your member id (easy to get) and your hashed password (probably not so easy to get), and practically put an end to session stealing because you might as well just try to get their password XD.

Advertisement: