• Открыта запись на вторую часть курса по анонимности и безопасности в сети интернет "Paranoid II" от команды codeby. Анонимные роутеры, Подъём, настройка и администрирование Tor-ноды, Работа с железом ПК, Удаление аппаратных закладок, Минимизация рисков, Авторские разработки и многое другое. Подробнее ...

  • Напоминаем, что 1 декабря стартует курс "Тестирование Веб-Приложений на проникновение с нуля" от команды codeby. Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, активный фаззинг, уязвимости, пост-эксплуатация, инструментальные средства, Social Engeneering и многое другое. Подробнее ...

Конкурс Как стать хакером и как взломать сайт или беглое знакомство с OWASP Testing Guide

larchik

larchik

Grey Team
07.06.2019
114
263
Статья для участия в конкурсе на codeby.

Здравствуйте.
Как вы уже поняли, в этой статье я попробую ответить на два самых часто задаваемых вопроса на тематических форумах.

Статья состоит из двух частей.
В первой части мои пространные рассуждения о новичках в ИБ и сложном тернистом пути, который предстоит пройти начинающим хакерам. Можете смело пропустить эту часть, если вы любите больше конкретики.
Во второй части я кратко опишу большинство разделов OWASP Testing Guide – методологии тестирования веб-приложений. Данная методология – это и есть ответ на вопрос в заголовке статьи.

Если вы еще не знакомы с данной методологией, с ТОП 10 уязвимостей по версии OWASP и вообще не знаете об организации OWASP, настоятельно рекомендую ознакомиться с их официальным сайтом. Так же на Википедии есть статья об этой организации.




Конечно работа хакера — это во многом творческая работа и тупое следование методологии не сделает из вас настоящего хакера. Нужно наблюдать, думать, анализировать, эксперементировать, выявлять закономерности и находить необычное поведение в тестируемой системе, искать нестандартные подходы к тестированию и постоянно учиться, учиться, учиться. Вместе с этим во время пентеста вам придется выполнять много рутинной работы, от которой никуда не деться, но эта работа фундаментально важна.

Моя статья предназначена новичкам, которые хотят, наконец, начать свой путь, но не знают, как и с какой стороны подступиться. А начать с нуля, как мы все знаем, не так-то просто.

Во-первых в сфере Информационной Безопасности очень много разных направлений. В одном месте ты прочитал статью о SQL-инъекциях в веб-приложениях, в другом о реверcе андроид-приложений, в третьем о написании эксплоита для повышения привелегий в linux, а в четвертом что-то о каком-то meterpreter... что это вообще? Как разобраться в этой каше?

Во-вторых в сети очень много информации о хакинге в целом и о пентесте веб-приложений в частности. Даже в Рунете ее столько, что из него можно не вылазить пару-тройку лет, изучая эту информацию и перенимая опыт, пока ты наконец поймешь, что можно двинуться дальше и перенимать опыт уже у англоязычных коллег. Ориентироваться в таком количестве информации новичку очень сложно. Ты видишь сотни статей с обзорами разных утилит, сканеров, техник атак, новых и старых уязвимостей, кучу историй успешных взломов с примерами, но все равно спрашиваешь:
“Как взломать сайт?!”.
Я не осуждаю таких вопрошателей, потому что сам считаю себя новичком, и столкнулся (и продолжаю сталкиваться до сих пор) с теми же проблемами, что и вы.

Тем не менее начинать с чего-то надо. Как начал я?
Если начинать с самого начала, то рассказ начнется с приставки СЮБОР, каким-то чудом оказавшейся в нашем доме, когда мне было лет 12. Но тогда текста наберется на широкую и длинную простыню, поэтому постараюсь кратко и начну с тех времен, когда ИБ я занялся довольно плотно.

Несколько лет назад я набрел на один из фрикерских форумов (речь идет о фрикерах, а не фриках), где в одном из разделов обсуждалась сборка и программирование кодграббера на базе Ардуино для автосигнализаций. Для тех, кто не знает, кодграббер - это такая штука, которая перехватывает радиосигналы, которыми обменивается брелок с головной частью сигнализации. Ардуино - это такая плата с микроконтроллером, на базе которой можно построить несложную автоматизированную систему, например робота или кодграббер. Именно в то время я познакомился с программированием близко, хотя попытки писать программы предпринимались и ранее.

Меня так увлекла эта тема, что я заказал на Али себе плату Ардуино, купил на Авито брелок от FM-сигнализации, и принялся конструировать свой собственный кодграббер. Затея почти удалась, но сейчас не об этом. Очень скоро моя любознательность расширилась на сферу безопасности веб-приложений. Так я и нашел этот форум, нашел тут книгу о Кали Линукс и почти сразу же принялся изучать инструменты этой операционной системы.

В первый раз надолго меня не хватило. Гидра совершенно ничего не брутила, вывод nmap'а мне абсолютно ни о чем не говорил, а Метасплоит для меня был вообще чем-то за гранью реальности (собственно и сейчас я не особо им умею пользоваться). В общем я забыл про виртуалку с Кали и надолго забросил это дело.

