Web security practice (2) Analysis of http-based web architecture

Web security practice (2) Analysis of http-based web architecture
The web security practice series focuses on the practical research and some programming implementation of the content of hacker exposure-web Application Security secrets and solutions (version 2. So if you fully understand this book, you can skip this article.




Body
In the first article, I briefly introduced the related tools. If you are familiar with them, let's try it out today!
2.1 determine the target
(1) ping. This is the most common method. We can perform this operation on a known domain name to obtain an IP address.

(2) DNS query. You can query the IP address of a website that provides the DNS query service on the Internet.
(3) port scanning. For an established ip address, we can scan whether to activate the corresponding well-known port to determine the service started by the server. Of course, the server can use any port for web services. We can perform simple detection on the corresponding port, for example, using netcat to send simple get or head requests. Check whether the web Service is activated in the response.

2.2 Obtain target web server information
Web server information collection is the main content of Architecture Analysis. Currently, we only discuss the analysis from the http protocol perspective.
Banner capture.

The most direct way to capture Banner is to use the browser extension tool I introduced in the previous section. The following uses the FireFox extension Live HttpHeaders as an example.

We start the capture option of Live HttpHeaders. Enter www.xiaonei.com.

In this case, you can view the request and response information.

From the response information, we can see that the website's server version is Resin 3.0.21. Through google, we can learn more about the server and the website. This is very important and I will introduce it in detail later.

I will not detail other tools that can get http packets, as long as they can achieve any feasible solution.

Http fingerprint.

The http1.1 specification (RFC2616) encourages the implementer to make the Server field configurable for security purposes. In this case, the http response information we get may be false information.

The solution to this problem is to jump out of the server response content, and then observe the overall behavior of the server against various responses. Because the current server does not have a uniform specification for the response details, they are different. As long as the analysis is conducted from a statistical perspective, we can see the original face of the server.

Uncommon http request methods

The less common a request is, the more likely a different response is.

Error Message

The error information is the easiest way to expose the original face of the server.

Both methods require us to summarize a large amount of correct data, analyze the Unknown Server, and compare the corresponding behavior with the known behavior for judgment. I hope that experts who do this can provide relevant information.

Httprint Tool

Net-Square's Httprint tool is an automated http fingerprint analysis tool with a customizable web Server fingerprint database. The following is a result report of Httprint.

If we want to use our fingerprint analysis tool, we need to test various servers. Now I do not have this condition.

2.3 Middleware Architecture Analysis

 

One possibility is that the host that returns information is not the one that we think is being analyzed, probably because of the Middleware Architecture configuration of the web server, including the Server Load balancer, virtual server configuration, proxy, and firewall.

Server Load balancer Detection

If a server with Server Load balancer is continuously attacked, each request may be distributed to a different host. If you do not realize this, the attack will never succeed. In theory, each server should be exactly the same, and the response should be exactly the same, but there will be many differences in reality. The server time, configuration, file directory, and so on may be different. If we find that we have a chance to start.

Scan ports within the same ip address range. First, determine the Server ip address of the host alias, and then send a request to the surrounding ip address. If the response is the same, it may be the Server Load balancer instance. However, if the server Load balancer host is in the same LAN within a few days, this method cannot be detected. If we use this method to obtain the Server ip address of the Server Load balancer, then we can test these ip addresses to check the differences among hosts, which will provide us with new ideas for intrusion.

For Load Balancing using dns round robin, we can easily see its related hosts.

Through domain name resolution, we can see multiple IP addresses of the Server Load balancer host on the Intranet.

Xiaonei.com has two ip60.28.196.237 and 60.28.196.247 (mobile phone internal network ).

Timestamp analysis. Send multiple requests consecutively within one second to check whether the timestamps in the returned headers are the same. If some hosts are not synchronized, you are lucky to find its load balancing function. I will demonstrate the implementation of this method in programming. Etag and Last-Modified. We observe two values after multiple requests. If they are different, load balancing is very likely to exist. View the comments in the html source code. If the comments of the same page are different, they may come from different hosts. Check the differences between ssl certificates. I have no good practice for this method. I hope you can give me a good practice solution.

Oh, I am so tired. I wanted to write all the Middleware Architecture today. It seems that I can't hold on, so leave it till tomorrow. More experiments are also required. Finally, I am grateful to have more friends to communicate with each other.