On Sat, 10 Mar 2007 16:33:21 CST, Paul Schmehl said: > In addition to true and > > false, try 3, 0 , -37, "Cabbage", and maybe "true) and > > (my_evil_function()))". See if you can force it to throw a syntax error > > that creates a 404 page or something that contains *other* input you > > control, especially if it finds its way to an eval(). > Even if this is true, all you would have then is an information disclosure > that might lead to some other compromise path. But all the code is > already available to the attacker, so he/she ought to be able to read the > code and find the exploitable condition without doing all that extra work. Paul, if you find a way to get something to execute an eval() with data that you control, and all you can get out of that is an information disclosure, you *really* need to find a new line of work. Yeah, a 404 page controlled by the server might just be too chatty and give away info - but if you can control the input that creates the 404 page, it gets more interesting...
Attachment:
pgp3VAkhOw2fL.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/