Шло время, я иногда почитывал статьи по хакингу, продолжал ходить на работу на завод, время от времени поигрывал в Colobot ( ). Где-то через пол-года после первого знакомства с Codeby и Kali, мне на глаза попалась статья о SQL-инъекциях. Надо сказать, что сама аббревиатура SQL для меня не значила ровным счетом ничего. Так вот, статья мне так понравилась, что я решил попробовать свои силы снова, и на этот раз у меня получилось.

Я никогда не забуду ту ночь. Мой первый взломанный сайт! Воистину, ощущения сравнимы с первым сексом, а может быть даже и ярче :) У меня тряслись руки, потели ладони, я бегал курить каждые пол часа, и я совершенно не знал, что мне делать с этим взломанным сайтом. Мне хотелось об этом кому-то рассказать, очень-очень. Но я не мог рассказывать, так как жутко боялся, что в мою дверь постучат и меня уведут куда-то в наручниках, да и к тому же это была глубокая ночь и все мои друзья, слава богу, спали.

Тогда с помощью SQL-инъекции, следуя инструкциям из статьи об инъекциях на форуме rdot (ссылку на статью приведу ниже, во второй части статьи), я вручную смог вытащить из базы данных логины и хеши паролей админов сайта. Про sqlmap в то время мне было ничего не известно, что делать с хешами я тоже не знал, но это было совершенно не важно в тот момент. Я был по-настоящему счастлив и горд собой!

Пароли я сбрутил позже с помощью инструмента под названием hashcat ( ). Хешей было несколько десятков (до сих пор не понимаю, зачем на сайт нужно несколько десятков админов, это очень небезопасно) и большинство из них конечно было вида 123456, qwerty, и тд.

Я стал дальше изучать этот сайт с целью найти его админку. Так я познакомился с утилитой под названием dirb ( ). Но с его помощью мне не удалось найти ничего интересного. Тогда я узнал об операторах поисковых систем и принялся гуглить, вдруг админка проиндексировалась. Но и тут меня ждала неудача. Поиск по доменам третьего уровня, типа admin.test.com, мне тоже ничего не дал. Я уже начал огорчаться, но удача пришла с другой стороны (и, как выяснилось потом, так происходит часто). Я обнаружил, что на сервере есть еще несколько сайтов того же владельца. И вот на одном из этих сайтов админка нашлась, и как вы понимаете, найденные мной логины и пароли подходили. Бинго!

Именно с тех пор, иногда с перерывами в 3-4 недели, я продолжаю изучать и практиковаться в ИБ и больше не бросал это занятие и не отчаивался, так как тот первый успех окрылил меня.

Через некоторое время мои знания, которые я продолжал получать в основном на форумах, немного утряслись и стали систематезироваться в моей голове. Я стал понимать, где добывать нужную мне информацию и какая именно информация мне нужна в данный момент. Тот темный лес, в котором я блуждал несколькими месяцами ранее, стал приобретать какие-то, едва различимые, очертания.

Пожалуй, самое главное, чему я научился в то время - терпению и гуглению.
Терпение - это то, что нужно новичку. Нам не терпится побыстрее нахакать сайтов. Новичок думает, что хакеры щелкают сайты, как семечки. Нет, мои друзья, это не так. Обычно взлому предшествует долгая и кропотливая, часто рутинная работа, и скоро ты это сам увидишь.
Умение гуглить - едва ли не самый важный фактор, который поспособствует твоему становлению, как хакера. На любом хакерском форуме мы все видим одни и те же вопросы, и одни и те же ответы на них: “Иди ты в Гугл со своими вопросами”.

Однажды я зарегистрировался на одном таком форуме с целью задать вопрос и был очень грубо послан в гугл. С тех пор вопросы на тему взломов я не задавал никому, кроме гугла (яндекса, бинга etc) и с удивлением обнаружил, что в сети есть всё. Примите как факт, что тот вопрос, который у вас возник, уже тысячи раз возникал в других умах, и на него точно уже где-то ответили.

Так, еще через некоторое время с помощью гугла и терпения я узнал о такой организации, как OWASP, о их Топ 10 уязвимостей и методологии тестирования. Именно об этом гайде и пойдет дальше речь. Ты спрашивал, как взломать сайт? Получи ответ.

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

Кстати, возьмите на заметку (те, кто не знает английский), пока я читал руководство с переводчиком, уровень моего английского вырос с нуля настолько, что это же руководство я смогу прочитать уже без словаря (ну почти).

В русском переводе в полном виде этого руководства в настоящее время не существует. Неоднократно предпринимались попытки перевода разными людьми (во второй части будут ссылки), даже существует открытый проект по его переводу ( ), но полностью перевод так никто и не осилил.
Пользуясь случаем, призываю неравнодушных юзеров присоединиться к переводу. Так как в ходе изучения этого гайда я делал множество заметок для себя, то сам присоединяюсь к переводу, несмотря на то, что мой английский оставляет желать лучшего.

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

В ходе изучения гайда не пренебрегайте другими источниками информации. Например, если вы читаете главу о CSRF, не поленитесь и прочтите об этой уязвимости статью в Википедии, на Хабре, на Кодебай, на Хакере, на других ресурсах. Если вам в ходе изучения материалов непонятны какие-то термины, остановитесь и загуглите их. Так вам будет гораздо легче усваивать знания. А так же не забывайте о практике. Установите себе уязвимую виртуальную машину, например bWAPP ( ), и отрабатывайте то, что в настоящий момент изучаете.

Далее, как обещал, вторая часть статьи с краткими описаниями и ссылками.
Внимание: переводы некоторых разделов, которые есть на сайте defcon.ru, могут быть устаревшими, но в целом отражают суть. В любом случае рекомендую читать оригинал, даже если сначала кажется очень трудно и долго. Дальше станет легче и вы даже не заметите, как все реже и реже обращаетесь к переводчику. Статьи по ссылкам тоже могут показаться вам устаревшими, но это не так. Многие уязвимости и техники их эксплуатации не потеряли своей актуальности с нулевых годов по сей день.


Часть вторая. Как взломать сайт. Краткое описание разделов OWASP Testing Guide.


Начать нужно с поиска утечек информации с помощью поисковых систем.

Индексы поисковых систем могут содержать страницы веб-приложения, не предназначенные для индексации. Один из ярких примеров недавнего времени, когда Google документы (в том числе с приватной информацией) были проиндексированы Яндексом, Bing'ом, самим Google и другими поисковиками.
В индексе поисковых систем могут оказаться логины и пароли пользователей, файлы баз данных, скрытые URL (например доступ к админ. интерфейсу), приватная информация о владельцах и админах сайта, и т.д.
Разные поисковики могут выдавать разную информацию. Например я заметил, что выдача Bing зачастую отличается от выдачи Яндекса и Гугла. Кроме того, существуют поисковые системы, специально предназначенные для поиска уязвимых устройств в сети. Я знаю один — .
Изучите поисковые операторы для каждого поисковика, так вы сможете искать по конкретному сайту, по URL, по файлам, по регионам, по датам и по другим параметрам.




Поиск утечек информации в метафайлах веб-сервера, а так же в комментариях исходного кода веб-страниц и метаданных веб-страниц.
Файл robots.txt, а так же комментарии к исходникам страниц сайта и теги META, могут содержать чувствительную информацию. Например разработчик в ходе написания кода сайта оставил для себя или своего коллеги комментарий в коде, содержащий логин и пароль тестового пользователя и перед релизом приложения забыл подчистить комментарии. Если вы обнаружите что-то подобное, то сможете хакнуть сайт, по существу еще даже не начав его взламывать.

Соответствующий раздел OWASP Testing Guide

Перевод раздела OWASP Testing Guide



Определение всех приложений на сервере.
На одном физическом сервере может находиться много сайтов и приложений. Любое из них может оказаться уязвимым и пустить вас на целевой сервер. Я для этих целей использую онлайн-сервисы, типа 2ip.ru, а так же брут DNS, nmap и поисковые системы.
В первой части статьи я привел пример, чем может грозить уязвимость всего лишь одного сайта для остальных приложений на сервере.




Определение точек входа.
Точки входа веб-приложения - это те места в приложении, где на сервер отправляются какие-то пользовательские данные. Чаще всего это GET и POST запросы, файлы cookie. Это важно, так как огромное количество уязвимостей приложений связано именно с неправильной обработкой пользовательских данных. В дальннейшем каждую из точек входа нужно протестировать на эти уязвимости.




Определение веб-сервера, фреймворка веб-приложения и самого веб-приложения.
Если вам известен вебсервер, фреймворк приложения, то вы сможете изучить его структуру, установив себе этот фреймворк, нагуглить известные уязвимости или слабые места. Тоже самое с веб-приложением, например, это может быть какая-то популярная CMS (Wordpress, OpenCart).

Соответствующий раздел OWASP Testing Guide
, ,
Перевод раздела OWASP Testing Guide
, ,


Тестирование конфигурации инфраструктуры и конфигурации приложения.
На данном этапе нужно собрать как можно больше информации о том, какой софт используется для работы целевого сайта и как он сконфигурирован. Файерволл, СУБД, почтовые службы, прокси-сервер и тд, все компоненты нужно по возможности определить. Определив версии ПО вы сможете поискать для них эксплоиты и известные уязвимости в открытом доступе, например на сайте . Кроме того, зная, какой софт используется в инфраструктуре, вы можете самостоятельно установить его на свой компьютер (если такой софт доступен) и изучить его работу изнутри, а часто и исходный код.

Соответствующий раздел OWASP Testing Guide
,



Исследование расширений файлов.
Определите, какие расширения используются в приложении - html, php, py, asp, jsp и тд., так можно определить, какие технологии используются в инфраструктуре. Кроме того, проверьте, какие типы файлов и с какими расширениями можно загрузить на сервер.




Обнаружение старых версий сайта, резервных копий, нежелательных файлов.
Иногда в ходе тестирования удается обнаружить на веб-сервере скрытые или забытые файлы, старые версии приложения, резервные копии. В таких файлах может содержаться информация, раскрывающая структуру веб-приложения или учетные данные пользователей.
В поиске вам так же поможет гугл, например вы можете обнаружить в поисковой выдаче что-то вроде “ . Кроме гугла используйте такие утилиты, как dirb и girbuster (брут директорий), fierce (dns-брут).




