PHP Security-forms and data

In typical PHP application development, most of the logic involves data processing tasks, such as checking whether a user has successfully logged on, adding commodities to the shopping cart, and processing credit card transactions. & Amp; nbsp...

Forms and data

In typical PHP application development, most of the logic involves data processing tasks, such as checking whether the user has successfully logged on, adding products to the shopping cart, and processing credit card transactions.

Data may come from countless sources. as a security-aware developer, you need simple and reliable data in two types:

L filtered data

L contaminated data

All trusted data set by yourself can be considered as filtered data. The data you set yourself is any hard-coded data, such as the following email address data:

  $email = 'chris@example.org';

The e-mail address chris@example.org above does not come from any remote data source. Obviously, it is trustworthy. Any data from a remote data source is input, and all input data is contaminated. The data must be filtered before use.

Contaminated data refers to all data that cannot be guaranteed to be valid, such as forms submitted by users, emails received from the email server, and xml documents sent from other web applications. In the previous example, $ email is a variable that contains filtered data. Data is the key, not the variable. A variable is only a data container. it is often overwritten by contaminated data as the program executes:

  $email = $_POST['email'];

Of course, this is why $ email is called a variable. if you do not want data to change, you can use constants instead:

CODE:

define('EMAIL', 'chris@example.org');

If the preceding statement is used for definition, e-mail is a constant with a value of chris@example.org throughout the script, it won't change even when you try to assign a value again (usually accidentally ). For example, the following code output is a chris@example.org (an attempt to redefine a constant will cause an error message at the level of Notice ).

CODE:

Tips

For more information about constants, visit #

As discussed in Chapter 1, register_globals makes it very difficult to determine the source of a variable such as $ email. All data from external data sources should be considered contaminated before being proved legal.

Although a user can send data in multiple ways, most applications perform the most important operations based on the results of form submission. Another attacker only needs to manipulate and submit data (the basis for your application to perform operations, the form makes it easy for them to open up the design scheme of your application and the data you need. This is why form processing is the first concern for all Web application security issues.

One user can transmit data to your application in three ways:

L URL (such as GET data)

L use the content of a request (such as The POST data method)

L HTTP header information (such as Cookie)

Because the HTTP header information is not directly related to form processing, it is not discussed in this chapter. In general, the suspicion of GET and POST data can be inferred to all input, including HTTP header information.

Form data is transmitted through GET or POST requests. When you create an HTML form, you must specify the request method in the method attribute of the form tag:

If I enter the user name chris and password mypass, after the form is submitted, I will go to the page where the URL is. The simplest valid HTTP/1.1 request information for this URL is as follows:

CODE:

 GET /login.php?username=chris&password=mypassHTTP/1.1  Host: example.org

It is not necessary to use an HTML form to request this URL. In fact, using the GET request of an HTML form to send data is no different from directly clicking a link.

Remember that if you try to use a Request string in the action in the form submitted by GET, it will be replaced by the data in the form.

In addition, if you specify an invalid request method or the request method attribute is not written, the browser submits data in GET mode by default.

To describe the POST request method, you can only make a simple change to the previous example. consider changing the GET request method to POST:

CODE:

If I specify the user name chris and password mypass again, after submitting the form, I will go to the # page. The form data is inside the request rather than a URL request string. The simplest valid HTTP/1.1 request information for this method is as follows:

CODE:

POST /login.php HTTP/1.1  Host: example.org  Content-Type: application/x-www-form-urlencoded  Content-Length: 30   username=chris&password=mypass

Now you can see the main way users provide data to your applications. In the following section, we will discuss how attackers use your forms and URLs as gaps in your application.

The above is the PHP Security-form and data content. For more information, see PHP Chinese website (www.php1.cn )!