Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exec($_GET

github.com

Post reply on HN
Print view View original

51–60 of 131 posts

Re: Exec($_GET

#51

Post by robbles »

elwell wrote: post #37
mikeytown2 wrote: post #9

I 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.

It would still be vulnerable to a CSRF attack. The attacker can just get a logged-in user to launch their exploit, through a vulnerable site they frequent or even a link or image in an email.

Re: Exec($_GET

#52

Post by LeonM »

xikrib wrote: post #48
DanOWar wrote: post #47

Example from the Github search: How to abuse: $_GET['name'] = "/dev/null; rm -rf /; echo ";

need root access, no?

Thats not the point. Of course "rm -rf /" won't work, but what about downloading and installing a backdoor? Or modifying the website scripts itself? Or dumping a database? Or...

Removing all the files from a filesystem is something only a script kiddy would do, and it's probably a "best case scenario" for the owner of the server, because the impact of that is relatively small (just re-install the server and restore the backups). But once the attacker starts injecting mallware, stealing customer information (credit card numbers anyone?) or anything else nasty they can think of that they would benefit from, then you are in a whole lot more trouble...

Re: Exec($_GET

#54

Post by skriticos2 »

xikrib wrote: post #48
DanOWar wrote: post #47

Example from the Github search: How to abuse: $_GET['name'] = "/dev/null; rm -rf /; echo ";

need root access, no?

True, but once you have you can start executing any user commands. So you do a (without the index file you can just view the file as plain text, which probably contains the database username and password. Then you can go on and download a database dump. The attacker probably does not give a damn about root in this scenario.

Re: Exec($_GET

#55

Post by RutZap »

ephemeralgomi wrote: post #40

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.

Re: Exec($_GET

#56

Post by sprobertson »

catkin wrote: post #43
chriskottom wrote: post #42

88,846 PHP 1,420 HTML+ERB 1,177 JavaScript 1,128 HTML 423 Ruby 250 XML 160 Markdown 117 Emacs Lisp 91 INI 65 Perl

Not actually so surprising considering `$_GET` is a PHP superglobal.

Though I'm surprised how many aren't PHP, for example all the Ruby repos...

Edit: ah, most of those are Metasploit scripts.

Re: Exec($_GET

#57

Post by saurik »

RutZap wrote: post #55
ephemeralgomi wrote: post #40

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.

"That's the joke."

Re: Exec($_GET

#58

Post by masklinn »

RutZap wrote: post #55
ephemeralgomi wrote: post #40

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.

I'm pretty sure GP was being sarcastic.

Re: Exec($_GET

#59

Post by huseyinkeles »

RutZap wrote: post #55
ephemeralgomi wrote: post #40

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.

I think he is being sarcastic.

Re: Exec($_GET

#60

Post by zoomerang »

deckiedan wrote: post #13

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…

It's pretty easy to implement such a feature in any strongly typed language, but sadly few framework/libraries/stacks actually do it.
Post reply on HN