At the beginning of the guide, we said that data filtering is the cornerstone of WEB application security in any language and on any platform. This includes verifying data input to and from the application, and good software design can help developers:
ensure that data filtering cannot be bypassed,
ensure that illegal information does not affect legal information, and
identify The source of the data.
There are various views on how to ensure that data filtering cannot be bypassed, and two of them are more general than others and provide a higher level of assurance.
Scheduling method This method is scheduled with a single PHP script (via URL). Any other operations are included using include or require when necessary. This approach generally requires that each URL be passed a separate GET variable for dispatch. This GET variable can be thought of as a more simplified design that replaces the script name. For example:
http://example.org/dispatch.php?task=print_formdispatch.php is the only root file (Document root). It allows developers to do two very important things:
implement some global security processing in dispatch.php at the beginning, and ensure that these processing cannot be bypassed.
It is easy to determine where data filtering is necessary, especially for some special-purpose control flow operations.
See the following example for further discussion of the dispatch.php script:
<?php/* Global Security Handling*/switch ($_GET['task']){case 'print_form':include '/inc/presentation/form.inc'; break;case 'process_form':$form_valid = false;include '/inc/logic/process.inc';if ($form_valid){include '/inc/presentation/end.inc';}else{include '/inc/ presentation/form.inc';}break;default:include '/inc/presentation/index.inc';break;}?>If this is the only publicly accessible PHP script, you can be sure that this program The design ensures that the initial global security processing cannot be bypassed. It also makes it easy for developers to see the control flow of specific tasks. For example, it is easy to know without browsing the entire code: when $form_valid is true, end.inc is the only one displayed to the user; since it is before process.inc is included and has just been initialized to false, it can be determined that The internal logic of process.inc will set it to true; otherwise the form will be displayed again (possibly with an associated error message).
Note that if you use a directory directive file such as index.php (instead of dispatch.php), you can use the URL address like this: http://example.org/?task=print_form .
You can also use ApacheForceType redirection or mod_rewrite to adjust the URL address: http://example.org/app/print-form .
Another way to include methods is to use a single module that is responsible for all security handling. This module is included at the front (or very front) of all public PHP scripts. Refer to the following script security.inc
<?phpswitch ($_POST['form']){case 'login':$allowed = array();$allowed[] = 'form';$allowed[] = 'username'; $allowed[] = 'password';$sent = array_keys($_POST);if ($allowed == $sent){include '/inc/logic/process.inc';}break;}?>In this case , each submitted form is considered to contain the unique verification value of form, and security.inc independently processes the data in the form that needs to be filtered. The HTML form that implements this requirement is as follows:
<form action="/receive.php" method="POST"><input type="hidden" name="form" value="login" /><p>Username: <input type="text" name="username" /></p><p>Password:<input type="password" name="password" /></p><input type="submit" /> </form>An array called $allowed is used to check which form variables are allowed. This list should be consistent before the form is processed. Process control decides what to execute, and process.inc is where the actual filtered data arrives.
Note that a better way to ensure that security.inc is always included at the beginning of every script is to use the auto_prepend_file setting.
Filtering Example Creating a whitelist is very important for data filtering. Since it's impossible to give examples for every form data you may encounter, some examples can help you get a general understanding.
The following code validates the email address:
<?php$clean = array();$email_pattern = '/^[^@s<&>]+@([-a-z0-9]+.) +[az]{2,}$/i';if (preg_match($email_pattern, $_POST['email'])){$clean['email'] = $_POST['email'];}?> below The code ensures that the content of $_POST['color'] is red, green, or blue:
<?php$clean = array();switch ($_POST['color']){case 'red':case 'green ':case 'blue':$clean['color'] = $_POST['color'];break;}?>The following code ensures that $_POST['num'] is an integer:
<?php$ clean = array();if ($_POST['num'] == strval(intval($_POST['num']))){$clean['num'] = $_POST['num'];}? >The following code ensures that $_POST['num'] is a float:
<?php$clean = array();if ($_POST['num'] == strval(floatval($_POST['num ']))){$clean['num'] = $_POST['num'];}?> Each example uses the array $clean before name conversion. This is a good practice for developers to determine if their data is potentially compromised. Never save data in $_POST or $_GET after validating it. As a developer, you should always be fully suspicious of data saved in super global arrays.
It should be added that using $clean can help to think about what has not been filtered, which is more similar to the role of a whitelist. Can improve the level of security.
If you only store validated data in $clean, the only risk in data validation is that the array element you are referencing does not exist, not unfiltered dangerous data.
Timing Once the PHP script starts executing, it means that all HTTP requests have ended. At this point, the user has no chance to send data to the script. Therefore, no data can be entered into the script (even if register_globals is turned on). This is why initializing variables is a very good practice.