В прошлой статье я предполагал, что читатель подробно знает, как работает язык запросов SQL, а также механизм протокола HTTP. Но обычно это не так.
И мне сразу вспомнилась история, описанная в одной из моих любимых книг «Недоверчивые умы» Роба Бразертона.
Там описан следующий эксперимент. Психолог Ребекка Лоусон спросила группу испытуемых, ездили ли они когда-нибудь в жизни на велосипеде? Большинство ответило утвердительно.
Далее она спросила, знают ли они, как устроен велосипед? Утвердительных ответов было меньше, но все равно подавляющее большинство.
А потом она предложила следующее изображение и попросила расширить его, чтобы на этом велосипеде можно было ездить.
И тут произошло самое интересное — больше половины людей не смогли этого сделать.
Эта обманчиво простая задача показывает, что большинство людей просто понятия не имеют, как устроен велосипед. Но самое интересное, что они не понимают, что не знают этого, а начинают понимать это лишь в тот момент, когда им приходится демонстрировать эти знания.
То же самое происходит с HTTP и SQL. SQL-запросы писали 90% ИТ-специалистов, по крайней мере, в лабораториях своих учебных заведений; люди каждый день работают с HTTP как пользователи, и те же ИТ-специалисты время от времени настраивают веб-серверы, которые действительно работают с HTTP. Но когда приходится отвечать на конкретный вопрос, регулярно наступает ступор.
Аналитик ИБ должен детально владеть технологией, зная нюансы и тонкости.
Если мы не знаем, как должна работать технология, как мы можем понять, что с ней не так?
Тоже "инъекция"
Я упоминал, что проверка ввода должна происходить на сервере, а не на клиенте.Время от времени можно встретить формы ввода, где отдельные элементы неактивны.
Ожидается, что они станут активными после выполнения определенных условий.
Или, например, поле ввода имени пользователя имеет длину 7 символов, что ограничивает максимальную длину имени пользователя.
Это все очень плохая практика, и вот почему: уже полученные элементы на странице можно произвольно редактировать перед отправкой, без каких-либо специальных технических средств.
В OWASP Mutillidae II это можно увидеть в примере «Другие» > «Элементы управления безопасностью на стороне клиента».
Перед нами форма, в поля которой нужно ввести случайное число, на этот раз это 2056694312. «Сложность» здесь в том, что поля имеют ограничения.
Есть поле «Только для чтения», где невозможно заменить число 42, есть слишком короткое поле «Короткое текстовое поле», куда наш номер просто не поместится, есть отключенное поле «Отключенное текстовое поле», которое неактивно.
, и так далее.
На самом деле проблема решается очень просто.
В браузере (в моем случае это Mozilla Firefox) нужно зайти в консоль разработчика (F12) и начать проверку элементов формы.
Например, поле, доступное только для чтения, выглядит так:
Удалим readonly="readonly" и вуаля: форма доступна для записи, можно вводить свой номер.<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Наше значение просто не помещается в следующее поле, давайте посмотрим на этот элемент: <input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Здесь мы заметим maxlength="3".
Давайте заменим 3 на 333, теперь мы можем вводить наш номер, не опасаясь, что он не подойдет. И, кстати, мы говорим не только о полях ввода.
Аналогичным образом можно изменить любые элементы, например флажки.
Код страницы выглядит следующим образом: <input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
Здесь все довольно просто, мы заменим значения на наше число, и оно будет отправлено, когда пользователь нажмет на кнопку.
В общем, если вы знаете, как работает HTML, то вам не составит труда подправить эту форму, чтобы ввести туда все необходимые данные.
Просто перечитайте раздел про велосипедный синдром =)
Не только SQL
Инъекции не всегда касаются баз данных.По большому счету, какую-то дополнительную информацию можно получить из любой формы, не фильтрующей входящие данные.
Пример Application Log Injection > DNS Lookup имеет удобную форму для DNS-запросов: 
И действительно, если вы введете туда адрес, например, google.com, вы получите всю необходимую информацию: 
Однако уязвимость в том, что помимо первой допустимой команды мы можем ввести что-то еще.
Например, укажите: google.com && dir
и теперь вывод команды гораздо интереснее: 
Мы сделали запрос к DNS-серверу, но дополнительно запустили команду dir и посмотрели, что находится в папке с нашим сайтом.
Не составит труда, комбинируя разные команды, побродить по жесткому диску веб-сервера и поискать, что не так.
В следующий раз мы рассмотрим больше примеров, а также посмотрим, как можно автоматизировать свою работу.
Вы можете прочитать блог автора по адресу эта ссылка .
Теги: #информационная безопасность #пароли #уязвимости #sql #http #стандартизация #пентест #инъекция #OWASP #owasp #инъекции #owasp топ 10 2017
-
Температура Отверждения
19 Oct, 24 -
Протокол Связи Siri Взломан
19 Oct, 24 -
Работаем Над Эскизами
19 Oct, 24 -
Работа С Номерами Версий Программы
19 Oct, 24 -
Датчики Для Умного Дома
19 Oct, 24 -
Уход Под Ключ: Как Работает Sap-Хостинг
19 Oct, 24