Обнаружение административных интерфейсов и тестирование надежности паролей в найденых интерфейсах.
С помощью тех же dirb, fierce и Гугла постарайтесь найти все админ. интерфейсы. Кроме, собственно, админки, это может быть вход в корпоративную почту через веб, какая-нибудь cPanel, или вообще админка от старой версии сайта. Так же используйте nmap, он покажет открытые порты, на которых тоже могут висеть какие-то интерфейсы для входа, например ssh или telnet.




Тестирование HTTP-методов.
Нужно определить, какие HTTP-методы поддерживаются веб-сервером. Кроме GET и POST есть множество других методов и сервер может реагировать на них весьма неожиданно. Стоит обратить внимание на метод TRACE. Если этот метод поддерживается сервером, становится возможной атака XST.





Тестирование HSTS.
HTTP Strict Transport Security - механизм, который активирует защищенное соединение по протоколу HTTPS. Нужно проверить, используется ли данный механизм на целевом веб-сайте.




Тестирование кросс-доменных политик.
Если файлы, регулирующие кросс-доменный доступ, неправильно сконфигурированы, то появляется возможность проведения атаки Cross-site Request Forgery и доступа к различной чувствительной информации.




Идентификация пользователей.
Определение ролей пользователей.
Определите, какие роли существуют в приложении для пользователей - гость, зарегистрированный пользователь, модератор, администратор и тд.




Тестирование процесса регистрации и “угадывание” имен других пользователей, определение политики образования имен пользователей.
Иногда по реакции веб-приложения можно определить, существует ли в системе пользователь с определенными учетными данными. Используя такую особенность приложения, вы можете выявить имена существующих пользователей, что значительно повысит ваши шансы на успех в дальнейшем при подборе паролей. Если пользователям назначаются имена по какому-то алгоритму, то так же есть вероятность угадать имена других юзеров, поняв алгоритм. Имейте ввиду, что кроме имен пользователям может присваиваться какой-нибудь другой идентификатор (id123456, напрмер).

Соответствующий раздел OWASP Testing Guide
, , ,
Перевод раздела OWASP Testing Guide
, , ,


Аутентификация.
Передаются ли учетные данные по защищенным каналам
Проверьте, когда вы логинитесь в приложении, как отправляются ваши логин и пароль? Для сайта хорошо, если данные отправляются по протоколу HTTPS, для хакера - если по HTTP, то есть в открытом виде. В таком случае есть вероятность, что хакер сможет перехватить учетные данные.




Тестирование учетных данных по умолчанию.
Часто в веб-приложениях используется программное обеспечение, которое работает “из коробки”. Для первоначальной авторизации в таком софте используются учетные данные по умолчанию. Если после установки программное обеспечение небыло настроено должным образом, дефолтные логин и пароль могут остаться в системе неизменными. Эти дефолтные пары логин/пароль для разного программного обеспечения можно посмотреть в официальной документации к ПО или просто нагуглить.




Тестирование механизма блокировки аккаунтов.
Механизмы блокировки аккаунтов используятся для предотвращения атак, связанных с подбором паролей (подбором ответов на секретные вопросы, перебором директорий и тд). Например, аккаунт может блокироваться на какое-то время после 10-ти неудачных вводов пароля, тем самым затрудняя возможность атаки методом перебора.




Обход схемы аутентификации.
Халатность, незнание или простое пренебрежение правилами безопасности часто приводят к схемам аутентификации, которые можно обойти просто пропустив страницу аутентификации и напрямую запросив страницу, доступ к которой должен получать только аутентифицированный пользователь. Довльно частый случай, например, когда приложение позволяет неаутентифицированным юзерам получить доступ к FCKeditor, который в свою очередь позволяет углубить атаку. Кроме того, аутентификацию можно обойти, подделывая запросы и обманывая приложение, заставляя его думать, что пользователь уже аутентифицирован.




Выявление слабых мест в кэше браузера.
Конфиденциальная информация пользователей не должна сохраняться в кэше браузера, так как в некоторых случаях можно извлечь ее из кэша.
Например вы совершаете покупку в интернет-магазине со своего рабочего компьютера. Заполняете форму оплаты на сайте, вводите данные своей карты, а потом передумываете и вводите в адресную строку codeby.net. Тут вас отвлек начальник или клиент и вы ушли с рабочего места. Злой коллега, который сел за ваш компьютер и обнаружил открытую страницу с codeby.net, взял да и нажал кнопку «назад» в браузере и попал в интернет-магазин, где вы собирались что-то купить. Если ваши данные были сохранены в кэше браузера, вероятно они отобразятся в полях ввода и предстанут взору вашему коллеге.



Тестирование надежности политики паролей.
Самые часто используемые пароли в мире - 123456, password и qwerty. Если приложение позволяет создавать пользователям слишком простые пароли, подобные этим, то политика паролей приложения, очевидно, не является надежной.



Тестирование политики секретных вопросов/ответов.
Многие веб-приложения реализуют функцию секретных вопросов/ответов таким образом, что ответы на эти секретные вопросы легко угадываются. Например, такие данные, как дата вашего рождения, любимый фильм или певец, кличка первого домашнего питомца, девичья фамилия матери и тд, обнаруживаются в соц.сетях жертвы либо подбираются методом перебора по словарю.



Тестирование функции восстановления, сброса и изменения пароля.
Придет ли забытый пароль на почту в открытом виде? Такое поведение будет указывать на то, что пароли хранятся в базе данных в открытом виде. Если новый пароль генерируется автоматически, можно ли его предсказать? Он придет на ту почту, которую указывали при регистрации или адрес можно как-то изменить в ходе восстановления?



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



Обнаружение уязвимостей Directory traversal/file include.
Используя эту уязвимость, можно читать директории и файлы, которые обычно нельзя прочитать, получать доступ к данным вне корня сайта или подключать скрипты к сайту и другие виды файлов с внешних ресурсов.



Обход схемы авторизации.
На данном мы получим ответы на следующие вопросы: можно ли получить доступ к ресурсу, даже если пользователь не аутентифицирован? Можно ли получить доступ к ресурсу даже после выхода из системы? Можно ли получить доступ к функциям, которые доступны пользователям с другими привелегиями? Можно ли получить доступ к административным функциям обычному пользователю?



Повышение привелегий.
Повышение привелегий происходит, когда пользователь получает доступ к большему количеству ресурсов и функций, чем ему разрешено правилами приложения. Различают веритикальное повышение - когда пользователь получает доступ к функциям администратора, и горизонтальное - когда пользователь получает доступ к функциям других пользователей, наделенных теми же правами.



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



Обход схемы управления сессиями.
Что бы пользователю не пришлось при каждом обращении к сайту вводить свой логин и пароль, сайты используют файлы cookie. С помощью cookie сессия сохраняется активной долгое время. Если cookie слабые (можно понять алгоритм, по которому они формируются и присваиваются), их можно подделать и с их помощью создать новую сессию.



Захват сессии.
Файлы cookie должны своевременно обнуляться и переиздаваться. Если этого не происходит, то в случае перехвата cookie возможен захват сессии жертвы.



Раскрытие переменных сессии.
Передача файлов cookie от сайта к пользователю должна происходить по защищенному каналу, что бы исключить возможность перехвата. Требования к передаче cookie, токенов сессии и других идентификаторов могут быть выше, чем требования к передаче других конфиденциальных данных.



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




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



Session Puzzling.




XSS. Межсайтовый скриптинг.
Тип атаки, заключающийся во внедрении вредоносного кода в какую-то из страниц сайта, который будет выполнен на компьютере пользователя при открытии им этой страницы. В этот момент у пользователя могут быть украдены cookie, перехвачены пароли, выполнена подмена выдаваемого контента и другие вредоносные действия.
Различают отраженные XSS и хранимые XSS.

Соответствующий раздел OWASP Testing Guide
,



Подделка HTTP-методов.
Cпецификация HTTP включает в себя множество методов, отличных от стандартных GET и POST. Веб-сервер может реагировать на альтернативные методы способами, которые не были предусмотрены разработчиком, что в свою очередь может привести к раскрытию конфиденциальной информации, выполнению действий без аутентификации или другим нарушениям работы приложения.




Загрязнение HTTP-параметров (HPP).
Данная уязвимость возникает, когда веб-сервер аномально реагирует на получение нескольких HTTP-параметров с одинаковыми именами. Используя эти аномалии, можно обойти фильтрацию входных данных, изменить значения внутренних переменных, вызвать ошибки сервера.




SQL-инъекции.
Один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода. SQL-инъекция, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и записи файлов и выполнения произвольных команд на атакуемом сервере.





NoSQL-инъекции.
В настоящее время довольно популярны базы данных, которые не используют SQL в качестве языка запросов. Нет SQL - нет SQL-инъекций. Однако, если NoSQL закрывает одну потенциальную уязаимость, то при этом открывает несколько других, которые позволяют совершать разнообразные вредоносные действия: манипулировать REST-интерфейсом и подделывать межсайтовые запросы (CSRF), выполнять скрипты на сервере и использовать в запросах регулярные выражения, получать доступ к данным через специальный интерфейс, например BSON в MongoDB.




LDAP-инъекции.
LDAP-инъекция - это атака на стороне сервера, которая позволяет получить доступ к конфиденциальной информации о пользователях и хостах, представленных в структуре LDAP. Это делается путем манипулирования входными параметрами, которые затем передаются во внутренние функции поиска, добавления и изменения.




XML-инъекции.
Атака, когда атакующий пытается внедрить в веб-приложение свой XML-документ. Данная атака может привести к раскрытию конфиденциальных данных и удаленному выполнению произвольного кода на сервере.




SSI-инъекции.
Веб-серверы обычно дают разработчикам возможность добавлять небольшие фрагменты динамического кода в статические HTML-страницы без необходимости работать с полноценными серверными или клиентскими языками. Эта функция воплощена в Server-Side Includes (SSI). В тестировании инъекций SSI мы проверяем, возможно ли внедрить в приложение данные, которые будут интерпретироваться механизмами SSI. Успешное использование этой уязвимости позволяет внедрить произвольный код в HTML-страницы или даже удаленно выполнять код на сервере.




Xpath-инъекции.
XPath (XML Path Language) - язык запросов к элементам XML-документа. В тестировании XPath-инъекции мы проверяем, возможно ли внедрить синтаксис XPath в запрос, интерпретируемый приложением, позволяя выполнять произвольные запросы XPath. При успешном использовании эта уязвимость может позволить обойти механизмы аутентификации или получить доступ к информации без надлежащей авторизации.



IMAP/SMTP-инъекции.
Также, как и в описанных выше технологиях SQL, LDAP, SSI, Xpath инъекций, технология IMAP/SMTP-инъекций позволяет внедрить произвольные IMAP или SMTP команды почтовому серверу через веб-приложение, если оно некорректно обрабатывает входные данные.




Инъекции программного кода.
Данный тест нацелен на серверные скриптовые движки (PHP, ASP, JSP и др.). Мы проверим, возможно ли отправить на сервер данные, которые будут интерпретированы этими движками.



Инъекции команд ОС.
Иногда возможно удаленно выполнять команды операционной системы на сервере, внедряя их в HTTP-запрос уязвимого веб-сайта.




Переполнение буфера.
Уязвимость возникает, когда приложение пытается поместить в буфер (выделенную область памяти) больше данных, чем может вместить в себя буфер и происходит запись данных в область памяти за пределы буфера. В результате переполнения буфера могут быть повреждены данные, может случиться сбой в работе приложения или выполненен произвольный код на сервере.




HTTP splitting/smuggling.


Еще материалы по теме на русском языке
,


Мониторинг HTTP-запросов.
Таким образом можно выявить подозрительный, ненужный трафик, который может указывать на вредоносные действия, исходящие от уязвимого сайта.



Анализ сообщений об ошибках.
Cтраницы с сообщениями об ошибках, которые иногда выдает приложение, могут содержать чувствительную информацию, полезную для атакующего. Например в таких сообщениях могут быть раскрыты пути к корню сервера, относительные пути, структуры запросов к БД, версии используемого ПО и тд.



Проверка стойкости шифров SSL/TLS, защиты транспортного уровня.
На данном этапе проверяется, использует ли сервер при передаче чувствительных данных (кроме учетных данных и идентификаторов, которые были проверены ранее) шифрование. Можно ли обойти использование SSL. Применяются ли стойкие алгоритмы шифрования либо устаревшие, подверженные взлому. Кроме того, выполняется проверка цифрового сертификата - выдан ли доверенным центром сертификации, является ли действительным, соответствие имени сайта с именем в сертификате.

Соответствующий раздел OWASP Testing Guide
, ,


Padding Oracle.
Уязвимость, которая позволяет расшифровать и зашифровать данные, не зная ключа шифрования.




Тестирование бизнес-логики приложения.
Проверка валидности отправляемых данных, тест на подделку запросов, предельное количество выполнений одной функции, загрузка непредвиденных типов файлов и вредоносных файлов.



DOM-based XSS.
Еще один вид XSS, который в отличии от первых двух, внедряется на стороне клиента.



JavaScript-инъекция.
Еще один вид XSS.



Client Side URL redirect.
Перенаправление URL-адресов является операцией на стороне клиента, которая предписывает клиенту обратиться к ресурсу по другому адресу, отличному от запрошенного.



Манипуляции ресурсами на стороне клиента.



HTML- и CSS-инъекции.
Типы атак, при которых атакующему удается встроить свой html-код или css-код на уязвимую страницу. Таким образом возможна подмена содержимого страницы для жертвы.

Соответствующий раздел OWASP Testing Guide
,


Кликджекинг.
Этот тип атаки провоцирует жертву кликнуть по такому элементу веб-страницы, по которому жертва не собиралась кликать.





Приведенный выше список шагов, которые вы должны предпринять при тестировании, не исчерпывающий. Еще раз повторюсь, обязательно читайте руководство на официальном сайте OWASP, оно постоянно обновляется и дополняется. В будущих статьях я постараюсь раскрыть каждый из этапов тестирования более подробно.

На этом у меня почти все. Статья получилась объемной, но для полноты картины я приведу :

1. Инъекции - это такие уязвимости, когда атакующий отправляет на сервер произвольные данные(напримр SQL-выражения или код javascript), которые затем обрабатываются сервером, как часть запроса или команды, что позволяет атакующему получать доступ к данным без авторизации.

2. Ошибки в системе аутентификации. Функции веб-приложения, связанные с аутентификацией и управлением сеансами, часто реализуются неправильно, что позволяет злоумышленникам получить пароли, ключи или токены сессий или использовать другие недостатки реализации, чтобы получить идентификационные данные других пользователей.

3. Раскрытие чувствительной информации. Многие веб-приложения не защищают должным образом пользовательские данные. Например при передаче данных по не защищенному каналу (http вместо https, слабое шифрование и тд) они могут быть перехвачены злоумышленником.

4. XML External Entities (XXE). Тип атаки на приложение, которое анализирует ввод XML. Уязвимость может привести к раскрытию конфеденциальных данных и удаленному выполнению кода.

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

6. Неправильные настройки безопасности, одна из наиболее часто встречающихся проблем. Обычно является результатом использования настроек в ПО по умолчанию (например имя пользователя и пароль), неправильно настроенных HTTP-заголовков, подробных сообщений об ошибках с конфиденциальной информацией.

7. Межсайтовый скриптинг (Cross-Site-Scripting, XSS). Атака заключается в том, что в когда жертва переходит на уязвимую страницу, в ее браузере возможно исполнение вредоносного кода (на языке JavaScript), который внедрил в страницу злоумышленник. В результате выполнения такого кода могут быть украдены конфиденциальные данные (пароли, cookie, ключи), выполнено перенаправление на другие вредоносные сайты, совершена подмена оригинальной страницы на фальшивую и многое другое, что может JavaScript.

8. Небезопасная десереализация может привести к удаленному выполнению кода. Кроме того, эта уязвимость может помочь в проведении других атак, таких как SQL-инъекции или повышение привелегий.

9. Использование компонентов ПО с известными уязвимостями. Библиотеки, фреймворки, модули программ работают с теми же привелегиями, что и само веб-приложение. Уязвимость одного из компонентов ПО ставит под угрозу все приложение, данные пользователей и сам сервер.

10. Недостаточный мониторинг, неполное ведение логов. Данный фактор в сочетании с неэффективным и несвоевременным реагированием на инциденты безопасности позволяет злоумышленникам проводить длительные атаки, закрепляться во взломанных приложениях и серверах, разворачивать атаку глубже (повысить свои привелегии на сервере, попытаться проникнуть во внутренний периметр сети организации), добавлять, изменять и удалять данные. Большинство исследований показывают, что время обнаружения нарушений (попыток взлома) составляет более 200 дней и, как правило, обнаруживается внешней стороной, а не в результате внутреннего аудита и мониторинга.



Критика приветствуется.
Спасибо за внимание :)
 
g00db0y

g00db0y

Red Team
11.06.2018
79
301
Статья отличная! Только вот без каких-то картинок довольно трудно воспринимается.
 
Doctor zlo

Doctor zlo

Well-known member
18.05.2017
74
32
Статья отличная! Только вот без каких-то картинок довольно трудно воспринимается.
Согласен, статья отличная. Но, зачем тут картинки? Ведь автор все расписал, привел ссылки, дал советы. Что еще нужно то?
 
  • Нравится
Реакции: Shadow User и Литиум
Rocer

Rocer

Well-known member
04.09.2017
134
7
Отличное пособие для начинающих по больше бы таких статей.
 
  • Нравится
Реакции: Литиум
S

systeman

New member
27.05.2019
4
0
1. А ничего что гайд 2015года?.
Ещё не читал но думаю вот бы виртуалку под данный гайд.
 
larchik

larchik

Grey Team
07.06.2019
114
263
1. А ничего что гайд 2015года?.
Ещё не читал но думаю вот бы виртуалку под данный гайд.
Последнее обновление wiki было в 2016, так написано на официальном сайте.
И да, ничего, потому что с тех пор в сайтостроении и методах их защиты (а значит и взлома) ничего особо не поменялось, имхо.

Что касается виртуалки под этот гайд, посмотрите тут .
Вот об этом на русском языке

Я этим инструментом еще не пользовался, так что сказать о нем ничего не могу. Может форумчане пользовались. Попробуйте и напишите потом статью об этом, мне было бы интересно)
 
S

systeman

New member
27.05.2019
4
0
1. А как вы вообще тренировались читая статью? На реальных сайтах?
Запоминали команды и как работает допустим инъеция ?
2. Попутно что-то изучали (html, php, js).
 
G

Gunn1110

Member
01.03.2017
14
1
Однозначно плюсанул за труды и статью. Для новичков инфы более чем достаточно.
ТС подскажи плиз: я сам то не ломаю сайты и знаю что для практики есть много тренировочных площадок,но может захотеться на реальном сайте что-то попробовать. Как лучше обезопасить себя и свои действия.
Ну к примеру я слышал,что кто-то берет дедик,заливает туда виртуалку, на нее весь необходимый софт, прикручивают vpn,соксы и потом уже вперед.Кто-то еще как-нибудь шифруется. Вопрос ко всем знатокам: кто что может посоветовать в этом случае?
За ранее благодарю.
 
Marlen

Marlen

Well-known member
11.03.2017
106
47
Если надо будет помощь с переводом, пишите в личку.
 
larchik

larchik

Grey Team
07.06.2019
114
263
1. А как вы вообще тренировались читая статью? На реальных сайтах?
Вы хотели сказать, “читая гайд”?

Да, сначала на реальных сайтах. (У меня есть друзья и знакомые, что держат сайты на разных CMS и самописные сайты. Если у вас есть такие же знакомые, договоритесь тестируйте их реальные сайты. Может кодебай вам разрешит потестировать форум :) )
Я тупо не знал о специальных уязвимых виртуалках. Ну и на реальных целях все-таки интересней, согласитесь? Присутствует азарт. Главное ничего не испортить на сайте в ходе тренировки.
Как альтернативу, могу посоветовать бесплатные лаборатории от PentestIT. Тут, на кодебай, я где-то встречал врайтапы по прохождению. Очень интересно.

