81–90 of 131 posts
"We've found 99,841 code results" Someone should write a script that automatically raises an issues for each line and each project, it's probably possible, but I'm chronically lazy.
This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.
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
Earlier 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'] ...
if(!in_array(IDEMPOTENT_COMMANDS, $cmdname)) { header("HTTP/1.1 405 Method Not Allowed"); die(); } Fixed ;).
PHP with its argument ordering strikes again :)
As 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...
Side side note. This same carelessness is what caused the heart bleed bug.
As 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…
This 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.
Are there any more sophisticated parses that also find the non-obvious cases? It should be easily doable to write a tool that finds an exec() of a variable that was assigned a $GET etc
I think it's easier to just avoid exec() altogether...
How about one with root access included? https://github.com/search?q=exec+sudo+%24_GET&type=Code&ref=...
This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.