How to send HTML form data

Source: Internet
Author: User
Tags html form chrome developer chrome developer tools ruby on rails csrf attack

Most of the time, the purpose of the HTML form is simply to send the data to the server, after which the server processes the data and sends a response to the user. While it may seem simple, there are a few things to keep in mind to ensure that the data being transmitted does not disrupt the server or cause problems for your users.

Where will the data go?

About client/server architecture

The entire web is based on a basic client/server architecture that can be summed up as follows:

A client (usually a Web browser) uses the HTTP protocol to send a request to the server (usually a Web server program, such as Apache, Nginx, IIS, Tomcat, and so on), while the server responds to the request with the same protocol.

On the client side, the HTML form simply provides a convenient and user-friendly way to configure the HTTP request sent to the server. This allows users to provide their own information that can be transmitted by HTTP requests.

Client: Defines how data is sent

The <form> element is able to define how its data is sent, and all of its features are designed to allow you to configure the request to be sent when the user clicks the Send button. The two most important features are action and method.

ACTION attribute

This attribute defines where the data will be sent, and its value must be a valid URL. If this attribute is not specified, the data is sent to the URL of the page containing the form.

Example

In the following example, the data is sent to http://foo.com:

    1. <form action="http://foo.com" >

Here, the data is sent to the server on which the form page is located, but it arrives at a different URL on the server:

    1. <form action="/somewhere_else" >

as follows, when you do not specify any attributes, the form data is sent to the page that contains the form:

    1. <form>

Many older pages use the following notation to indicate that the data has to be sent to the page containing the form, which is necessary at the time because the action attribute is required until HTML5. But now it's no longer necessary.

    1. <form action="#" >

Note: You can specify a URL that uses the HTTPS (secure HTTP) protocol, where the data is encrypted with the other parts of the request, even if the form itself is in an unsafe page that is accessed over HTTP. In addition, if the table unit is on a secure page and you specify an unsafe HTTP URL for the action attribute, all browsers give them a security warning every time the user wants to send the data because the data will not be encrypted at this time.

Method Properties

This attribute defines how the data is sent. The HTTP protocol provides several ways to execute a request; HTML form data can be sent in at least one way: Get and post.

To understand the difference between these two approaches, we have to look back at how HTTP works. When you want to get a resource on the web, the browser sends a request to the specified URL. An HTTP request contains two parts: a request header containing a series of global fields related to the browser function, and a request body containing the information to be processed by the server.

Get method

The browser uses the Get method to request that the server send back the specified resource: "Hey server, I want to get this resource". In this case, the browser will only send an empty request body, and because of this, if the browser uses this way, then the data sent to the server will be appended to the URL.

Example

Consider the following form:

    1. <form action="http://foo.com" method="get" >
    2. <input name="say" value="Hi" >
    3. <input name="to" value="Mom" >
    4. <button>send my greetings</button>
    5. </form>

When you use the Get method, the HTTP request looks like this:

    1. GET/?say=hi&to=mom http/1.1
    2. Host:foo.com

Post method

The Post method is slightly different, and the browser sends this method to the server to request a response to the data in the HTTP request body: "Hey server, look at the data and send me back a proper result". If the form is sent using this method, the data is appended to the HTTP request body.

Example

Consider the following form (same as the one above):

    1. <form action="http://foo.com" method="POST" >
    2. <input name="say" value="Hi" >
    3. <input name="to" value="Mom" >
    4. <button>send my greetings</button>
    5. </form>

When using the Post method, the HTTP request looks like this:

    1. post/http/1.1
    2. Host:foo.com
    3. content-type:application/x-www-form-urlencoded
    4. Content-length:13
    5. say=hi&to=mom

The Content-length header field indicates the size of the request body, while the Content-type field identifies the type of resource destined for the server. We'll discuss these request headers later.

