Meet his brother https://github.com/search?q=eval%28%24_GET&type=Code&ref=sea... (eval($_GET
Also relevant - https://github.com/search?q=mysql+%24_GET&type=Code&ref=sear...
The names of the files alone suggests many of these are quite deliberate.
Exec($_GET
31–40 of 131 posts
Re: Exec($_GET
#32Directly passing user data to the command line is highly dangerous.It allows an attacker to execute arbitrary commands on the command line [0]. escapehellarg [1] has to be used to Escape a string to be used as a shell argument [0] http://gcattani.co.vu/2013/03/a-tale-of-a-php-shell/ [1] http://php.net/manual/en/function.escapeshellarg.php
Directly doing anything with attacker supplied data is generally a no-no.
Everything that may come from a user must be filtered, escaped or generally treated as hostile.
As an example on an IRC channel someone once made their chan bot log the channel to the web, all it took was pasting javascript into an IRC window, and typing "LOL look at this! http://stupidbot.com/ircweblog". Channel pwned.
Re: Exec($_GET
#33As a theoretical aside, I wonder if it'd be possible to have a typesystem based solution to these kinds of problems - where variables coming from the user (or from another program) are considered 'unsafe' and the compiler refuses to let exec() or whatever use them until they've been through a cleaner/tester of some kind... (OK, I know PHP doesn't have a compiler as such - but a static checker of some kind could work…
https://en.wikipedia.org/wiki/Taint_checking
Ah, "Taint" was the missing magic word I couldn't figure out to aid my google-fu (well, duckduckgofu...). Thanks for that - there is a lot of interesting stuff out there. :-)
Re: Exec($_GET
#34As a theoretical aside, I wonder if it'd be possible to have a typesystem based solution to these kinds of problems - where variables coming from the user (or from another program) are considered 'unsafe' and the compiler refuses to let exec() or whatever use them until they've been through a cleaner/tester of some kind... (OK, I know PHP doesn't have a compiler as such - but a static checker of some kind could work…
There is Argos[0] which is a research project at my university, it's a qemu-based emulator that tracks tainted data coming from the network and other compromised sources and makes sure it doesn't tamper with memory or filesystem locations than it shouldn't. It's a bit overkill,especially for this, but it's interesting to check out :)
Re: Exec($_GET
#35As a theoretical aside, I wonder if it'd be possible to have a typesystem based solution to these kinds of problems - where variables coming from the user (or from another program) are considered 'unsafe' and the compiler refuses to let exec() or whatever use them until they've been through a cleaner/tester of some kind... (OK, I know PHP doesn't have a compiler as such - but a static checker of some kind could work…
Phantom types can help with this. F#'s unit of measurement does something similar for numbers.
Re: Exec($_GET
#36As a side note, this is how many SQL injection attacks happen too. You almost never want unfiltered user input to directly interact with your system. A while back, I did an episode on how SQL injection can lead to code execution by using unfiltered user input on a LAMP stack. See it @ http://sysadmincasts.com/episodes/21-anatomy-of-a-sql-inject...
Re: Exec($_GET
#37I found a legit repo for this code https://github.com/andresriancho/w3af-moth "A set of vulnerable PHP scripts used to test w3af's vulnerability detection features."
Which points out that the context has to considered as well. E.g., if it's a personal intranet or password protected page, this may not be vulnerability.
Re: Exec($_GET
#38Thats a little more than concerning!
Re: Exec($_GET
#39Meet his brother https://github.com/search?q=eval%28%24_GET&type=Code&ref=sea... (eval($_GET
most of those are demonstrations of the vulnerability
Re: Exec($_GET
#40This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.