Запоминали команды и как работает допустим инъеция ?
Когда раз за разом вводишь в запрос одни и те же команды, они сами запоминаются. Ну и надо бы для начала хоть немного разобраться в языке, на котором делаешь инъекцию.
Как работает инъекция, запоминать не надо, а надо один раз понять, как она работает и все, это на всю жизнь.

2. Попутно что-то изучали (html, php, js).
Изучение чего-то - это вообще непрерывный процесс. Но у меня плохо с самодисциплиной, поэтому сегодня я изучаю Java или Python, а через месяц мне надоест и я изучаю что-нибудь другое. Не самый лучший вариант, но хоть как-то.


Однозначно плюсанул за труды и статью. Для новичков инфы более чем достаточно.
ТС подскажи плиз: я сам то не ломаю сайты и знаю что для практики есть много тренировочных площадок,но может захотеться на реальном сайте что-то попробовать. Как лучше обезопасить себя и свои действия.
Ну к примеру я слышал,что кто-то берет дедик,заливает туда виртуалку, на нее весь необходимый софт, прикручивают vpn,соксы и потом уже вперед.Кто-то еще как-нибудь шифруется. Вопрос ко всем знатокам: кто что может посоветовать в этом случае?
За ранее благодарю.
Спасибо вам и всем, кто плюсанул, это очень приятно, что труд был не напрасный )

На ваш вопрос трудно ответить, потому что каждый параноит по своему.
Могу дать несколько советов, которые известны всем форумчанам и вам наверное тоже:
Не трогайте российские сайты, если тут живете, особенно государственные.
На тестируемом сайте старайтесь ничего не попортить. Если нашли уязвимость, сообщите админам сайта.
Не занимайтесь грязью.
В общем соблюдайте этикет.

По технической части:
Работайте так, как будто бы ваш комп уже взломало ФСБ, АНБ, Моссад. То есть система должна быть чистой, без доступа к вебке, микрофону и тд.
От майора, который не обладает большой компьютерной грамотностью, вам поможет связка VPN1-Whonix-VPN2. Хуникс и второй впн может тут лишний, но так спокойней.
Для тренировки этого хватит.
Покупать дедик и ставить на него виртуалку - это оверпаранойя, имхо.
Если сильно накосячите, то найдут в любом случае. Вспомните про Шалтай-Балтай, они ведь профессионалы и точно знали, как их будут искать, но их все равно нашли.
Чего уж говорить о нас.
И я тоже хочу послушать мнение более компетентных форумчан, может я не прав.
 
Последнее редактирование:
  • Нравится
Реакции: BaShu и id2746
g00db0y

g00db0y

Red Team
11.06.2018
79
301
Однозначно плюсанул за труды и статью. Для новичков инфы более чем достаточно.
ТС подскажи плиз: я сам то не ломаю сайты и знаю что для практики есть много тренировочных площадок,но может захотеться на реальном сайте что-то попробовать. Как лучше обезопасить себя и свои действия.
Ну к примеру я слышал,что кто-то берет дедик,заливает туда виртуалку, на нее весь необходимый софт, прикручивают vpn,соксы и потом уже вперед.Кто-то еще как-нибудь шифруется. Вопрос ко всем знатокам: кто что может посоветовать в этом случае?
За ранее благодарю.
На Ваш вопрос отлично отвечает автор книги "How to Hack Like a Pornstar: A Step by Step Process for Breaking Into a Bank" в пункте 1. Safety first. К сожалению книга на английском, но даст Вам ответ.
 

Вложения

  • Нравится
Реакции: Gunn1110 и larchik
Soooer

Soooer

New member
07.07.2017
4
0
Статья просто отличная и без картинок то что надо !! Самый полный и объемный гайд !! Отлично мотивирует и классифицирует знания !!! Ура!!
 
Deminig

Deminig

Active member
18.01.2019
34
2
Здрасте. Вот я, новенький, потому что с английским только со словарём, программу Colobot не знаю. Python пробовал, но как и у тебя присутствует лень, хотя язык, вроде бы многообещающий. Вот ты просишь помощь с переводом, а пишешь - "начинающий", нельзя так, я между прочим, так и не понял как сделать SQL- инъекцию, поэтому я новичёк! С уважением Deminig.
 
V

Vultros

New member
25.05.2019
1
0
Спасибо большое за статью! Очень понравилась первая часть, где описываются трудности входа, так как зачастую про это мало кто рассказывает! Вторая часть очень объемная, спасибо за дополнительные ссылки. На каждом пункте нужно подробно останавливаться.
 
Iain

Iain

Active member
17.09.2016
41
59
  • Нравится
Реакции: BaShu, larchik и g00db0y
Iain

Iain

Active member
17.09.2016
41
59
Автор, спасибо тебе за твой труд!
 
S

systeman

New member
27.05.2019
4
0
Странно ввожу: nc x.x.x.x 80
Проходит время и ничего не происходит. Пробовал разные ip.
 
Мы в соцсетях:  ТелеграмВконтактеДзенФейсбукТвиттерЮтуб