Construct HTTP request headers to "forge source IP addresses"

Before reading this article, you should have a concept that the source IP address cannot be forged in the case of normal TCP/IP communication. That is to say, in the TCP/IP protocol, the source IP address of the data packet can be forged, but this will prevent the sent data packets from going back and cannot implement normal communication. This is like when we write a letter to the recipient, if the wrong sender's address is written, and the recipient replies according to the sender's address on the envelope, the original sender cannot receive the reply.

 

Some DDoS attacks, such as SYN flood, use this vulnerability of TCP/IP to launch attacks. In the book "Computer Network", such behavior is defined as "no matter if it is launched ".

 

Therefore, the forged Source IP address in the title of this article is enclosed by quotation marks. Not all HTTP applications have this vulnerability.

 

How does "counterfeit source IP address" occur in HTTP? How to defend?

Before understanding this principle, you need to understand the HTTP protocol. HTTP is an application layer protocol based on the request/response model. Client (usually a browser) Requests correspond to server responses one by one.

 

The request information consists of the request header and request body (the Request body is blank when a GET request is sent ). The request header is similar to the basic information enclosed in the letter when we write a letter. The request body is similar to the letter body. The response format of the server is similar, which consists of the response header information and response body.

 

To understand this principle, you can use Firefox Firebug or the IE browser plug-in HTTPwatch to track HTTP Request/response data.

 

The following uses HTTPwatch as an example. After httpwatch is installed and the IE browser is restarted, its icon appears on the IE Toolbar. Click and run Httpwatch, And the HTTPWatch main interface is displayed below the browser.

 

Click the red "Record" button in the lower left corner and enter www.baidu.com in the address bar. After the page opens, select a request and select "Stream" in the tab button below ",

 

Request data on the left and server response data on the right. The request headers on the left end with a line break, that is, "\ r \ n", and a blank line (content is \ r \ n), indicating that the request header ends. Except for the first line, other lines in the request header are composed of the header name and header value, such as Accept-Encoding: gzip, deflate, And the header name and value are separated by colons, the space between them is optional.

 

In the HTTP application, how does one obtain the specified request header information? The PHP language is used as an example. For all client request headers, the PHP program obtains the value as follows:
$ _ SERVER ['HTTP _ HEADER_NAME ']

HEADER_NAME should be replaced with the corresponding header name. The rule of this item is: Full uppercase, and the connection line becomes an underscore. For example, to obtain the User-Agent Request Header of the client, you can use $ _ SERVER ['HTTP _ USER_AGENT '] to master this rule to achieve the opposite effect. To obtain COOKIE information, use $ _ SERVER ['HTTP _ cookier. That is to say, items starting with HTTP in the $ _ SERVER array belong to the information sent by the client.

 

Back to the HTTP application layer, the source IP address is important, for example, form submission restrictions, frequency, and so on all require Client IP information. Use the code snippet in the popular Discuz X2.5 file source/class/discuz/discuz_application.php:

Private function _ get_client_ip (){

$ Ip = $ _ SERVER ['remote _ ADDR '];

If (isset ($ _ SERVER ['HTTP _ CLIENT_IP ']) & preg_match ('/^ ([0-9] {1, 3 }\.) {3} [0-9] {1, 3} $/', $ _ SERVER ['HTTP _ CLIENT_IP']) {

$ Ip = $ _ SERVER ['HTTP _ CLIENT_IP '];

 

See the following JSP code snippet:
Public String getIpAddr (HttpServletRequest request ){
String ip = request. getHeader ("x-forwarded-");
If (ip = null | ip. length () = 0 | "unknown". equalsIgnoreCase (ip )){
Ip = request. getHeader ("Proxy-Client-IP ");
}
If (ip = null | ip. length () = 0 | "unknown". equalsIgnoreCase (ip )){
Ip = request. getHeader ("WL-Proxy-Client-IP ");
}
If (ip = null | ip. length () = 0 | "unknown". equalsIgnoreCase (ip )){
Ip = request. getRemoteAddr ();
}
Return ip;
}

 

The above code snippet gets the Client IP address. This program will try to check HTTP_CLIENT_IP and HTTP_X_FORWARDED_FOR. According to the previous principle, headers starting with HTTP _ are all sent by the client. So, if the Client spoofs the Client-Ip, X-Forward-For, can this program be spoofed to "forge the IP address?

 

So how can we forge this value? If you write a program and understand the HTTP protocol, you can directly forge the request header. You can also use the Moify Headers plug-in of Firefox.

Enter or click the corresponding button according to the sequence number shown in the figure. The Start button changes to red Stop, indicating that the setting is successful.

At this time, if we use Firefox to access other websites, the website server will receive our forged X-Forward-For, with the value 1.1.1.1.

 

Strictly speaking, this is not a program vulnerability. To maintain good environment compatibility (including the web server environment with reverse proxy, such as nginx as the front-end proxy of php fastcgi), Discuz can be understood in this way. So how can we solve this problem?

 

The server reconfigured X-Forward-For to the correct value.

 

For example, for a typical nginx + php fastcgi environment (whether nginx and php fastcgi are on the same machine does not prevent this problem), nginx and php fastcig processes communicate directly:

 

Remember, $ _ SERVER ['remote _ ADDR '] is a parameter passed to php by nginx, which represents the IP address of the client that communicates directly with the current nginx (which cannot be forged ).

 

For example, an intermediate layer proxy server environment exists:

 

 

In this case, the REMOTE_ADDR obtained on the backend HTTP File Server is always the communication IP address of the front-end squid/varnish cache server.

 

Communication between Server clusters can be trusted. What we need to do is to forcibly set the X-Forward-For value on the front-end proxy closest to the user. No configuration is made For all backend machines, directly trust and use the X-Forward-For value passed by the front-end machine.

 

Set on the frontend Nginx:

Location ~ ^/Static {

Proxy_pass ....;

Proxy_set_header X-Forward-For $ remote_addr;

}

 

If the frontend proxy server directly communicates with php fastcgi, you need to set it on it:

Location ~ "\. + \. Php $ "{

Fastcgi_pass localhost: 9000;

Fastcgi_param HTTP_X_FORWARD_FOR $ remote_addr;

}

Remember, $ remote_addr is a built-in variable of nginx, representing the real IP address of the client (network transport layer. By using this measure, X-Forward-For is forcibly set to the Client ip address, so that the client cannot "forge an IP address" as described in this article ".

 

Does this problem exist in The LVS forwarding environment?

LVS works at the network layer, and does not change the source and target IP addresses, or even the application layer information. Therefore, this problem does not exist. If you have any questions or need help, please contact the author mail zhangxugg@163.com.

 

Programs with this problem:

All versions of discuz, phpcms, phpwind, and dedeCMS. And other programs that may be unknown.

 

For example, if you use Modify Headers to disguise IP addresses and then log on to bbs.phpchina.com, we can view the data that we disguised as the "Last accessed IP Address" in our personal data.

 

It can be said that there are too many websites with this vulnerability on the Internet. Try it. Therefore, be careful when using IP addresses for websites with this vulnerability.