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. > 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> >> I do really believe it deservers to be considered as critical; >> although if you (or anyone else from the team) really insists I would >> not accept anything below important. Think about web hosting services >> where they share the same domain but use a different subdomain, it is >> possible for one site to inject cookies that will affect the others. > > As I said if they allow such dangerous practises as dinamic change of > php.ini values that's not wordpress' fault. Invalid argument for both reasons: a) there's no such directive in php.ini b) if there were such a directive, it would have a security exception just like for magic_quotes, safe_mode, and other b0rken by design options. > You can exploit almost every web application overwriting it's cookies! The problem here is that a) they have predictable names, b) they are not just storing data but actually making the script do something it was not requested to do (cookies, just like GET and POST request methods, have some specific purpose. $_REQUEST should only be used where it doesn't matter at all what kind of request it is, IOW: never). > > Cheers. > > Andrea. > Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net J. Paul Getty - "The meek shall inherit the Earth, but not its mineral rights." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
