Как я смог обойти Cloudflare WAF для SQLi пэйлоада

Эта статья носит исключительно образовательный характер. Автор не несет ответственности за любые последствия ее прочтения.

Данная статья является переводом и ведется со слов автора. Оригинал тут.

Привет, хакеры и хантеры!

Cloudflare привел к неудачам многих людей, которые хотели достичь критических уязвимостей, таких как: SQL injection, потому что, к сожалению, он блокирует большинство (почти все) полезных нагрузок. Итак, я искал уязвимость на таргете и использовал свое мышление, чтобы обойти и сломать этого зверя!

Я решил использовать полезную нагрузку для Boolean Based SQL Injection. Вы должны знать, что самым важным этапом является этап обнаружения плохих символов, которые блокирует WAF (брандмауэр веб-приложений).

В моём случае, после множества попыток я обнаружил, что брандмауэр блокирует следующее:

• пробелы
• OR/ AND во всех случаях
• -- comment
• # comment
• ;
• =

Итак, давайте подумаем, как мы можем обойти их, разделив эту статью на разделы:

Обход для пробелов

Чтобы обойти пробел, я подумал о том, чтобы использовать URL кодировку, например: используя: %20, но это не сработало. Также, я попытался поставить: + вместо пробела, но это тоже не сработало, поэтому я попытался мыслить творчески, добавив многострочный комментарий вместо пробелов: /**/ . Теперь, WAF пропустит его как обычную строку, но когда он отправится в серверную СУБД, он будет проанализирован как комментарий, это будет выглядеть как-то так:

Итак, это обычная конструкция запроса SELECT с многострочным комментарием. Вот также живой пример:

Обход логических ограничений

Теперь WAF блокирует все логические операторы. Я попробовал разные техники записи в прописном или малом регистре, для выполнения логических операторов, таких как oR/aNd .. и т.д. Но, к сожалению, в моем случае WAF также блокирует все это. Поэтому, я подумал о стандартной URL кодировке, при которой заблокированные операторы будут похожи на:

oR -> %6fR

Но, к сожалению, брандмауэр заблокировал это, а значит нужно подумать о нестандартной кодировке, которая в большинстве случаев не попадает в WAF, и, наконец мы получаем:

oR -> %256fR

Теперь я столкнулся с новой проблемой: символ = заблокирован. Но теперь я знал слабое место этого WAF, которое заключается в нестандартной кодировке, поэтому я сделал нестандартную кодировку и получил полезная нагрузка вида:

= -> %253d

Но, к сожалению, если вы поставите после этого какое-либо значение, вы просто будете заблокированы, поэтому я подумал:

• Мы хотим достичь значения True, используя логическую SQL инъекцию и брандмауэр блокирует все, что после нестандартного кодирования символа =
• И тут я подумал, почему бы не получить True с помощью другого метода, например, если сказать: 50!=22, что, безусловно, будет истинно и вернёт нам True, так как 50 не равно 22

Поэтому я сделал нестандартную кодировку для !=:

!= -> %2521%253D

Обход для концовки полезной нагрузки

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

;# -> %253B%2523

Конечный результат полезной нагрузки:

На этом все. Спасибо за просмотр!