@mikem @tkopecek what do you think?

Can we clarify the issue rather than just linking to a doc?

It is a question if we want to detect potential session hi-jacking (e.g. IP changed during the session, some cookies present before the login, etc.) Some of the detections could be expensive, so maybe test them only in case user has some permissions.

I've gone through the code and:
a) changing IP is covered (select sessions is based also on ip)
b) bruteforcing doesn't make sense to detect. session-key is random, we also allow multiple sessions per IP, so we can't know if it is rogue code, or if it is just non-optimal application or NAT.
c) checking useragent/location could have some use but I don't think any attacker would be so dumb to change these if he can already steal session-key/IP

d) maybe it would be better to leave this attack type detection on external module (e.g. ModSecurity) which can also handle additional tasks, configurable logging, etc.

@mikem ?

a) changing IP is covered (select sessions is based also on ip)

Yup. Baked in from the beginning

b) bruteforcing doesn't make sense to detect. session-key is random, we also allow multiple sessions per IP, so we can't know if it is rogue code, or if it is just non-optimal application or NAT.

It's worth considering before we dismiss it. It's a random string of 20 letters (upper and lower) and digits, so about 10^35 possible combinations. It would indeed take a very long time to brute force.

On the flip side, part of the point of detection is to know you are being attacked, even the the attack is unsuccessful.

c) checking useragent/location could have some use but I don't think any attacker would be so dumb to change these if he can already steal session-key/IP

A good point, though often security is about making things harder (since you can never truly make them impossible). This hypothetically wouldn't be too hard to add in the Koji session code. If so, we'd probably want to make it configurable (e.g. like CheckClientIP).

It's also worth noting that we bind our sessions to another property -- callnum. This is actually quite hard to fake if the original client is still using the session.

d) maybe it would be better to leave this attack type detection on external module (e.g. ModSecurity) which can also handle additional tasks, configurable logging, etc.

Using mod_security is an interesting thought, though it might be better suited to the web ui than the hub.

PR 3557

Commit 69b0bad fixes this issue

Commit fea12ba fixes this issue