Please don't take this discussion off-list. You need to hit the "Reply
to all" button in your Mozilla mailer.
Hans Wolters wrote:
Hans Wolters wrote:
Matt,
But you still need to see the session-id to be able to hijack the
session, and for that you need to see someones desktop.
Once you can trigger someone to visit another site where you can tail
the logfiles you have the session id in some cases.
But if there aren't any such vulnerabilities (that are known) in the
current powerboard code this isn't a bugreport at all. You're simply
stating the vector for a sometime-in-the-future attack exploiting a yet
unknown vulnerability, which is a waste of time since anybody with half
a brain can figure it out anyway.
If, on the other
hand, you can guess session-id's in a reasonable timeframe (incremental
ID's, for example) and you don't care which session you steal then this
might be a real vulnerability, except that it also uses originating IP,
which you can't know if you're guessing the session id.
It's not guessing...
Until you find the bug where you can post the session-id somewhere where
you can get your hands on it you're reduced to guessing.
This is not so different from phishing scams. If you can get someone to
enter his/her username and password on your site you'll own their
account too.
If Powerboard can be duped into including the session-id in a link to
some other site then it is a real vulnerability.
Like I stated before. Once you can insert js in the board that will visit
another site then he does have a problem if transparent sessions are being
used.
Prove that "once" is now and you have a valid bug-report. Otherwise this
is just noise.
As for hiding the session id, in certain situations it will keep
showing up not matter what you do. Popups, javascript, etc.. You must
be absolutely sure this will not take place.
I think that's what he meant by "hiding the session-id".
The board has been having issues with XSS, he can't be sure this isn't
possible in future versions.
So? Apache has had pretty much every sort of exploitable vulnerability
possible to create with a web-server written in C (which is quite a
few). There's no guarantee it won't happen again, but there aren't any
known bugs now, so we don't file bug-reports against it.
One last thing, you might be right when you state that I do not know
how the board works, however, I do not need to know since the session
hijacking itself reveals how it works, you are not checking enough in
certain situations.
What do you suggest more to check? session-id and originating IP are the
only two variables available for authentication, unless you send the
username and password every time (http BasicAuth).
There has been a lot of discussion about this. It could be partly done by
generating a new session id right after validating the excisting one. This
would at least save the boards problem.
If we want to be really paranoid we'd only access it over stateful
connections encrypted with AES-2048 in CBC-mode with PKE-authentication.
The question is where to draw the line. It's a stupid forum thing. Not
an online banking app.
/exon
