Security drawbacks and proposals
Trustmaster |
|
---|---|
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. May the Source be with you!
|