0

What is the earliest place a hacker can break out of a GET or POST method in a PHP submission?

For example,

If the first lines of my processing form are:

$id= $_GET['id'];
$post_id= $_POST['post_id'];

can they already insert some malicious code that would execute when the variables were set equal to the unfiltered GETs and POSTs?

Thanks

Harvard
  • 29
  • 1
  • 7
  • 5
    No. It becomes a problem when you try to *use* those variables and they contain malicious input. – John Conde Mar 28 '14 at 18:13
  • What John said. Any time you receive input from a user you should validate that it matches the exact format of the input you were expecting, sanitize the input, and reject anything that doesn't conform to your specifications. That said, you should still use things like parameterized queries to protect against common things like SQL injection. – Sammitch Mar 28 '14 at 18:17
  • so would this sequence be "perfectly" safe: get variable unfiltered-> prepared statement store in db-> get form db and display in html using htmlspecialchars() or htmlentities() – Harvard Mar 28 '14 at 18:19
  • @user3462240 Pretty much. Remember though if you're outputting to JavaScript or JSON that you should be using hex entity encoding (e.g. `\x22`). – SilverlightFox Mar 29 '14 at 10:10

3 Answers3

2

As long as you don't do something stupid like eval() them or directly put those into a mysql query, it's fine.

They're mostly just strings, so there's no direct danger (if you meant something like viruses on windows).

Here's some possible "malicious" things you can get:

  • SQL injection attack
    (breaking your query to do something bad, like dropping a table)
  • PHP injection attack
    (hacker hoping you will eval it, or write it to a .php file and later execute that)
  • HTML/JavaScript injection attack
    (if you print it on a page, so it can run bad JavaScript or break layout - imagine </html> in the middle of your article)
  • Forged form fields
    (CSRF etc - usually avoided using captcha or some security tokens)
MightyPork
  • 18,270
  • 10
  • 79
  • 133
  • 1
    "If eval() is the answer, you're almost certainly asking the wrong question." -- Rasmus Lerdorf, BDFL of PHP – Sammitch Mar 28 '14 at 18:18
  • There is a common use-case for eval(): online PHP editors, for live coding. That's the reason why they are sandboxed. – Jens A. Koch Mar 28 '14 at 18:36
2
  1. The earliest place to break out, is, when the incoming GET or POST data is interpreted. Might that be directly, eval($_GET['foo']);, or, indirect, after an assignment $a = $_GET['foo']; eval($a);.
  2. The assignment operator "=" itself doesn't trigger an execution or interpretation of the assigned content. You might consider it being safe.
  3. You might think of "=" as "equal to". Don't do that. By using the assignment operator the left operand gets set to the value of the expression on the right (not "equal to", but "gets set to").
  4. $a = $_GET['a']; $a(); this is actually the earliest place of an exec i can think of

Ok, i should stop being a nitpicker.

My suggestions are:

Workflow

  1. GET/POST = untrusted variable content
  2. validate, sanitize
  3. use in prepared statement
  4. store in db
  5. get form db
  6. escape
  7. display

Do not trust incoming data. Validate it.

Use $_dirty['foo'] = $_GET['foo'] and then $foo = validate_foo($_dirty['foo']);

Use PHP's filter_input(), filter_var() or your own validation functions.

You can also rely on PHP filter_input() function, instead of writing your own validate_foo() logic. Read http://www.php.net/manual/en/function.filter-input.php

$search = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_SPECIAL_CHARS);

Example

The example validates an incoming $_GET['id']. The value should only be considered valid, if it is an integer and in a certain range.

$range = array('options'=>array('default'=>1, 'min_range'=>0, 'max_range'=>10));
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT, $range);

Database: use PDO & preparedStatements & bindValue

http://www.php.net/manual/en/pdostatement.bindvalue.php

Jens A. Koch
  • 39,862
  • 13
  • 113
  • 141
1

No, processing external input values within PHP doesn’t pose any risk as long as you don’t use the data in some interpreted language, which distinguishes between code and data.

Because in that case you may be vulnerable to injection. And by interpreted language I mean any language like HTML (Cross-Site Scripting), SQL (SQL Injection), PHP (Code Injection), shell commands (Command Injection), etc.

So if you use external data in any other way, make sure to process it properly.

Gumbo
  • 643,351
  • 109
  • 780
  • 844