I made some tests and seems to me that just environments where magic_quotes_gpc = 'Off' are affected (which is not default on php). When magic_quotes_gpc = On, the query that is sent to database is interpreted as: SELECT active, view FROM nuke_modules WHERE title='\' OR 1=2 /*' Which is properly slashed. But, if we do have magic_quotes_gpc = Off, it's interpreted as: SELECT active, view FROM nuke_modules WHERE title='' OR 1=2 /*' Which is exploitable. On 9/15/05, Paul Laudanski <zx@xxxxxxxxxxxxxx> wrote: > On Fri, 16 Sep 2005, Matthias Jim Knopf wrote: > > > What do you gain from that? In what way would you think your advice did > > ANYTHING GOOD? > > You did neither issue a "addslashes()" as appropriate for SQL-commands, > > nor did you explain, why a variable set by a POST or a COOKIE could be > > worse than anything you could give any URL by appending '?name=...' or > > '&name=...' (->GET vars) > > > > If you read the code and original advisory, there is filtering already in > place within the PHP-Nuke framework that monitors HTTP GETs. As such, > this 'exploit' makes of variables which should only be passed via HTTP > GETs and not POSTs nor cookies. > > Proper data sanitization for this is simply to retrieve what is expected: > > $name = $_GET['name']; > > The function you specify like http://php.net/addslashes is neither here > nor there. Why use that function for a variable in POST or cookies when > it is clearly expected to be returned via GET alone? > > Ergo: > > register_globals off ! > > -- > Paul Laudanski, Microsoft MVP Windows-Security > CastleCops(SM), http://castlecops.com > > > > ________ Information from Computer Cops, L.L.C. ________ > This message was checked by NOD32 Antivirus System for Linux Mail Server. > > part000.txt - is OK > http://castlecops.com > -- # (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
