This needs to be quoted to return decent results:
https://github.com/search?q=%22exec%28%24_GET%22&type=Code&r...
Otherwise there are way too many false positives. Still, 188 results is pretty awful.
Exec($_GET
91–100 of 131 posts
Re: Exec($_GET
#92Re: Exec($_GET
#93This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.
I think the problem here is the fact that tainted variables (user input) are used to execute shell commands. it doesn't matter if that's $_POST or $_GET, both of these are user input and therefore these are huge vulnerabilities.
I think he is indeed being sarcastic.
Re: Exec($_GET
#94I already have a thing called "all seeing eye" that picks up on things like this on a pre-commit script in SVN and tells people to go away if they do something stupid. It's done some wonderful work so far.
Re: Exec($_GET
#95Re: Exec($_GET
#96Earlier quoted context omitted.
It depends by the command, echo is idempotent for example. There should be some checking like $cmdname = split(' ', $_GET['command']); if(!in_array(IDEMPOTENT_COMMANDS, $cmdname)) echo ' Your request is not guaranteed to be idempotent. Please use a POST. '; else exec($_GET['command'] ...
echo is idempotent As a simple call, yes. But there are many shell tricks (redirection, command substitution, process substitution) that can make an echo call have significant side effects - so if you were daft enough to be considering this you'd need to do much more checking before submitting the provided instruction to your shell, and those checks would need to know which shell you were targeting (in fact you'd pro…
Yes, though if a shell is chosen and the command is shell escaped you are good to go
Re: Exec($_GET
#97As 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…
Here's one approach: http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti...
Different languages (SQL, JS, HTML, Shell, Plaintext, etc.) are treated as different types. Language-specific functions only accept arguments of the relevant type (eg. shell_exec takes Shell, db_query takes SQL, etc.). User input is Plaintext (usually; sometimes it might be something more specific like BASE64).
Different languages can't be combined (eg. SQL can't be concatenated with Plaintext), but they can be converted down to Plaintext and Plaintext can be converted to any language via escaping functions. This avoids injection attacks, since the only way to please the type-checker is by escaping properly.
Re: Exec($_GET
#98Earlier quoted context omitted.
if(!in_array(IDEMPOTENT_COMMANDS, $cmdname)) { header("HTTP/1.1 405 Method Not Allowed"); die(); } Fixed ;).
in_array(needle, haystack) PHP with its argument ordering strikes again :)
... actually,
if(!IDEMPOTENT_COMMANDS[$cmdname]) { ...
Re: Exec($_GET
#99Horrible.. Been sending 2 security bug reports so far.
Re: Exec($_GET
#100My fav: $device = $_GET['device']; $state = $_GET['state']; exec( "sudo ./send " . $device . " " . $state ); EDIT: it is for home automation, but also appears to be a CS class group project.
I really, really, really want to post on their issue tracker, but maybe I shouldn't. There's no guarantee the person grading the project will care, either.
You should.
But be factual. No point in bringing the attitude.