В прошлой статье я предположил, что читатель знает, как устроен язык запросов SQL в подробностях, а также механизм работы протокола HTTP. Но это, как правило, не так. И я сразу вспомнил историю, описанную в одной из моих любимых книг «Недоверчивые умы» Роба Бразертона. В ней описан следующий эксперимент. Психолог Ребекка Лоусон спросила у группы испытуемых, катались ли они в своей жизни хоть раз на велосипеде? Большинство ответило утвердительно. Далее она спросила, знают ли они, как устроен велосипед? Утвердительных ответов было уже поменьше, но всё равно подавляющее большинство. А затем она предложила следующее изображение и попросила дополнить его так, чтобы на этом велосипеде можно было ездить.
А дальше произошло самое интересное – более половины людей не смогли этого сделать. Эта обманчиво простая задача показывает, что большинство людей просто не представляет как устроен велосипед. Но самое интересное, что они не понимают, что они этого не знают, а начинают понимать это только в момент, когда им предстоит продемонстрировать эти знания.
C HTTP и SQL происходит примерно то же самое. SQL-запросы писали 90% ИТ-специалистов, хотя бы на лабораторных в своих учебных заведениях, с HTTP люди работают каждый день как пользователи, а те же ИТ-специалисты время от времени настраивают веб-серверы, которые собственно с HTTP и работают. Но когда приходится ответить на конкретный вопрос, регулярно наступает ступор.
Аналитик информационной безопасности должен владеть технологиями подробно, зная нюансы и тонкости. Если мы не знаем, как должна работать та или иная технология, то как мы можем разобраться, что с ней не так?
Я упомянул, что проверка вводимых данных должна происходить на сервере, но никак не на клиенте. Периодически можно встретить формы ввода, где неактивны отдельные элементы. И предполагается, что они станут активными после выполнения определенных условий. Или, например, поле ввода имени пользователя имеет длину 7 символов, таким образом ограничивая максимальную длину имени пользователя. Всё это очень плохая практика и вот почему: элементы на странице, которые уже получены, могут быть произвольно отредактированы перед отправкой, причем без каких-либо специальных технических средств. В OWASP Mutillidae II это можно посмотреть в примере «Others» > «Client-side «security» Controls».
Перед нам форма, в поля которой нужно ввести случайное число, в этот раз это 2056694312. «Сложность» тут в том, что поля имеют ограничения. Есть поле «Read-only», где число 42 заменить нельзя, есть слишком короткое поле «Short text box», куда наше число просто не влезет, есть отключенное поле «Disabled Text Box», которое неактивно, и так далее.
На самом деле, задача решается очень просто. В браузере (в моем случае это Mozilla Firefox) нужно перейти в консоль разработчика (F12) и начать инспектировать элементы формы.
Вот, например, поле, доступное только для чтения, выглядит так:
Удалим readonly=”readonly” и вуаля: форма доступна для записи, можем ввести наше число.
В следующее поле наше значение просто не влезает, посмотрим на этот элемент:
Тут мы заметим maxlength=”3″. Заменим 3 на 333, теперь мы можем вводить наше число, не опасаясь, что оно не поместится.
И речь, кстати, не только о полях ввода. Подобным образом можно поменять любые элементы, например чек-боксы. Код страницы выглядит так:
Тут совсем просто, заменим значения value на наше число, и вот оно уже будет отправлено, когда пользователь нажмет на кнопку.
Итого, если вы знаете, как устроен HTML, то вам не составит труда исправить эту форму так, чтобы ввести туда все нужные данные. Просто перечитайте раздел про Синдром велосипеда =)
Инъекции это не всегда про базы данных. По большому счету, из любой формы, которая не фильтрует входящие данные, можно получить какую-то дополнительную информацию. В примере «Application Log Injection» > «DNS Lookup» есть удобная форма для DNS-запросов:
И действительно, если ввести туда адрес, например, google.com, то получим все необходимые сведения:
Однако, уязвимость состоит в том, что кроме первой валидной команды, мы можем ввести, что-то еще. Например, указать:
и вот уже вывод команды куда интереснее:
Мы выполнили запрос к DNS-серверу, но кроме этого, выполнили команду dir и посмотрели, что лежит в папке нашим сайтом. Не составит труда, комбинируя разные команды, побродить по жесткому диску веб-сервера и поискать, что плохо лежит.
В следующий раз мы разберем еще примеры, а также посмотрим, как можно автоматизировать свою работу.
Прочитать блог автора статьи можно по этой ссылке.
А дальше произошло самое интересное – более половины людей не смогли этого сделать. Эта обманчиво простая задача показывает, что большинство людей просто не представляет как устроен велосипед. Но самое интересное, что они не понимают, что они этого не знают, а начинают понимать это только в момент, когда им предстоит продемонстрировать эти знания.
C HTTP и SQL происходит примерно то же самое. SQL-запросы писали 90% ИТ-специалистов, хотя бы на лабораторных в своих учебных заведениях, с HTTP люди работают каждый день как пользователи, а те же ИТ-специалисты время от времени настраивают веб-серверы, которые собственно с HTTP и работают. Но когда приходится ответить на конкретный вопрос, регулярно наступает ступор.
Аналитик информационной безопасности должен владеть технологиями подробно, зная нюансы и тонкости. Если мы не знаем, как должна работать та или иная технология, то как мы можем разобраться, что с ней не так?
Тоже «инъекция»
Я упомянул, что проверка вводимых данных должна происходить на сервере, но никак не на клиенте. Периодически можно встретить формы ввода, где неактивны отдельные элементы. И предполагается, что они станут активными после выполнения определенных условий. Или, например, поле ввода имени пользователя имеет длину 7 символов, таким образом ограничивая максимальную длину имени пользователя. Всё это очень плохая практика и вот почему: элементы на странице, которые уже получены, могут быть произвольно отредактированы перед отправкой, причем без каких-либо специальных технических средств. В OWASP Mutillidae II это можно посмотреть в примере «Others» > «Client-side «security» Controls».
Перед нам форма, в поля которой нужно ввести случайное число, в этот раз это 2056694312. «Сложность» тут в том, что поля имеют ограничения. Есть поле «Read-only», где число 42 заменить нельзя, есть слишком короткое поле «Short text box», куда наше число просто не влезет, есть отключенное поле «Disabled Text Box», которое неактивно, и так далее.
На самом деле, задача решается очень просто. В браузере (в моем случае это Mozilla Firefox) нужно перейти в консоль разработчика (F12) и начать инспектировать элементы формы.
Вот, например, поле, доступное только для чтения, выглядит так:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />Удалим readonly=”readonly” и вуаля: форма доступна для записи, можем ввести наше число.
В следующее поле наше значение просто не влезает, посмотрим на этот элемент:
<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" />Тут совсем просто, заменим значения value на наше число, и вот оно уже будет отправлено, когда пользователь нажмет на кнопку.
Итого, если вы знаете, как устроен HTML, то вам не составит труда исправить эту форму так, чтобы ввести туда все нужные данные. Просто перечитайте раздел про Синдром велосипеда =)
Не только SQL
Инъекции это не всегда про базы данных. По большому счету, из любой формы, которая не фильтрует входящие данные, можно получить какую-то дополнительную информацию. В примере «Application Log Injection» > «DNS Lookup» есть удобная форма для DNS-запросов:
И действительно, если ввести туда адрес, например, google.com, то получим все необходимые сведения:
Однако, уязвимость состоит в том, что кроме первой валидной команды, мы можем ввести, что-то еще. Например, указать:
google.com && dirи вот уже вывод команды куда интереснее:
Мы выполнили запрос к DNS-серверу, но кроме этого, выполнили команду dir и посмотрели, что лежит в папке нашим сайтом. Не составит труда, комбинируя разные команды, побродить по жесткому диску веб-сервера и поискать, что плохо лежит.
В следующий раз мы разберем еще примеры, а также посмотрим, как можно автоматизировать свою работу.
Прочитать блог автора статьи можно по этой ссылке.
