IOSOR

IOSOR Знания

Защита на входящи уебхукове с множество тенанти чрез проверка на подпис

Научете как да валидирате подписи на входящи SMS уебхукове в IOSOR, за да защитите подсамовете с множество тенанти срещу фалшифицирани мобилни събития и неоторизирани инжекции на трафик.

Защита на входящи уебхукове с множество тенанти чрез проверка на подпис.

Архитектурен преглед на входящата проверка

Когато управлявате CPaaS платформа с бял етикет, защитата на вашите крайни точки срещу фалшифицирани заявки HTTP POST е от жизнено значение. Маршрутизирането с множество тенанти въвежда сложни гранични случаи, при които входящ полезен товар от мобилни SMS съобщения може да бъде насочен към грешен подсамов.

Инспекция на криптографски хедър и управление на тайни

Всяка входяща доставка съдържа специализиран хедър за оторизация, обхващащ криптографския дайжест и времеви печат. Вашият тръбопровод за приемане трябва да извлече този токен и да потвърди, че възрастта на заявката попада в тесен прозорец на толерантност, обикновено пет минути, за да се предотвратят атаки с преиграване. Тайните се предоставят динамично, когато тенантите завършат JIT предоставянето чрез API на нашата платформа.

Обработка на парсване на полезен товар и нормализиране E.164

Когато валидирането на подписа успее, вашият работник парсва JSON полезния товар, за да извлече номера на изпращачи, токени за маршрутизиране на дестинацията и текст на съобщението. Всички номера преминават през строга нормализация E.164, преди да влязат в опашката за обработка.

Смекчаване на атаки с преиграване и отклонение на часовника

Мрежовата латентност и малките разлики в часовника на сървъра могат да причинят триене при верификацията, ако не се управляват правилно. Внедряването на кеш с плъзгащ се нонс гарантира, че идентичните подписи на уебхук не могат да бъдат препредавани злонамерено. Ако вашата крайна точка за приемане върне статус, различен от 2xx, поради временна блокировка на базата данни, платформата поставя на опашка сигурен повторен опит.

Отстраняване на неизправности при неуспешни подписи и одити на главната книга

Ако валидирането на подписа се провали, проверете суровите HTTP хедъри и потвърдете, че междинните прокси сървъри не променят интервалите в тялото на заявката. Администраторите могат да сверят неуспешните опити за доставка в одитните логове на платформата.

Започнете с IOSOR

Направете POST на подписано входящо събитие със секрета на наемател B към края на наемател A. Проверката трябва да отхвърли. Завъртете секрета на един наемател и докажете, че пада само неговият webhook. Експортирайте отказ на подпис срещу id на наемателя. Това е HMAC на наемател, не изолация на списък STOP и не дебит на прозорец replay.

Обобщение IOSOR

Един URL на webhook не е един секрет.

Правете: проверявайте HMAC срещу наемателя, който притежава DID. Не правете: да делите един ключ за подпис между подсметки или да приемате неподписан MO като вътрешен.

Полезно ли беше ръководството?

Свързани ръководства