How did Zalo encrypt their Web API?

The story of Alizalo and 40 bandits.

Once upon a time in a countryside there was a small town called Zola. That place is a peaceful, dreamy countryside. Around the town are simple farmers specializing in vegetable farming, hard-working cows. Vegetable in Zola town is a famous vegetable in the market. It is famous because of its variety, from the slender green vegetables to the oversized type, it is enough to be tough. In the evening, rows of vegetable carts from all over Zola's fields were glistening towards the town, which was a bustling but equally peaceful sight.

Life has inherently been able to go through such peaceful days, if not naturally there are 40 fierce robbers who come stalking on the road to transport vegetables. They plundered vegetables, goods, money of farmers, sometimes even forging farmers to bring fake vegetables into the city.

Before that situation, suddenly a day appeared a mysterious person named Alizalo appeared with the statement will protect the path of farmers, avoid robbers can touch vegetables and prevent pseudo-farmers. People at first did not believe it, but because the bandits were too raging, they had to try it. And it was unexpected, a time after the number of robberies has decreased. And Alizalo has been honored to become a hero …

So how did Alizalo do to prevent theft on Zola's transport route? Let's follow it up.

First things first

I am Minh Monmen , your storyteller today. If you imagine your web application is a solid citadel, then API is the way to get into that building. To be able to comprehend today's story, please learn some concepts:

• Web API
• Client – server connection, HTTP request
• Man In The Middle (MITM)
• Cross-origin resource sharing (CORS)
• Web Crawler

Okay, let's begin.

The story of 40 bandits

Talk to 40 bandits, not to mention their cruel tricks. Let's take a look at:

• The one on the road blocking the vegetable car (Man In The Middle). This person will block the Web API by interfering with the transport path of computer networks.
• As bandits in the mountains but disguised as farmers to use town goods (CORS). These guys come from a fakezola.com website but can still call the API to the official website via the user's browser. Therefore, access to user data (if the user is logged in on the official website)
• Is a counterfeiter who specializes in collecting genuine goods from the town, then falsifying or using for personal purposes (Web crawler)

What they did

So how to prevent Web API from being interfered or misused? Let's see how the Alizalo guy did:

Set Access-Control-Allow-Origin header

This is a header returned by the Server to tell the browser: "I only allow this domain's website to call me". As I said in the article about authentication. The method of keeping a login session using cookies will have the feature of a cookie that automatically attaches a cookie to the request when calling the original domain . So if you visit hellohacker.com , this website can completely call up Zalo's API to get your current login information (since Zalo's API call will automatically have Zalo's cookies) . Access-Control-Allow-Origin header was born to prevent this.

Remember CORS does not prevent anyone from calling your API. CORS header only works for requests from the browser

Encrypt API response

Although HTTPS is an HTTP protocol with end-to-end encryption for MITM prevention. However, Zalo developers found this still not enough, and they went one step further on the path of preventing the curious. Please open firefox, turn on F12 and start watching what Zalo APIs have?

A string of data that is boundless. I don't know what the model is all about. However, after performing a few simple but laggy operations to inspect the 7.6MB heavy code file of zalo web (already minify), I found the following code to be executed to decode each request:

Actually this js file has been minify, above is the function I have edited some important variables so that you can understand what it is doing

It turned out that zalo used AES encryption to encrypt the entire response response. In the above code, you can easily see what we need to decrypt the response from the API is the secretKey when other components have hard fixes.

The first is the idea of secretKey hidden in code to me. Although this is the most criminal way to save the secretKey. Because of that, the secretKey will exist for too long, and every time it changes, it will cause the js file to be updated again. However, immediately after that I saw the catch error section of the log: Change zkey . So it is possible to exclude the secretKey hidden in the code that will be taken from the API.

Go back to the inspect network, and I see there are some unencrypted APIs:

In those, this getLoginInfo API seems to have the potential to contain the most secretKey. I continue to see that secretKey is decoded Base64 before using: var secretKey = i.default.enc.Base64.parse(this.getSecretKey()); .

So that secretKey will be in Base64 format. And sự chú ý của ta đã va phải vào cái key của nàng , I tried zpk_enk: U0hHcmksxATNSMjEJ/RGiQ== in this response from API and … VIOLA, I caught the card:

Again, this method includes steps:

• Create 1 Secret Key on the server.
• Sharing Secret Key between client and server (Through hard fix in code, config file, API).
• Use Secret Key with AES encryption (or any trusted encryption algorithm) that encrypts the response from the server.
• Use the Secret Key to decode it again to get information from Response.

Basically, it is no different from the concept of HTTPS, which is to encrypt and decode the terminal so that the middle person cannot read it. The other thing here is that HTTPS is done automatically by the browser, but here we have to do it in our client code.

So, when someone checks or catches requests to Zalo, it will only see the encrypted data and do not understand anything. This helps limit the application or 3rd party, web crawler is not Zalo web client illegally using API of Zalo. But you see, after about ten minutes I was able to simulate the decoding process under the client. So this method is used to fight people immediately =))

summary

Through the completely fictional story above, I draw 3 things:

• Everything on the client cannot be trusted.
• You cannot prevent the 3rd person from using your API. But you can limit it. Doing it takes time to tinker with your code as above is an example.
• It's over