Надеюсь, кто-нибудь сможет сказать, что я делаю не так.
Я настроил вебхук Discourse, и он работает как ожидалось без секрета. Затем я ввожу строку в поле Секрет, а затем копирую эту строку в заголовок принимающего вебхука, как показано ниже:
X-Discourse-Event-Signature: secret_here
Это приводит к следующей ошибке в теле сообщения при отправке вебхука:
{"code":"rest_forbidden","message":"Извините, вам не разрешено это делать.","data":{"status":401}}
Полагаю, что я просто что-то делаю неправильно, так что просветите меня!
Я знаю, что секрет шифруется с помощью sha256, поэтому заголовок, который отправляется, выглядит так:
X-Discourse-Event-Signature: sha256=XXX
Но я не уверен, что мне следует делать с этой информацией в заголовках безопасности принимающего вебхука.
Не уверен, что это просто особенность вашего поста, но реальный заголовок должен выглядеть так:
X-Discourse-Event-Signature: XXX
Вы можете (по желанию) использовать это на принимающей стороне для проверки того, что вебхук действительно был отправлен Discourse. Если вы не выполните проверку, злоумышленник потенциально сможет подделать события вебхука.
Мой сайт на WordPress. Я использую плагин WordPress для получения вебхуков. Если я не добавляю заголовок безопасности (секрет), вебхук работает нормально. Проблема возникает только при добавлении секрета.
В триггер входящего вебхука могут включаться пользовательские заголовки безопасности, но важно отметить, что WordPress может заменять дефисы на подчеркивания. Например, вместо «x-api-key» может потребоваться использовать «x_api_key».
Однако у меня есть связанный вопрос, @RGJ. Допустим, мой секрет — «1234». Каким должно быть значение X-Discourse-Event-Signature в принимающем вебхуке:
Похоже, что используемый вами плагин WordPress может сравнивать только статическое значение заголовка, а не динамическую подпись. Это особенность Discourse.
Позже я обнаружил, что значение sha меняется каждый раз при отправке вебхука, поэтому указание значения sha в принимающем вебхуке не сработает. Мне кажется, что подходит вариант №1, и, как вы, вероятно, предлагаете (с использованием статического заголовка), плагину действительно нужно будет декодировать хеш перед генерацией ответа заголовка?
В заключение: я не думаю, что смогу использовать хешированный X-Discourse-Event-Signature в этом плагине, так как он принимает только статические значения.
Небезопасно ли использовать вебхук без секрета? Я планирую отправлять события пользователей из своего Discourse на свой основной сайт, используя неочевидный URL, например main-site.com/wp-json/fol/fil/532563-5312534. Также я могу добавить статические заголовки, которые должны совпадать на принимающей стороне.
Могли бы вы привести пример приложения, способного обрабатывать динамически меняющийся HMAC?
Это значение рассчитывается на основе полезной нагрузки вебхука, поэтому для каждого запроса оно будет отличаться.
Интересный вопрос. Единственное приложение, которое я знаю, — это плагин WP Discourse, но он был специально настроен для обработки вебхуков Discourse. Если реализация в Discourse мешает людям проверять вебхуки с использованием секретных ключей, возможно, это стоит изучить.
Оставлю этот вопрос другим участникам.
Если вас беспокоит отсутствие проверки вебхука, возможно, в плагине Incoming Webhook Triggers есть хук действия в коде приема вебхука, который срабатывает до обработки данных вебхука. Если такой хук существует, то можно написать функцию, которая подключится к нему, проверит, предназначены ли данные для вебхука Discourse, а затем проверит секретный ключ с помощью кода, похожего на тот, что я приводил в своем предыдущем сообщении.
Мне стало любопытно, поэтому я немного изучил этот вопрос. Я не уверен насчет приложений, настроенных на получение динамически меняющейся HMAC-подписи, но аутентификация запросов вебхуков с помощью HMAC-подписи, рассчитанной на основе полезной нагрузки, является довольно стандартной практикой для приложений, которые отправляют вебхуки. Например, GitHub, Stripe и Shopify используют этот метод.
Также существует множество популярных приложений, использующих метод аутентификации вебхуков с помощью секретного токена. Например (по состоянию на 2021 год), Mailchimp, Trello, Slack и Discord используют этот подход. Похоже, что Slack до сих пор использует этот метод: Slack developer FAQ | Slack Developer Docs. Я понимаю, как это может упростить работу для приложения, принимающего вебхук.
Кажется, здесь есть компромисс между безопасностью и удобством при выборе метода, который будет использовать отправляющее приложение. Моя обеспокоенность по поводу метода HMAC-подписи в Discourse заключается в том, что он может привести к тому, что люди будут настраивать вебхуки без секретных ключей, чтобы обойти трудности обработки меняющихся HMAC-подписей. Например, на Meta есть несколько ссылок на отправку вебхуков Discourse в Zapier без какого-либо упоминания о том, как проверить подпись в Zapier. (Технически проверить подписи в Zapier, впрочем, возможно. На данный момент у меня нет возможности это протестировать.)
Функция вебхук-секрета реализована в соответствии с этим:
Похоже, что программное обеспечение, которое вы хотите использовать, не поддерживает этот стандартный механизм безопасной связи, но вы всё равно можете использовать вебхуки Discourse без него.
Планы по добавлению фиксированного заголовка с общим секретом отсутствуют, поскольку ценность такого подхода с точки зрения безопасности сомнительна. Однако, если это вам необходимо, это можно реализовать в виде плагина.
