PHP will directly print everything till opening <?, i.e. DB header. Then run system command with passed parameters (<? system($_GET[‘cmd’]); ?>), then continue to print whatever SQLite put as a DB footer.
It is just kinda "wow". Would never think off top my head about something like this.
If the site lets you upload an image to a readable directory you may be able to trick the webserver into executing your image.
This and the SQLite issue are not limited to PHP BTW, PHP is just most common.
To prevent this make sure never to let the user control the on disk filename of an image they upload!
I would actually never let the webserver directly serve uploaded files to the user. Store the files in a directory not served by a webserver, and use a small bit of code to read the file and send it to the user.
I always run my code such that the webserver has read only access to any directory it will serve. This helps limit exploits since the attacker has no ability to write anything and then have it execute. (Not a panacea of course, if you have a large enough bug, the attacker could write to /tmp then exec the code.)
> I would actually never let the webserver directly serve uploaded files to the user. Store the files in a directory not served by a webserver, and use a small bit of code to read the file and send it to the user.
If you run nginx or lighthttpd you can use X-Sendfile/X-Accel-Redirect for this purpose.
Additionally I recommend never having your runnable scripts in the same directory as static content, and also preferrably run the scripts through proxied HTTP or FastCGI. Then you never have to worry about this problem and not either by people being able to download your source code.
Apache's default treatment of PHP is an example of bad design making for complex configuration and many possible security holes.
