Il giorno ven, 07/11/2008 alle 15.36 -0600, Raphael Geissert ha scritto: > 2008/11/7 Andrea De Iacovo <[EMAIL PROTECTED]>: > >> Hi, > >> > >> It is not just about the DoS (because as I demonstrated, there are > >> other possible attacks). > >> The whole point is that wordpress' (ab)use of $_REQUEST is leading to > >> more and more possible attacks (as I also demonstrated by showing how > >> etch's version is less worst than lenny's). > > > > All attacks can be done only by setting malicious cookies. > > With a standard apache/php configuration, cookies can only be set for > > the current subdomain (foo.bar.com) and not for the entire domain > > (.bar.com). > > Being one of the folks working on the php5 package lately I don't know > of any such apache or php configuration that restricts the domain of a > cookie. PHP has session.cookie_domain, but it does only work for the > session cookies of PHP's built-in session manager.
Ok I was misinterpreting a man page. > > > However you can act on the php.ini changing the domain value with a php > > script but I don't think that's wordpress' fault if the server > > administrator allows you to dinamically change such configuration with a > > simple script! 99% of the public hoster which give you a > > yourname.hoster.com do not allow you to change the domain value for the > > cookies and so should people do if hosting multiple websites with teir > > debian machine. > > > > You can also set cookies via javascript code, e.g. > <script>document.cookie = "GLOBALS=1;domain=.domain.tld"; </script> ok that's true. So let's see what we have: 1. $_REQUEST references are widely used in wordpress. 2. the standard EGPCS makes cookies overwrite GET and POST values in $_REQUEST 3. such values are used in "dangerous" cases (such as user deletion or logout after redirection). 4. "grave" data loss (user, post, comments deletion) could be avoided not logging in as administrator (but only as a user with some privileges) 5. the issue is related to wordpress only and does not influence other parts of the system 6. we can try to prepare a workaround while we wait an officile fix from upstream: maybe I could implement a function to check out if dangerous cookies are present and stop any other operation until those cookies are not removed. So I agree that I absolutely have to solve the bug(s) but I keep thinking it should be set as important instead of grave. Thank you very much for all your help with the issue. If you need more information just ask me, please. Cheers. Andrea
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente
