[Reprint] Study Notes HTTP protocol

Let's take a simple look at the HTTP protocol and CGI program processing process. For many new friends, the HTTP protocol has been listened to for countless times, however, we do not know much about the process. Here we will not talk about the principles of the HTTP protocol. For more information, see rfc1945. In fact, as long as we can clearly understand the work process, we can use it to do a lot of things. This article is intended for beginners who prefer to study port 80 security and start CGI learning.
HTTP is a relatively simple protocol that defines the session process between the client (usually through a browser) and the WWW server. Now let's take a look at the brief description of this session process: the customer opens the socket with the server, usually using port 80. The server then sends the request line, the request title, and finally the request blank line. Customer requests are usually request documents, which can be text files, images or programs. The server accepts the request, searches for the requested data, and then responds to the query result. If the above process is a CGI program, the server will execute this program and lose the execution result to the client. If you do not understand the CGI program, you can understand the CGI program in this way. It can be written in many languages, as long as it can complete a task: analyze the data in the customer request line, then, make a response on behalf of the server! What we want to discuss today is to understand this problem from the client perspective. First, let's look at a standard client request format:
Request Method text block address http/version
Request title: data 1
................
Request title: Data n
Blank line
In the preceding format, the first line is required. It specifies the request's document block, also known as the request header. The following table lists multiple request headers. The last blank line indicates termination. There is another problem here. If the request method is post, additional data can be sent after the blank row. A very important issue here is the request method. No matter whether we are new to CGI or those who like Web security, they are all necessary knowledge.
This is a typical request header:
GET/BBS/login. asp http/ 1.0
GET is a request method. /Bbs/login. asp is the document block address (URI), which is part of the URL. HTTP/1.0 is the version number of the http protocol. This method of request is based on the connection established with the server. The complete URL can be like this: http://www.target.com/bbs/login.asp. Three request methods are defined in the http 1.0 Protocol: GET, POST, and HEAD. Http 1.1 adds some more, such as PUT, DELETE, OPTIONS, and TRACE. More and more servers now support these methods. The following describes common methods.
GET is the most common method for browser requests to the server. The URL we send in the browser is a GET request. Of course, we can also use programs such as netcat and webget. We sometimes see some examples of requests mentioned by hacker experts in the article. It may be hard for new friends to understand, for example:
Http://www.target.com/bbsxp165/bbsxp/searc...password)> 1)
This is a very complex GET request,/searchok. asp? It is the request for this asp file, followed by the data to be transmitted to this program, which is fixed according to webpage interaction. After the Server accepts this request, the data will be placed in the environment variable QUERY_STRING. Data is usually a number of data name/data value pairs. No & is used to separate data names/values. In the example submission, forumid = () refers to an SQL statement. This is because of the SQL injection vulnerability, which is certainly not covered in our discussion. In addition, the data in the GET request cannot exceed a specific length, such as 2000 bytes.
The POST method is also used to transmit data, but unlike GET, when using POST, the data is not transmitted after the URI, but as an independent row, at this time, you must also send a Content_length title to indicate the Data Length, followed by a blank row, and then the actual transmitted data. Webpage forms are usually transmitted using POST. Here we will refer to two common submission methods for security personnel, which are usually used when hackers discover a webpage or cgi program vulnerability and construct a special request:
1. Script implementation
............
$ Socket = IO: Socket: INET-> new (PeerAddr => $ host, PeerPort => $ port, Proto => "tcp", Type => SOCK_STREAM) or die "can't connect to the host \ n ";
Print $ socket "POST/$ B HTTP/1.1 \ r \ n ";
Print $ socket "Host: $ host \ r \ n ";
Print $ socket "Content-Type: text/xml \ r \ n ";
Print $ socket "Content-length: $ length \ r \ n ";
Print $ socket "$ data \ r \ n ";
$ Socket-> recv ($ rbuf, 500 );
Close ($ socket );
..........
The above is the main part of POST submission of the perl program. For example, an overflow program, the key lies in the Construction of $ B (URI) and $ data!
2. Use nc to submit
Create a hack.txt file and enter the following content:
POST/cgi-bin/websendmail HTTP/1.0
Content-length: xxx (shocould be replaced with the actual length of
String passed to the server, in this case xxx = 90)
Explorer =; mail + your_address \ @ somewhere.org
Then use nc to request
Nc http://www.victim.com/80 This completes the submission of a post. Of course there are many other methods to implement this submission. Here are just two convenient methods I think.
The HEAD method and GET syntax are the same. If the HEAD method is used for a request, the server returns only the response title, instead of being blocked by the request, the HEAD method is commonly used in some search engines. Of course, many of our cgi scanning software uses this method for requests.
The following method is a standard of http 1.1, which is rarely used currently. A brief introduction to the definition is provided.
PUT stores the files submitted by the customer on the server URI.
DELETE is used to request the server to DELETE the specified URI.
OPTIONS can request information about common OPTIONS available for the specified URI
The TRACE request server blocks the returned files without changes and is mainly used for debugging.
When it comes to requests, let's talk about the server's response. Its standard format is as follows:
HTTP/version status code message
Response title: data 1
.............
Response title: Data N
Blank line
Customer-submitted document
Let's look at an example:
Nc http://www.victim.com/80
GET/index.html
HTTP/1.1 400 Bad Request
Date: Tue, 14 May 2002 07:03:02 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset = iso-8859-1

