Forumlar / Cotonti / Bugs / Archive / Several XSS security notes

I have noticed that by default Seditio uses Sessions + Cookies for security. I propose leaving Sessions mode the only available for the following reason. If authentication method is set to 1 (Cookies) or 3 (Cookies + Sessions), it puts base64-encoded authorization credentials into cookie, including the MD5 hash of the password. If someone steals a cookie with some XSS exploit, he will get not just user's current session (which will be most probably stopped with IPcheck) but also the hash of the password. Then he has a chance to brute force a collision for that hash, and use user's login and the collision of the password to log into the site. So, the solution I propose is using authmode=2 be default and removing the other methods.

Another thing is important for people on shared hosts with PHP session data stored in some commonly available folder, usually /tmp. In this case your neighbors can steal session data from your users. The protection from this is overloading PHP's sessions to use local file storage or MySQL database (recommended). The drawback is that with MySQL-driven sessions it will produce 1-3 extra queries per request. The solution I would propose is not using cheap shared hosts with commonly available session data. But if this problem appears for many Cotonti users, we will have to provide optional MySQL-driven sessions for them.

The third thing is related to AJAX and server-side part of it, in which we disable Anti-XSS protection (sed_check_xp()). In fact, it is not Cross Site Scripting (XSS) what sed_check_xp()/sed_check_xg() does, but Cross Site Request Forgery (CSRF/XSRF). None of our currently existing plugins are vulnerable because they don't insert any essential data into the database (although, they can be used for a non-persistent XSS attack). But still it's a potential flaw in future, so I suppose we need to bring those checks back even for AJAX mode and edit client-side scripts to support it.

I see no reason to remove any modes. You can simply double MD5 the password in session or cookie, or even salt+md5 it or something.

IP Sec, stops any stealing, unless the person is smart enough to spoof ip's. And well thats a risk for any system really.

How about this for a proposal. There can be some sort of unique value that has nothing to do with password. Say md5($sys['now'].rand(0, 1000)); On login, its stored in a row on the user, thats used for unique identification, instead of throwing the password in the cookie. On logout the field is cleared. And say on a new login, the field is changed, with a new value.

This would remove any sort of password in session or cookie, solving the problem. and the salt for the time, can be soemthign more complex. No one would ever be able to just randomly fill in cookies to steal, as witht he salt it would be impossible to get the same 2, as the time changes as well.