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