SMF Development > Bug Reports
[4244]SMF 2.0 RC3 - Obfuscation of session variable name breaks integration
MultiformeIngegno:
...and about the possibility to replace the piece of code with the RC2 one (that worked properly)?
Orstio:
It's not just one piece of code that needs changing. As I said, it's not just a quick patch, or I would have posted one for you. It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.
N. N.:
Tracked as http://dev.simplemachines.org/mantis/view.php?id=4244, in order to be more easily found and considered by the devs. Also reported it directly to the people responsible with it.
Thank you both for the report and Orstio for taking the time to look into it. I will most likely not be able myself to investigate this properly soon, for lack of time and tools at my disposal for the moment, but hopefully it will be taken into consideration as soon as possible.
Arantor:
--- Quote from: Orstio on April 04, 2010, 09:25:14 AM ---It's not just one piece of code that needs changing. As I said, it's not just a quick patch, or I would have posted one for you. It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.
--- End quote ---
Well, I think the idea is that it makes it harder to grab the session and reuse it since you're no longer user sesc=[session id] in the HTTP request, you also need the session variable too.
Though if you can grab one... presumably you can grab the other too. It just makes it slightly harder to notice if you're just randomly snooping.
Orstio:
--- Quote from: Arantor on April 04, 2010, 09:44:30 AM ---
--- Quote from: Orstio on April 04, 2010, 09:25:14 AM ---It's not just one piece of code that needs changing. As I said, it's not just a quick patch, or I would have posted one for you. It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.
--- End quote ---
Well, I think the idea is that it makes it harder to grab the session and reuse it since you're no longer user sesc=[session id] in the HTTP request, you also need the session variable too.
Though if you can grab one... presumably you can grab the other too. It just makes it slightly harder to notice if you're just randomly snooping.
--- End quote ---
It's the same logic that makes people want to remove their copyright for "security reasons". Script-kiddies are called script-kiddies because they run automated scripts. Nobody is doing any random snooping, they are doing systematic runs of exploit checks. If $sesc could have been exploited, then the exploit should have been fixed, not obfuscated. What that says to me is that the underlying security issue is still there, it's just hidden better.
And, I agree with you -- it is harder to grab the session and reuse it. In fact, it's pretty much impossible, even from SSI.php. Thus, this bug report. See, if a security fix breaks functionality, it's what's called "throwing the baby out with the bath-water". It's like welding the doors shut on your car so nobody can get in to steal it. Unfortunately, it also means you can't get in to drive it either.
There is no point in the SSI functionality if it isn't going to work. It's bad enough that the SSI login/logout redirect bug has been around since the session fixation security fix (1.1.6?) and never fixed. Now there's an even bigger SSI.php file with even more functions, and half of them rendered useless by obfuscating a variable name.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version