Комментарии 15
Когда безопасностью занимаются дилетанты вы получаете мистические ошибки, но не получаете безопасность. Эти глупые фильтры легко обходятся. Проблема не в том, что передаёт пользователь, а в том, как вы работаете с его вводом и под какими правами.
Очередной мамкин безопасник, который где-то что-то слышал, но не понял, о чём там речь. В итоге накрутил какой-то фигни, которая ни от чего не защищает, но зато создаёт кучу проблем.
Сталкивался с подобным у одного из наших клиентов. Клиент выделил нам виртуалку, чтобы мы там развернули наше ПО. Клиент сильно топит за "безопасность", потому доступ по SSH только через прокси хост, который мониторит все вводимые команды. Ну и волшебные фильтры, типа если вводишь `sudo -l`, то тебя просто выкидывает. В итоге, ты даже не можешь посмотреть, а что тебе вообще можно делать на машине.
Обходили это дело через кодирование комманд с помощью base64, типа:
bash -c "`echo c3VkbyAtbAo= | base64 -d`"
Ну, вас запустили через PAM, это понятно. Ограничение по вводимым командам на PAM - это тоже понятно, но тут странно другое - почему это ограничение делали на самой PAM, а не на конечном хосте, раз уж вам на нём sudo дали. Хотя, если это у них общая политика, а не конкретно для вас - тогда ситуация проясняется. Правда, такое ограничение, буде установлено на PAM должно формировать соответствующий алерт в SOC.
Что это за редактор такой?
Вас им заставляют пользоваться?
Вы с читателями поступаете примерно так же, как редактор с Вами.
П.С. А, это перевод.
Заметно что оригинал бусурманский, так как слегка много текста.
В комментах пишут про некомпетентных безопасников, но, скорее всего, все еще прозаичнее - это дефолтное правило WAF, который установили в компании. В подавляющем большинстве приложений передача в запросе /etc/passwd, вероятнее всего, означает, что запросы исходят от хакера или исследователя безопасности, и срабатывание WAF будет вполне оправданно. Но в данном случае не учтена специфика приложения.
Некомпетентные безопасники этот WAF и установили.
WAF не является основной мерой защиты - скорее профилактической.
В ретроспективе понятно, что стоило бы отключить данное правило. А лучше отключить сработки WAF на эндпоинты, куда пользователи отправляют текст статей или комментариев. Но заранее предусмотреть каждую мелочь - дело непростое.
Делал в Microsoft Teams задание для студентов для курса "Администрирование Linux". Если в тексте задания попадалось /etc/passwd, то задание не сохранялось. Выдавалась ошибка о попытке доступа к конфиденциальным данным.
Ну и по собственному опыту администрирования. Включил на мелком служебном хостинге WAF в Apach'е со стандартными настройками, и через пару дней уже разбирался с жалобой на то, что какая-то система ведения документации не позволяет сохранять тексты с описанием SQL запросов. При этом там же крутились самописные системы с подозрением на SQL инъекции и отключать правила полностью было очень нежелательно.
Оригинал: https://scalewithlee.substack.com/p/when-etchsts-breaks-your-substack
редактор Substack показывал «Network Error»
я намеренно его обфусцировал, чтобы не вызвать ту самую ошибку
Зачем тащить на хабр костыли, позволяющие написать на сабстаке статью об ошибках сабстака
А на хабре, на хабре-то можно написать /etc/hosts без костылей?
Как /etc/hosts поломал редактор сайта