Is using extract($_POST) insecure?

后端 未结 5 1470
半阙折子戏
半阙折子戏 2021-01-20 17:03

Is using extract($_POST) insecure? If yes then what can I do about this?

相关标签:
5条回答
  • 2021-01-20 17:40

    Using extract($_POST) is insecure, as others have stated. You asked what you could do about making extract($_POST) secure, specifically to avoid constantly referencing the $_POST array.

    The Literal Answer

    You asked about using extract($_POST) securely. It is somewhat safe to use as the first line of your script, before any local variables have been defined, or with EXTR_PREFIX_ALL and a prefix. In both cases however, you are making a risky gamble, that you will never accidentally introduce a security hole via typo anywhere in that variable scope. Global scope is exceptionally difficult to verify. Because all programmers make typos and the inconvenience is minimal, most programmers strongly encourage never extract()ing untrusted content, regardless of limited scope, prefixes, etc.

    The Correct Answer

    $_POSTed data is untrusted and insecure. You never know what it might contain - or if it will even be set. It is useful to think of $_POST as "tainted" data which must be "cleaned" before assigning it to a local variable. As a result, you should be able to minimize your typing of "$_POST" by validating the input as you assign it to local variables. PHP 5.2 and up make this easier with the filter_input() and filter_var() functions with the validation filters.

    As an aside, you should always validate your inputs and sanitize your outputs. If you instead sanitize your inputs you can run into problems displaying them in different contexts (ie, a non-HTML logger, printing to a terminal). If you don't sanitize your outputs, you run into XSS, SQL Injection, etc.

    The rule of thumb encouraged by this mindset is to treat all data entering your system from another you don't control as "tainted", untrustworthy - you probably don't control the system running the web browser, unless developing for a LAN. Further, "defense in depth" encourages treating even trusted systems as compromisable (it happens), making this most generally best practices for programmers.

    0 讨论(0)
  • 2021-01-20 17:40

    It is always better simply read values from $_POSTand do something with them instead of just exposing them as variables and risking overriding some of yours...

    0 讨论(0)
  • 2021-01-20 17:48

    Yes it is insecure. Any one can override your local variables (for example $password or $access_level).

    I recommend declaring and assigning your own local variables like this:

    $var1 = isset($_POST['field_1'])?$_POST['field_1']:null;
    $var2 = isset($_POST['field_2'])?$_POST['field_2']:null;
    $var3 = isset($_POST['field_3'])?$_POST['field_3']:null;
    
    0 讨论(0)
  • 2021-01-20 17:51

    Yes it is. It is the same thing that register_globals was. It means that if someone inject a value with the name "my_name" the variable "my_name" would exist. And if it exists, it can bring some garbage or security issue in your script if somewhere you use the variable $my_name

    0 讨论(0)
  • 2021-01-20 17:57

    From the php documentation:

    Do not use extract() on untrusted data, like user input (i.e. $_GET, $_FILES, etc.). If you do, for example if you want to run old code that relies on register_globals temporarily, make sure you use one of the non-overwriting extract_type values such as EXTR_SKIP and be aware that you should extract in the same order that's defined in variables_order within the php.ini.

    The recommended practice is to use $_POST[<varname>] directly, so that users of your site can not set variables that should be 'safe'

    0 讨论(0)
提交回复
热议问题