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...
Exec($_GET
21–30 of 131 posts
Re: Exec($_GET
#22As 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…
On the practical side, Ruby (MRI specifically) has such a system ($SAFE), that taints certain objects (e.g. those gained by IO) and only allows you to use them in certain fashions (e.g. only after explicit handling).
It's leaky as hell, because all components have to get the marking right. Also, not all Objects have equal trust levels. Objects created due to a HTTP request (GET-Parameters) should certainly be tainted, but how about Object read through IO - do we trust out filesystem? Do we trust the database? Thats more of an architectural decision.
In the end, the problem comes down to this: you have to whitelist the world and everything you miss is an error.
Re: Exec($_GET
#23As 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…
perl and ruby have "taint" which is similar to what you describe. And yes, this can be encoded in the type system and you can also make it so the sanitization is context dependent, i.e. http://www.comp.nus.edu.sg/~prateeks/papers/csas-ccs11.pdf
PHP does to http://pecl.php.net/package/taint but I haven’t used it or the perl/ruby ones so I'm not actually sure how similar they are...
Re: Exec($_GET
#24"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.
As noted in other comment(s), there are legit uses for this.
Re: Exec($_GET
#25"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.
Well, some of them are false positives.
Re: Exec($_GET
#26Something like this might make a great feature for github — exploit code review warnings/alerts.
It would actually be a nice to build an optional warning feature into `git` itself. You could download some known common issues and the script would generate warnings if you checked in corresponding code. E.g. git add id_rsa WARNING: You may have just staged a private key. or better echo '{"password": "mypassword"}' > config.json git add config.json WARNING: You may have just staged a password.
Write git hooks and share them as "git-lint"
Re: Exec($_GET
#27Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Taint_checking
Of note is that Perl had this since at least 1998. See http://gunther.web66.com/FAQS/taintmode.html But of course we just laugh about Perl and pat ourself on our backs with our safe new languages because we clearly know much more than those anachronistic neckbeards.
But of course we just laugh about Perl and pat ourself on our backs with our safe new languages
And there is some justification for that: if those "safe new languages" are doing the type checking at compile time, that is better than only finding out you have a safety issue when you fail at run time.
Re: Exec($_GET
#28Note that most of these are intentional. pointer.jpg.php, pypwn/test.php, w3af-moth, etc.
Re: Exec($_GET
#29Are 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
Re: Exec($_GET
#30Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Taint_checking
Of note is that Perl had this since at least 1998. See http://gunther.web66.com/FAQS/taintmode.html But of course we just laugh about Perl and pat ourself on our backs with our safe new languages because we clearly know much more than those anachronistic neckbeards.
The issue I have with Perl taint checking is that data is untainted by a group match within a regexp.
It's not explicit enough and it's easy enough to find legitimate code with accidental untainting of dangerous data.
Ruby requires an explicit untaint call, and IMHO it's the right way to go.