Of course, HTTP requests are not presented to the user (if you want to see them, you have to use tools such as Firefox's Web console or Chrome Developer tools), and only the URLs that are presented to the user are accessible. So when a GET request is used, the user will see the data in their address bar, which is not visible with the POST request. This is essential for the following reasons:

    1. If you want to send a password (or any sensitive data), do not use the Get method, otherwise the data will be unsafe to display in the Address bar.
    2. If you want to send large amounts of data, it is best to use the Post method, because some browsers limit the size of the URLs. In addition, many servers limit the length of URLs that are received.

Server-side: processing data

Whichever HTTP method you choose, the server will only receive a string and parse it, and then get the data in the form of a key/value pair list. How you access this list depends on what development platform you are based on and what kind of framework you are using. The technology you use will also determine how to handle duplicate key names, usually the last value a key name receives is preferred.

Example: Native PHP

PHP provides several global objects to handle the data. Assuming you use the Post method, the following example extracts your data directly and presents it to the user. Of course, what you do with the data depends on you, you can show it, save it in a database, send it by mail, or whatever.

    1. <?php
    2. Global variable $_post allows you to access data sent using the Post method
    3. To access data sent using the GET method, you can use the $_get
    4. $say = Htmlspecialchars ($_post[' say ');
    5. $ to= Htmlspecialchars ($_post["to");
    6. echo $say, ', $ to;

This example generates a page with the data we send. Considering the form sample data we used earlier, the output would be:

    1. Hi Mom

Example: Native python

The following example uses Python to do the same thing---present the given data on a Web page. The CGI Python package is used to process form data.

  1. #!/usr/bin/env python
  2. Import HTML
  3. Import CGI
  4. Import CGITB; Cgitb.enable () # for handling errors
  5. Print ("content-type:text/html") # Request header field, which identifies what follows is HTML
  6. Print () # blank line, indicating the end of the request header
  7. form = CGI. Fieldstorage ()
  8. Say = HTML. Escape (form["say"].value);
  9. to = HTML. Escape (form["to"].value);
  10. Print (Say, "", to )

The result is the same as before with PHP:

    1. Hi Mom

Other languages and frameworks

There are many other service-side technologies that can be used to process forms, such as Perl, Java,. Net, Ruby, and so on, and choose your favorite one. We seldom use these technologies directly, because it takes a lot of skill to pits, and we usually choose one of the many useful frameworks, which makes it easier to process the form, such as:

    • Symfony for PHP
    • Django for Python
    • Ruby on Rails for Ruby
    • Grails for Java

It is important to note that even with these frameworks, the processing of forms is not necessarily easy. But it would be better to use it at least, and it would save you a lot of time.

Special case: Sending files

A file is a special example of an HTML form, and other data is text data, and the file is generally, or is considered to be, binary data. Because HTTP is a text protocol, there are special requirements for processing binary data.

Enctype characteristics

This feature allows you to specify the value of the Content-type field in the HTTP request header, which is important because it tells the server what type of data to send. The default value is application/x-www-form-urlencoded, and the corresponding explanation is: "This form data has been encoded as a URL format."

And when you want to send a file, you have to do two things first:

    • Set the method attribute to post because the contents of the file cannot be placed in the URL parameter when using the form
    • Set the value of the Enctype attribute to Multipart/form-data so that the data is split into multiple parts, and each file appends the text associated with the form that they sent together.

Example:

    1. <form method="POST" enctype="Multipart/form-data" >
    2. <input type="file" name="MyFile" >
    3. <button>send the File</button>
    4. </form>

Note: Some browsers support the multiple feature of the <input> element to allow an INPUT element to send multiple files. As for how the server will handle these files, it depends on what technology it uses. As mentioned earlier, the use of frames can make your life easier ~

Warning: To prevent abuse, many servers set a size limit on file and HTTP requests. Therefore, it is a good idea to check this limit with the server administrator before sending the file.

Safety-related

Every time you send data to the server, you have to consider security issues. The HTML form is one of the primary attack vectors for the server, but the source of the harm is not the HTML form itself, but how the server processes the data.

Common Security issues

There are many famous security issues and how to divide them depends on what you are doing:

XSS and CSRF

Cross-site scripting attacks (XSS) and cross-site request forgery (CSRF) are the most common types of attacks that occur when you display data that is sent to users by a user.

XSS allows an attacker to inject client script onto a Web page that another user accesses. Attackers use the vulnerability of cross-site scripting to bypass access control policies, such as the same-origin policy. This kind of attack can obtain the harm effect ranging from small trouble to serious security crisis.

CSRF are much like XSS because they all start in the same way---inject client script to Web pages, but their target is different. CSRF an attacker would try to upgrade permissions to become a highly privileged user (such as a site administrator) and then perform actions that could not be performed (such as sending data to untrusted users).

XSS attacks take advantage of user trust in the Web site, while the CSRF attack leverages the trust of the site to its users.

To prevent such attacks, the data sent to the server is often verified and, if necessary, the user-provided HTML content should be handled, and the user-provided data should be processed to avoid displaying it intact. Almost all of the current frameworks, at least, implement a filter to remove <SCRIPT> from user submissions, <iframe>, <object>, which helps mitigate risk, but does not mean it will be eradicated.

SQL injection

SQL injection is a way of attacking the database execution of the target Web site. Typically an attacker sends a SQL request and expects the server to execute it (mostly when the application server wants to store the data). This has actually become one of the main attack vectors for Web sites.

The harm of this attack is very serious, small to data loss, large to the attacker through permission to upgrade access to the entire site architecture. This is indeed a very significant threat, so you should not store data that users submit without special processing (for example, mysql_real_escape_string () processing under the Php/mysql architecture).

HTTP header injection and mail injection

This attack occurs when your app constructs an HTTP header, or an email, using data entered by the user on the form. While this attack will not harm your server or affect your users, it will open the door to deeper problems such as session hijacking and phishing attacks.

All of these attacks tend to happen silently and make your server into a broiler.

Be paranoid: Never trust your users

So how do you fight these threats? This is beyond the scope of this guide, but there are a few rules that we need to keep in mind. The most important thing is to never trust your users, including yourself, and even trusted users can be hijacked.

All data that arrives at your server must be checked and processed, and should be kept, with no exceptions.

    • Filter for potentially dangerous characters. The specific characters that you want to focus on depend on the context in which you use the data, and on the server platform that you use, and all of the service-side languages provide the appropriate functionality.
    • Limit the amount of data that is passed in, allowing only the necessary.
    • Put the uploaded files in the sandbox (store them on a different server, and access them only by a different subdomain, or an entirely different domain name).

If you can follow these three rules, you should be able to avoid most of the problems, but a better way is to have a qualified third party to do the security review, do not think you can see through all the potential problems.

Conclusion

As you can see, it's easy to send form data, but it takes a lot of technology to secure an application. Front-end developers are not the kind of role that defines a data security model, although it may be possible to perform a [client-side data check] (), but the server cannot trust these checks because it does not know exactly what happened on the client.

How to send HTML form data

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.