1. The signaling messages in a room should be distributed by the background rather than the client

1.1 What if the client distributes?

  • Who sends the order message on the client side?
    • Follow the business differentiation logic. It’s easy to imagine that controlling signals such as “kicking” or “eating” can only be triggered by being a homeowner or administrator. Sending text messages or pictures is a universal signaling that can be triggered by the initiator. At first glance, this logic seems fine, but in reality, it’s a lot of trouble. The following
    • Is there a possibility that the client can be cracked? What if I intercept your encrypted message and send it back exactly as it was? Then you have to check for uniqueness.

    There is also the problem of checking uniqueness only, plus time stamp checking. Because our signaling message ids are generally stored in memory in real time, they are not saved locally. It is possible for someone to retransmit the message before killing the process. [such as gift messages], if the message ID is saved locally, there will be a new question, how long do you want to save? How much space do you want to save before deleting?

An attacker can also modify the number of memory values on the client side, regardless of any encryption method you use. For example, the number reported to the interface is 1 gift, but when the client sends a message, it is changed to 99. This vulnerability occurs if the client is not carefully calibrated.

  • Huge maintenance costs
  • The workload is large, android and iOS need to write the logic of sending a message.
  • During release iterations, signaling message fields are easily added, modified, or discarded. If maintained by the client, the iOS and Android versions need to be strictly consistent. And because the update rate of the new version of Android is much lower than that of iOS, iOS often sends out old signaling messages in order to be compatible with the old version of Android.
  • There is something wrong with the line. We can’t deal with it in time. As I have seen, in the room to send special Arabic characters, Android room will immediately crash after receiving. If the text message is distributed by the background, in this case, the character can be quickly masked to avoid a crash.
  • Other problems: Multiple clients rob the MAC. Clients A, B, and C initiate A MAC robbery at the same time. Logically, when the three clients send signaling messages, the time stamps must be different. But the other clients don’t know that. Suppose the actual click time is A first, B second, and C last. The most likely order to get to client E is B, A, and C. The order of arrival at client F is C, A, and B. This caused a number of mobile phone mic personnel display inconsistent problems. 【 was trapped by the client to own logic, compromise is who first received the message, who first showed wheat, in a certain period of time, such as 5 s received other news on wheat, comparing timestamps, if earlier, then replace the people on the wheat] such an experience is not very good, people in the room, Michael will display a person first, Often another person is immediately displayed. If the background controls who can be on the mic, there is no such problem.

The above logic, the client will also be mixed with the timestamp problem. For malicious users, they can disconnect the network first and restore the network before triggering the forced logout callback. Because the mic bit information has not been pulled at this time, the mic bit can click. At this time, the user can click and adjust the time stamp of the mobile phone to an appropriate time at the same time. So no matter how he operates, he can replace the original mic [I have encountered a problem, big R was repeatedly malicious mic]. Note that in this scenario, a timestamp correction at App startup does not solve any problems. Need to be corrected in real time every time. Of course, we have a simpler judgment, the user is not allowed to click until the data is pulled. In order to insist that the client send the message, we can of course try the following: there are some ways that the local client can increase the threshold of attack, but it is not cost-effective. Confusion and reinforcement: THE author confused for a period of time but was found by Apple during an audit, which was rejected and warned not to confuse again. Android app 360 is hardened and obtuse, and it is understood that professionals can directly crack the memory protection: increased business complexity, because every time a client sends a message, it needs memory to compare the information to see if it is tampered with. If normal service logic triggers the modification of user information, you need to synchronize the modification in other places. Or the application of some other advanced protection technology [anti-debugging, prevent decompilation, code realization, code out of order, instruction replacement, etc.] above their own implementation, heavy workload, easy to cause a variety of other bugs, small output return. If you directly use mature SDK, such as love encryption, it will increase the cost (the basic version of the protection SDK starts from tens of thousands).

  • At the root of all the above problems is that the client does not have an authentic reference platform. All local information can be falsified. Sending fake information to other clients can easily lead to endless problems, and the client will be trapped in endless torment, only to be passive defense. However, when this problem is encountered online, the customer feedback to customer service, customer feedback to test, development, discussion and analysis, solution, modification, test, shelf success, users update. By the time this series of processes are finished, at least in the past three or four days, the platform’s reputation has been affected. To sum up, if a signaling message is tampered and may affect other clients, the message must be distributed by the background.

2. Room lock

  • Under no circumstances should the interface directly return the lock’s password value and let the client check whether the password is correct, even if it is encrypted. Whether the password is correct must be judged by the background. The front end is only responsible for submitting the password entered by the user when entering.
  • Room locks, we usually design in the form of pure numbers. Note: when the client using pure digital keyboard, need extra processing under the background of Arabic Numbers, or the client custom pure Arab digital keyboard (some big R will don’t like the keyboard, they would like to use their own language number), or the client itself Arab language, after converted to Arabic numerals in the upload.

3. Positioning of target users

  • Putting Indians and Middle Easterners together creates a lot of contradictions and cultural clashes
  • Indians like special Indian gifts like slippers that are very high
  • Arabs look down on Indians for being poor and noisy