127
...............
There are many predefined response status codes, usually the default server setting, which is a three-digit number starting with 1, 2, 4, 5.
1xx is mainly used for debugging and experiment purposes
2xx indicates that the request is successful.
3xx indicates that the requested uri has multiple options or has been moved.
4xx 400 indicates a syntax error exists in the request line, and 404 indicates that the text block does not exist.
5xx indicates an internal server error
Sometimes, you may ignore the usage of these things. In fact, sometimes their functions are not small. For example, if we have no tools at hand, how can we know whether ida is available on the server, for printf and other mappings, we can make this request: http://www.victim.com/developer.ida. If a 500 internal server error occurs, I think the problem is clear.
Since we have all said so much nonsense, I would like to give you some tips on URL encoding, data transmission, and cookies.
URL encoding and Data Transmission
The following is an example:
Http://www1.baidu.com/baidu? Word = netcat + ex... gb2312 & cl = 3 & f = 1
Generally, our browser must encode the data before sending it. This is a standard. GET and POST are the same. Of course, you can use the enctype field to specify other encoding methods for the form. The preceding example syntax uses the HEAD request format. We can see some special symbols, such as "%", because when the data contains non-letter or data characters, URL encoding converts a character into a number corresponding to its ASCII code, which is represented by a two-digit hexadecimal encoding. The percent sign indicates the URL encoding. Therefore, % 25 indicates the percentage itself (25 is in hexadecimal format, which is based on 16 and represents the ASCII code value of the percentage), all 127 (7 fhex) and above, all characters earlier than 33 (21hex) are escaped. This character contains a space character. The Escape Character of a space is % 20. the plus sign is interpreted as a space character.
Cookies
I will not talk about the role of cookies here. I will introduce its syntax and format. Let's look at an example of cookies.
Aspsky
Userhidden = 2 & password = 469e80d32c0559f8 & userid = 1 & userclass = % B9 % DC % C0 % ED % D4 % B1 & username = admin & usercookies = 1
Localhost/bbs/
0
3061727232
29562033
2222055456
29561914
*
Let's take a look at the cookies in this example. The properties mainly include:
Key --> aspsky
Value --> userhidden = 2 & password = 469e80d32c0559f8 & userid = 1 & userclass = % B9 % DC % C0 % ED % D4 % B1 & usernam e = admin & usercookies = 1
Damain --> localhost/bbs/
Secure --> 0 is equal to no
Expire --> 3061727232 29562033 the validity period must be decoded before it can be read.
Modified --> 3061727232 29562033 modification time, the decoding method is the same as expire
Created in-> server
Sometimes there is an ip address
These introductions are just for your understanding of cookies. For details, please refer to some professional materials. Sometimes some friends often ask how to forge cookies. I want to write it here very clearly.