Revealing the 315 hacker wifi, how to ensure APP data security?

The 315 Party exposed WIFI security, demonstrated WeChat and email being hacked on the spot, and private passwords were disclosed. Risks are everywhere. For users, Ali Mobile Security has given the following advice: 1. Do not access WiFi without passwords or mobile verification codes; 2. Do not root or jailbreak your phone; 3. Download official APPs from regular app stores; 4. Do not submit important personal information on unfamiliar APPs; 5. Install a security software, such as Ali Money Shield; develop healthy and good Internet habits, etc. For developers, how can they better design mobile apps to protect against attacks after WIFI is hijacked?

Attack principle under WIFI

Attackers usually attack WIFI through man-in-the-middle attacks. During the man-in-the-middle attack, the path of normal APP applications through WIFI is as follows:

Figure 1

Hijacked by hackers, the attacker creates independent connections with both ends of the communication and exchanges the data they receive. Through man-in-the-middle attacks, the attacker can steal sensitive information of HTTP or other plaintext protocols, crack HTTPS communications, hijack DNS, etc.:

Figure 2

In the mobile application environment, HTTP or other plain text protocols such as POP3, SMTP, FTP can be sniffed through various proxies and sniffing tools, just like in the PC environment. Attackers can also attack HTTPS. These attacks generally include:

1. Attack HTTPS through SSL separation + HTTPS-> redirection, etc.          

The principle of SSL separation + HTTPS-> redirection is:

- ARP spoofing allows the attacker to intercept all network traffic of the target host

-The attacker takes advantage of the user's negligence of HTTPS and HTTP in the address bar and replaces all HTTPS connections with HTTP

-At the same time, establish a normal HTTPS connection with the target server

-Since HTTP communication is transmitted in plain text, attackers can easily sniff it

Off-the-shelf tools such as ssltrip, dSploit, and zANTi can all be used to perform such attacks.

2. Use the client to not verify the SSL certificate (including whether the signing CA is legal, whether the domain name matches, whether it is a self-signed certificate, and whether the certificate is expired):

This problem is often caused by several coding errors:

- Java code snippet of the self-implemented X509TrustManager interface that does not verify the certificate (that is, the checkServerTrusted() method is implemented as empty, that is, it does not check whether the server is trusted):

- Java code snippet that does not check whether the site host domain name matches the domain name in the certificate (i.e. the verify() function directly returns true to accept any host domain name)

- Java code snippet that accepts any host domain name

-When using webview to load HTTPS web pages, override the onReceivedSslError() function in the Android system WebViewClient class to directly ignore certificate verification failures and accept any certificate

Solution

Since hijacking is sometimes inevitable, developers have an obligation to protect users. Alibaba Mobile Security recommends that developers do not use the HTTP protocol to transmit sensitive information. When using HTTPS for communication, remember not to support HTTP at the same time. If you must use the HTTP protocol to transmit sensitive information, use the Juanquan SDK component to encrypt the input data. Developers can also use the Juanquan SDK component for more tips: through audit and review, security reinforcement, and strong verification of SSL certificates; through data encryption, sensitive information leakage will not be affected in the case of WIFI hijacking; through security signatures, session integrity is guaranteed in the case of WIFI hijacking, and data is not tampered with or forged. Ensure that the risk is minimized in the event of WIFI hijacking:

Figure 3