On Fri, Aug 05, 2011 at 11:36:06PM +0200, Pierre Schmitz wrote:
Hi TUs,
the AUR still handles user logins and sessions in a insecure way that can easily be exploited. The last approach to use https by default was denied a long time ago. But I hope you guys will reconsider this decision.
The only thing that was denied is enforcing HTTPs. HTTPs has been enabled by default some time ago [1], [2], [3], [4]. It's just not live yet. There will be another AUR release, soon, though.
To prevent session hijacking, mtm attacks or whatnot I'd recommend the following: * Redirect all http traffic to https by default
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
* Set session.cookie_secure = 1 in your php.ini * If you use setcookie() make sure to set the secure parameter to true
See above.
* If you don't require any javascript to access your session data it's also a good idea to set all cookie to httponly (again via php.ini and if you use setcookie() directly)
That kind of makes sense :)
The optional https access as we have now wont work here. Even if you never forget to add the s to http when you login session data is also transferred via http. So once you click a non-https link to the AUR it would be possible for an attacker to hijack your session.
That is kind of fixed in Git (again, check [1], [2], [3] and [4]). [1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137