Jump to content

IPB 3 Security Vulnerability Question


ᴡᴅツ

Recommended Posts

[quote name='! αη∂у яιχση !' date='08 August 2009 - 02:13 PM' timestamp='1249755200' post='1840583']
I wouldn't say thats possible, as far as I can remember, every OS that gets installed on to a pc or mac, has different serials, the OS matches your motherboard (not that sure though)

You can detect what OS someone is using if you know how. You can't get the product key or something like that, but you can tell if it's Windows (98/ME/2K/XP/2003/etc), Linux, etc.


[quote name='IP.iBaLLiN' date='08 August 2009 - 11:39 AM' timestamp='1249745961' post='1840529']
Wolfie, there is a feature to match browser and OS in the admin CP, I believe, right below the "Match IP" setting.

That affects the public end of the board, not the ACP itself.

Link to comment
Share on other sites

What you're suggesting is basically the browser signature technique. While it's not necessarily a bad idea, it by no means mitigates all possibilities of session hijacking.
While browser headers generally remain constant for the same user, and are relayed between proxies and gateways, it's not something that can be fundamentally relied upon.
Also, it is possible for two users to have an identical signature, and a proxy may normalise the header values, making the check pointless in some cases. Also, the attacker could just make the user's browser submit a request to their own server, at which point they could capture the header values and manipulate what their browser is sending (a feat which is much easier than it sounds with a bit of social engineering).

Like I say, it's not a bad idea, it just won't improve security as much as it sounds like it might when you first hear the idea. And there's certainly no immediate threat that needs to be patched anyway.

Link to comment
Share on other sites

I know that there's no true way to make 100% certain that the user, even if at the same IP, is indeed the same person. Just would be nice if there was something that would help to make it a little bit tighter. Also, why are no cookies used? Could the session ID itself at least be stored, or a hash of it, which would be set to expire an hour (or however long the admin configures it for) after the last usage? No personal information such as a password or member ID, and in conjunction with IP checking, would make it very difficult for someone to hijack the session (albeit not impossible). Just bothers me that this leaves a gap in security.

Link to comment
Share on other sites

Ok, let's get rid of the fear-tactics being used in this topic ok? There is no inherent security risk in the way the ACP is managed now. As someone else already pointed out, it has been this way since 1.3, and I assure you - if there was a problem, it would be found and fixed by now.

Using a cookie to validate the session proved LESS secure. If an XSS attack somehow gets through, an attacker can then just fix their cookie and reach your ACP.

Presently, a secure session id is used, which of course can't be known unless you share it remotely with a user. We mitigate any links to external resources through the ACP (i.e. if you view a member who links to an offsite avatar, you actually go through a special local script on the public side that looks up the avatar, to try to prevent you referrer URL being passed), though it's not always 100% possible to stop this. For this reason, we also by default match your IP address. Unless you actually go edit a file to disable this, you're fine.

On a local environment where everyone's IP address is the same, you have bigger issues (as in no one can use the site). That's what the "Match x-forwarded-for" setting is for, at which point your IP addresses are no longer the same, and the ACP then does not suffer from the issue Wolfie is suggesting.

[quote name='.Wolfie' date='09 August 2009 - 11:55 AM' timestamp='1249833326' post='1840897']
I know that there's no true way to make 100% certain that the user, even if at the same IP, is indeed the same person. Just would be nice if there was something that would help to make it a little bit tighter. Also, why are no cookies used? Could the session ID itself at least be stored, or a hash of it, which would be set to expire an hour (or however long the admin configures it for) after the last usage? No personal information such as a password or member ID, and in conjunction with IP checking, would make it very difficult for someone to hijack the session (albeit not impossible). Just bothers me that this leaves a gap in security.
[/quote]

Why "would it be nice if there was something that would help to make it a little bit tighter"? Can I ask you this - how many times has your ACP been hacked through someone getting your ACP session ID? If it's 0, then why does it need to be tighter?

Let's worry about real issues here, instead of non-issues. :) This, I'd say, is presently a non-issue.

Link to comment
Share on other sites

I'm still curious about the question I asked which is copied below.

[quote name='Archon Neo' date='10 August 2009 - 12:22 AM' timestamp='1249860164' post='1841086']
I have a question. How are the session IDs generated? What files are responsible for creating this session?
[/quote]

Link to comment
Share on other sites

[quote name='Archon Neo' date='10 August 2009 - 01:40 PM' timestamp='1249926010' post='1841396']
I'm still curious about the question I asked which is copied below.
[/quote]

Not that I know why it really matters, but...

[code]$sess_id = md5( uniqid( microtime() ) );[/code]

admin/applications/core/modules_admin/login/manualResolver.php

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...