Как состязательный цикл применим к кодированию и безопасности?

Большинство проблем с безопасностью приложений возникают из-за ошибок в программном обеспечении, из-за которых существующие меры безопасности выходят из строя.

Однако даже если код идеален, это не значит, что злоумышленник не может его использовать.

Уязвимость может быть скрыта внутри бизнес-логики, а не в коде, который ее обеспечивает.

Этот тип уязвимости называется уязвимостью бизнес-логики. Это когда злоумышленник злоупотребляет законным потоком приложения, что приводит к негативным последствиям.

Примером может быть контактная форма на веб-сайте, которая используется для отправки электронных писем владельцам службы. Эту форму можно использовать для отправки спам-сообщений вместо настоящих запросов в службу поддержки.

Имея дело с уязвимостями бизнес-логики, мы входим в ветвь безопасности, называемую защитой от злоупотреблений. Борьба со злоупотреблениями часто требует более творческого подхода к этим проблемам, потому что, в отличие от исправления ошибок в коде, бизнес-логику часто нельзя изменить, чтобы снизить риск.

Мы застряли в ситуации, когда не можем решить проблему, мы можем только управлять ею. Это требует активного участия, потому что злоумышленник изменит тактику, когда мы установим защитные механизмы.

Вот что делает ее состязательной проблемой. Чтобы лучше понять это, давайте посмотрим на следующую диаграмму.

Таким образом, обороняющийся непосредственно контролирует этапы 1 и 2, а атакующий напрямую контролирует этапы 3 и 4. Однако оба противника косвенно контролируют весь цикл.

Цель игры для злоумышленника — убедиться, что атака не будет обнаружена. Если это так, они должны быть в состоянии изменить планы достаточно быстро, чтобы попробовать другой подход.

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

Переводя это на диаграмму, злоумышленник хочет, чтобы переходы 1 и 2 были как можно более длинными, а переходы 3 и 4 — как можно короче. Напротив, защитник хочет, чтобы переходы 3 и 4 занимали очень короткое время, но растягивали переходы 1 и 2.

Итак, вам может быть интересно, как это можно применить на практике? 🤔

Как защитник, легко попасть в ловушку, тратя слишком много времени на интуитивные решения, которые не сильно усложняют жизнь злоумышленнику. Я приведу вам пример.

Допустим, нам нужно защитить контактную форму, упомянутую ранее, от рассылки спама. Мы видим, что злоумышленники используют bash-скрипт, что отражено в заголовке User-Agent.

Естественно, вы можете подумать, что мы должны блокировать все попытки, исходящие от этого конкретного User-Agent. Так как мы не хотим, чтобы спам рассылался, мы блокируем попытку прямо на странице.

Однако только что произошло то, что мы дали противникам очень тесную петлю обратной связи, чтобы выяснить нашу защиту.

Чтобы обойти это, им просто нужно подделать User-Agent, чтобы он выглядел как браузер. Это простое изменение с их стороны, и они снова в деле. Нехорошо для нас, теперь их стало труднее обнаружить.

Атакующие становятся сильнее, когда мы сражаемся с ними. Память о состязательном цикле помогает нам избежать первоочередного мышления и оценить последствия интуитивного решения.

Совместно опубликовано [здесь] (https://blackfedora.dev/adversarial-cycle)