Вместо предисловия

Давно ничего не писал - переживал последствия перенесенного ковида помноженного на некоторое подобие истощения нервной системы после сильнострессового периода.
В целом легко отделался - пью анксиолетики с антидепрессантами, неделя ушла на то, чтобы "встать на рельсы" и вернуться к полноценной работе.
Сейчас хотя бы появилась какая-то мотивация вставать с кровати, приводить себя в порядок, что-то читать, работать и всё остальное.

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

Немного печалит, конечно, что приходится пить таблетки для того, чтобы чувствовать себя "нормально". Но это время такое. Не суть.

О нулльбайтах

Ковыряя проекты крупных компаний всё чаще стал обращать внимание на то, что разработчики игнорируют необходимость очищать строки от потенциально вредоносных нагрузок, что, как минимум, приводит к тому, что я (имитируя потенциального злоумышленника) могу увидеть используемый стек технологий на бекенде.
Как пример - подставлял символы нулльбайта в запросы к API крупного банка, в результате получал небольшой кусок стактрейса с ошибкой о невозможности выполнить SQL запрос от postgresql, опираясь на который, сделал вывод о том, что с 100% вероятностью на бекенде используется SpringFramework и postgres.
Уже используя эту информацию можно было бы попробовать различные экслпойты под конкретные версии спринга и постгреса, но это не мой стиль. Мне было интересно копнуть глубже.
Само собой разумеется, что современные версии постгреса, при наличии в запросе нулльбайт-последстовательности, не выполняют запрос. Так что дальнейшие рассуждения строятся на концепции сферической эксплуатации в вакууме, где по какой-то причине нашлось применение данному типу уязвимостей за пределами контекста SQL-injection.

В чем же опасность нульбайта в стеке java+postgres? На данный момент, насколько я понял из своих жалких попыток и недели гуглежа, сами по себе нулльбайты опасности не представляют. Они могут быть использованы при наличии SQL инъекций для удаленного выполнения кода (эксплуатации RCE уязвимостей). То есть, если в продакшене БД работает от имени root, то, теоретически, я смогу выполнять команды от имени администратора.

В чем же сложность реализации защиты от нулльбайта?
Сама по себе защита от нулльбайта сводится к тому, что нам необходимо проверить строку побайтово и, при наличии нулльбайт последовательности, удалить ее из строки, после чего передать дальше. Само собой здесь встает вопрос вероятности получения "рекурсивного нулльбайта", который объявится после одноразовой очистки строки. А значит необходимо очищать строку побайтово до тех пор пока она не будет полностью очищена.

Сам код для java выглядит подобным образом:




Вообще, в целом, встает вопрос о написании какой-то либо универсальной функции, которую нужно будет вызывать каждый раз при получении какой-то либо переменной со стороны клиента (которому мы, следуя концепции zerotrust, не доверяем).
Функция эта выглядела бы подобным образом:




Собственно, проблема в том, что слишком сложно поставить задачу разработчикам фильтровать полученные со стороны клиента переменные.

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

И эксплуатация нулльбайтов в контекстах отличных от SQLinj - лишь вопрос времени и желания исследователей безопасности.