Time to make normal Telegram bots #2

Time to make normal Telegram bots #2

I am sure that many people do not even think about how the bot being developed will behave if it is misused. It’s time to reveal your robots and fix the flaws that are often allowed, which I will describe here. Again there are 5 of them, again no code, again only a description. Welcome under cat.

Previous parts:

1. Russians are outsiders for a reason

I’m sorry if it overlapped with the subpoena, but it already happened that the international encoding uses a one-byte part for the Latin alphabet, and a two-byte part for the Cyrillic alphabet and others (including emojis). This means that when using “non-Latin”, for example, in the buttons (parameter callback_data) or in the text of the message (or in the caption to the media), you may not have enough space. If you send such a “long” request to the Telegram server, it will say so, but the request will not go anywhere. Your task is to check the response from the server so that the result is positive (for example, for the method sendMessage a positive result will be a sent message for answerCallbackQueryTrueand for editMessageText generally different, depending on the type of message being edited). If the result is not positive, you need to solve it: shorten the message or something else.

A programmer must ensure that his code controls itself. The response of each called method should be checked, if it suddenly fails – then something needs to be done to ensure that the code completes and doesn’t break in the middle due to an incorrect response or ambiguous behavior.

2. Users have the ability to delete messages

It will be sad if you send a message that needs to be updated, but the message doesn’t end up in the dialog at the right time.

It should not be forgotten that it is a commandment for a programmer to consider the user an idiot.

As much as you’d like to write as few checks as possible, you can’t do it while there’s a person on the other side. Obviously, it will not be possible to update a non-existent message, but there is a more serious problem: the buttons attached to the keyboard (ReplyKeyboard) exist until (if they are not specifically deleted) as long as the message with which these buttons came to the user exists. So if a person deletes a message, those speed dial buttons also disappear.

Example of buttons with a message from a bot.

I don’t use these buttons, so I can’t give examples when this is critical, but consider that a person can lose them like this – just by deleting the “same” message.

3. You need more checks than you think

In addition to the basic “don’t allow SQL injections” there is a very funny situation:

Asked the bot to send me my name.

This is what my name looks like in settings:

Tags could be inserted into different parts of the name, but that’s it, I think, it’s clear what it’s about.

If the developer uses html markup in messages, any tags will not be text unless they are specifically escaped. I don’t know how it works with markdown, but be aware that with incorrect html markup (incomplete tags, non-existent, etc.) telegram will not send a message to the chat, but will say that you have incorrect markup, and then you will be guessing , which doesn’t work like that.

4. No, the checks do not end there

This also happens:

One of my bots. Two identical messages.

The user can use the button twice (sometimes even very dangerous for the developer and for the user) in the same messages. If you have not provided a bunch of checks for pressing the button – the result can be sad. Sometimes even one button is enough to bring down the server or cause it to malfunction. And so there are several solutions. If multiple clicks of a button cause problems, you can prevent the button from being clicked again until the current click is processed: for example, set the user to a block flag so that any (or some) requests from the user are ignored while the previous request is processed. In addition to checking the reuse of dangerous buttons on the server, you can add a secret to the buttons (or, to save space in the request, store the ID of the sent message with the necessary buttons, they are then returned to us when pressed), and when pressed, check whether (i.e. or current) button is used. If not, then do, for example, like this:

An example of refusing to process an outdated message.

5. You can’t trust Telegram either

Since you are using a direct link to the script when you install the webhook, this means that anyone can send any request to your bot if the link is compromised. The danger of not verifying the data received from the telegram is directly proportional to the seriousness of the development: the more “tasty” your bot (or your activity, respectively) is for hackers, the higher the probability of hacking if you do not verify the data received from the outside (even if it is the telegram itself) . If a number is expected, check if it is a real number; if text with a certain number of characters, spaces, etc. is expected. – Check this too.

Yes, in simple bots all this is not necessary, but if you monitor these little things, control yourself, take into account any outcome of events, then you will have to spend less time catching errors. Design bots in such a way that their behavior cannot be broken even if they are intentionally misused. If you don’t want to think about it, just forbid using the bot incorrectly.

Related posts