Using HTML to implement a voting website cheating scheme that restricts IP

This is a cheating scheme for voting websites with restricted IP addresses. This method takes advantage of some loopholes in the voting website's monitoring of remote IP addresses. It does not actually forge IP addresses. HTTP is the seventh layer built on top of TCP. It is impossible to forge real IP addresses. Recently, a friend needed a voting software, and I also studied this voting website. This voting website has a verification code, and each IP is limited to one vote. It looks like a standard voting website. I studied the verification code first:

The verification code of this voting website is very simple at the beginning, with standard four numbers in standard positions, which is easy to recognize. Later, the verification code was modified to have different digits and letters, and the positions were different. Now, it is difficult for software to recognize the verification code, and even manual recognition is difficult. When you seem to have reached the end of your rope, there is always a way out. Please see the next paragraph for details!

As I continued to analyze and research, I found that there was a loophole in its verification code check. After discovering this loophole, the verification code has become useless. There is no need for identification or verification code. It can be bypassed directly because it only sets the js code on the voting options page to check whether the verification code is empty. The js code runs on the client, and the effect of this verification is zero. Generally, JS verification is just for the convenience of users. As a voting website, it only uses this verification method. It does not check whether the verification code is empty on the voting processing dynamic page. This is really unacceptable and poses a great threat to the security of the website.

Regarding the verification code problem, I have already learned how to crack it. As long as you don't directly access the verification code file when voting, the verification code will be empty. Since its dynamic page does not check whether the verification code is empty, as long as the verification code parameter is empty when posting, it will be fine.

Then there is another problem. This voting website checks the IP and limits an IP to only one vote. Therefore, this can only be achieved by using a proxy or by constantly disconnecting from the Internet and dialing up. I really couldn't think of any other good solution, and then this friend found a program that could vote on this website very quickly. I was very curious about the IP solution of this program, so I asked my friend to analyze it.

First, I took the approach of capturing packets of the voting software to study it. After I was ready, I opened the voting program and "Swish! It prompted a software conflict!" Oh no, no way. Then I closed some programs and only left the packet capturing program, which still prompted a conflict. Haha, it turned out that this program knew that someone might analyze its software, and it actually traversed the process name to check whether there were any suspicious programs. If a program analyzed it or captured packets, it would refuse to run. Haha, currently I know that the restricted software includes Easy Language programming software and WSockExpert_Cn packet capture software. Haha, I closed Easy Language, changed the name of WSockExpert_Cn, and successfully passed the software's own security test and ran successfully.

The following is the data packet I voted for during use:

-Forwarded-For I found this http header parameter followed by the IP. Haha, this parameter must have a history. I didn’t know it before. Haha, I quickly searched it on Baidu.

The following is an explanatory article from Baidu, it is very well explained, you can take a look.
Forge the X-Forwarded-For field in the HTTP header to forge the IP. I searched Baidu for the principle of X-Forwarded-For. This thing has been out for a long time. This is the first time I heard of X-Forwarded-For: XFF header for short. It represents the client, that is, the real IP of the HTTP request end. This item will only be added when passing through an HTTP proxy or load balancing server.

It is not a standard request header information defined in the RFC. A detailed introduction to this item can be found in the squid cache proxy server development documentation.

The standard format is as follows:

X-Forwarded-For: client1, proxy1, proxy2

As can be seen from the standard format, there can be multiple X-Forwarded-For header information, separated by commas. The first item is the real client IP, and the rest are the IP addresses of the proxies or load balancers that have passed through. There will be several of them.

Wiki's X-Forwarded-For explanation http://en.wikipedia.org/wiki/X-Forwarded-For analysis:

Since we want to forge the client IP, let's first look at how to obtain the client IP address (using PHP as an example). This code was found by searching on Baidu. Most websites may use this code.

First, determine whether the HTTP_VIA header exists. The HTTP_VIA header indicates whether a proxy server is used. If not, get the client's IP address from the REMOTE_ADDR field. If yes, get the client's IP from X-Forwarded-For. I guess many programmers get the code from Baidu. ASP is similar.

Then let's test it.

Server code:

You can see that the client IP addresses obtained are different. REMOTE_ADDR is the real address.

So if a website determines the client IP address from X-Forwarded-For, we can use this logical loophole to cheat.