Analysis of "malicious proxy" attacks in mobile client development

When designing HTTP security, malicious proxy is an important part to consider, especially in the era of "WiFi. A free WiFi node in a hotel or shopping mall may expose important information such as passwords and funds when using the client.

This article describes how to avoid malicious proxy attacks in security design based on several attack methods.

I. Packet token Modification

This is a relatively small attack, as long as you have a little security awareness, it is easy to prevent. A typical attack is to intercept a plain text request through a malicious proxy, analyze the request format, modify some of the parameters, and then send a request to the simulated user to the server. In this way, the user's private data on the server can be easily damaged. For example, a user sends a command to delete a message, and a malicious proxy modifies the Command sent by the user to clear all information.

For this type of packet rewrite attacks, we can abstract the request packets to prevent them.

Ii. replay attacks

This is mainly for server attacks. There are always some APIs on the server that consume a lot of performance, either for security or complicated services. A malicious proxy may intercept a user's request and send the request to the server continuously for DoS attacks. If the server cannot sign for the request, it will affect the services of normal users. For such replay attacks, we can add random number verification in the request to set the request timeliness. There are several specific methods for reference:

1. The server Synchronizes time with the client at the first request. When a customer requests a random number, the current time of the request is obtained, the server determines whether to replay the attack based on whether the client time is too different from the server time. This method is easy to implement. However, due to the time difference in network interaction between the client and the server, the timeliness is slightly lower.

2. When the request server responds, it returns the random number of the next request. The server abstracts the random number with the normal request data. The server verifies each request. If the random number is abnormal, It is a replay attack and the request is invalid. However, this method can also be used to deal with relatively simple malicious proxies. A more powerful malicious proxy can intercept this random number. The biggest problem with this method is the inability to verify concurrent requests.

3. The client and server use the shared key to generate a random number for each request. For example, for security hardware, the server can also generate a corresponding key for each client. When sending a request, the client generates a random number using the key and includes its own appkey in the request. When the server receives a request, it queries the client's key based on the appkey of the client and generates a random number based on the key. If the random number is the same as the one sent by the client, the request is normal, otherwise, you can identify the request as a replay attack. The disadvantage of this method is that once the appsecret of the client is cracked, the security will disappear.

Iii. password cracking

This type of attack mainly involves obtaining user authentication information such as passwords. There may be the following methods:

1. Use a malicious proxy to replace the security certificate for HTTPS connections. If the design relies too much on HTTPS security and the information sent via HTTP is not encrypted, it is easy for malicious agents to intercept and analyze the user's original password.

2. For simple password digest information Authentication, malicious proxy can use the dictionary to perform brute force cracking after the digest is blocked. If the request contains a summary with a random number, the malicious proxy can simulate the server to respond to a random number from the client, and then perform brute-force cracking on the intercepted client requests.

Malicious proxy is far more destructive than traditional internet, and security issues have never been solved overnight, we need to make more careful trade-offs between security, convenience, and performance during design, and work together to protect our users.