Комментарии 8
Не получил ответ на вопрос "зачем вообще это все нужно".
Вот есть у меня web-приложение на GO, или даже много приложений на GO в кубере, балансировщик на HAProxy, наружу торчит 80 порт, запросы строго по спецификации. SQL-injection и другие OWASP TOP-10 отсутствуют.
Для чего мне могут понадобится обычный firewall и WAF?
Непонятно, каким образом вы смогли гарантировать, что вам будут приходить только "запросы строго по спецификации" строго от добропорядочных клиентов, что у вас нет OWASP Top 10, что у вас нет и никогда не появится уязвимостей в серверной ОС, в фреймворке, в HAProxy и т.п.
Непонятно, каким образом вы смогли убедиться, что вам будут приходить только "запросы строго по спецификации"
Приходить будут любые, обрабатываться только те которые есть в спецификации т.к. для других нет кода :)
что у вас нет OWASP Top 10
В имозрительном примере их просто не сделали. В реальных проектах они поправлены, и проверены командой QA которые специализируются на это, не рокет саинс.
что у вас нет и никогда не появится уязвимостей в серверной ОС, в фреймворке, в HAProxy и т.п.
Они есть, будут итд. Но пока открыт только 80 порт уязвимость может быть в сетевом стеке ОС (шанс 0%, иначе всё уже было взломано по кругу), в HAProxy (шанс поменьше, но аналогично, тысячи сайтов уже были бы взломаны) и мой фреймворк и мой код. Тут я могу проверить и быть увереным в результате.
А вот еще один продукт в цепочке типа WAF это штука которая как миннимум бесполезна, а скорее сама содержит ошибки и уязвимости. Проверить ее нельзя. Чет исходников для предложенной системы не нашел.
Есть с десяток веб-приложений, в числе которых легаси. Следить за ними полноценно просто дорого, дешевле взять WAF и отсечь разом море потенциальных CVE
Здесь пока первая часть статьи. Частично согласен и про Legacy и про микросервисы, только в разном контексте: если WAF для закрытия проблем, которые быстро не поправить - то первый вариант, если для включения в CI\CD на этапе тестов, для большей наблюдаемости - второй.
Интересно посмотреть на перспективы WAF в контексте API. Задача WAF - противостоять инъекциям, но если не получается составить белый список разрешённых значений, то эта задача практически невыполнима: пытливые умы так или иначе найдут способ обойти чёрный. И если бичом WAF для web-приложений были ложноположительные срабатывания (Волки! Волки!), то для API им стали ложноотрицательные (что ещё хуже). При этом в OWASP Top 10 API Security этого года инъекции уже не вошли…
Как оценить эффективность WAF и зачем вообще это все нужно. Часть 1