Статья для участия в конкурсе на codeby.
Здравствуйте.
Как вы уже поняли, в этой статье я попробую ответить на два самых часто задаваемых вопроса на тематических форумах.
Статья состоит из двух частей.
В первой части мои пространные рассуждения о новичках в ИБ и сложном тернистом пути, который предстоит пройти начинающим хакерам. Можете смело пропустить эту часть, если вы любите больше конкретики.
Во второй части я кратко опишу большинство разделов OWASP Testing Guide – методологии тестирования веб-приложений. Данная методология – это и есть ответ на вопрос в заголовке статьи.
Если вы еще не знакомы с данной методологией, с ТОП 10 уязвимостей по версии OWASP и вообще не знаете об организации OWASP, настоятельно рекомендую ознакомиться с их официальным сайтом. Так же на Википедии есть статья об этой организации.
Официальный сайт OWASP
На Википедии об OWASP
OWASP Testing Guide
Конечно работа хакера — это во многом творческая работа и тупое следование методологии не сделает из вас настоящего хакера. Нужно наблюдать, думать, анализировать, эксперементировать, выявлять закономерности и находить необычное поведение в тестируемой системе, искать нестандартные подходы к тестированию и постоянно учиться, учиться, учиться. Вместе с этим во время пентеста вам придется выполнять много рутинной работы, от которой никуда не деться, но эта работа фундаментально важна.
Моя статья предназначена новичкам, которые хотят, наконец, начать свой путь, но не знают, как и с какой стороны подступиться. А начать с нуля, как мы все знаем, не так-то просто.
Во-первых в сфере Информационной Безопасности очень много разных направлений. В одном месте ты прочитал статью о SQL-инъекциях в веб-приложениях, в другом о реверcе андроид-приложений, в третьем о написании эксплоита для повышения привелегий в linux, а в четвертом что-то о каком-то meterpreter... что это вообще? Как разобраться в этой каше?
Во-вторых в сети очень много информации о хакинге в целом и о пентесте веб-приложений в частности. Даже в Рунете ее столько, что из него можно не вылазить пару-тройку лет, изучая эту информацию и перенимая опыт, пока ты наконец поймешь, что можно двинуться дальше и перенимать опыт уже у англоязычных коллег. Ориентироваться в таком количестве информации новичку очень сложно. Ты видишь сотни статей с обзорами разных утилит, сканеров, техник атак, новых и старых уязвимостей, кучу историй успешных взломов с примерами, но все равно спрашиваешь:
“Как взломать сайт?!”.
Я не осуждаю таких вопрошателей, потому что сам считаю себя новичком, и столкнулся (и продолжаю сталкиваться до сих пор) с теми же проблемами, что и вы.
Тем не менее начинать с чего-то надо. Как начал я?
Если начинать с самого начала, то рассказ начнется с приставки СЮБОР, каким-то чудом оказавшейся в нашем доме, когда мне было лет 12. Но тогда текста наберется на широкую и длинную простыню, поэтому постараюсь кратко и начну с тех времен, когда ИБ я занялся довольно плотно.
Несколько лет назад я набрел на один из фрикерских форумов (речь идет о фрикерах, а не фриках), где в одном из разделов обсуждалась сборка и программирование кодграббера на базе Ардуино для автосигнализаций. Для тех, кто не знает, кодграббер - это такая штука, которая перехватывает радиосигналы, которыми обменивается брелок с головной частью сигнализации. Ардуино - это такая плата с микроконтроллером, на базе которой можно построить несложную автоматизированную систему, например робота или кодграббер. Именно в то время я познакомился с программированием близко, хотя попытки писать программы предпринимались и ранее.
Меня так увлекла эта тема, что я заказал на Али себе плату Ардуино, купил на Авито брелок от FM-сигнализации, и принялся конструировать свой собственный кодграббер. Затея почти удалась, но сейчас не об этом. Очень скоро моя любознательность расширилась на сферу безопасности веб-приложений. Так я и нашел этот форум, нашел тут книгу о Кали Линукс и почти сразу же принялся изучать инструменты этой операционной системы.
В первый раз надолго меня не хватило. Гидра совершенно ничего не брутила, вывод nmap'а мне абсолютно ни о чем не говорил, а Метасплоит для меня был вообще чем-то за гранью реальности (собственно и сейчас я не особо им умею пользоваться). В общем я забыл про виртуалку с Кали и надолго забросил это дело.
Шло время, я иногда почитывал статьи по хакингу, продолжал ходить на работу на завод, время от времени поигрывал в Colobot (Colobot — Википедия). Где-то через пол-года после первого знакомства с Codeby и Kali, мне на глаза попалась статья о SQL-инъекциях. Надо сказать, что сама аббревиатура SQL для меня не значила ровным счетом ничего. Так вот, статья мне так понравилась, что я решил попробовать свои силы снова, и на этот раз у меня получилось.
Я никогда не забуду ту ночь. Мой первый взломанный сайт! Воистину, ощущения сравнимы с первым сексом, а может быть даже и ярче
У меня тряслись руки, потели ладони, я бегал курить каждые пол часа, и я совершенно не знал, что мне делать с этим взломанным сайтом. Мне хотелось об этом кому-то рассказать, очень-очень. Но я не мог рассказывать, так как жутко боялся, что в мою дверь постучат и меня уведут куда-то в наручниках, да и к тому же это была глубокая ночь и все мои друзья, слава богу, спали.
Тогда с помощью SQL-инъекции, следуя инструкциям из статьи об инъекциях на форуме rdot (ссылку на статью приведу ниже, во второй части статьи), я вручную смог вытащить из базы данных логины и хеши паролей админов сайта. Про sqlmap в то время мне было ничего не известно, что делать с хешами я тоже не знал, но это было совершенно не важно в тот момент. Я был по-настоящему счастлив и горд собой!
Пароли я сбрутил позже с помощью инструмента под названием hashcat (Hashcat – Инструменты Kali Linux). Хешей было несколько десятков (до сих пор не понимаю, зачем на сайт нужно несколько десятков админов, это очень небезопасно) и большинство из них конечно было вида 123456, qwerty, и тд.
Я стал дальше изучать этот сайт с целью найти его админку. Так я познакомился с утилитой под названием dirb (DIRB – Инструменты Kali Linux). Но с его помощью мне не удалось найти ничего интересного. Тогда я узнал об операторах поисковых систем и принялся гуглить, вдруг админка проиндексировалась. Но и тут меня ждала неудача. Поиск по доменам третьего уровня, типа admin.test.com, мне тоже ничего не дал. Я уже начал огорчаться, но удача пришла с другой стороны (и, как выяснилось потом, так происходит часто). Я обнаружил, что на сервере есть еще несколько сайтов того же владельца. И вот на одном из этих сайтов админка нашлась, и как вы понимаете, найденные мной логины и пароли подходили. Бинго!
Именно с тех пор, иногда с перерывами в 3-4 недели, я продолжаю изучать и практиковаться в ИБ и больше не бросал это занятие и не отчаивался, так как тот первый успех окрылил меня.
Через некоторое время мои знания, которые я продолжал получать в основном на форумах, немного утряслись и стали систематезироваться в моей голове. Я стал понимать, где добывать нужную мне информацию и какая именно информация мне нужна в данный момент. Тот темный лес, в котором я блуждал несколькими месяцами ранее, стал приобретать какие-то, едва различимые, очертания.
Пожалуй, самое главное, чему я научился в то время - терпению и гуглению.
Терпение - это то, что нужно новичку. Нам не терпится побыстрее нахакать сайтов. Новичок думает, что хакеры щелкают сайты, как семечки. Нет, мои друзья, это не так. Обычно взлому предшествует долгая и кропотливая, часто рутинная работа, и скоро ты это сам увидишь.
Умение гуглить - едва ли не самый важный фактор, который поспособствует твоему становлению, как хакера. На любом хакерском форуме мы все видим одни и те же вопросы, и одни и те же ответы на них: “Иди ты в Гугл со своими вопросами”.
Однажды я зарегистрировался на одном таком форуме с целью задать вопрос и был очень грубо послан в гугл. С тех пор вопросы на тему взломов я не задавал никому, кроме гугла (яндекса, бинга etc) и с удивлением обнаружил, что в сети есть всё. Примите как факт, что тот вопрос, который у вас возник, уже тысячи раз возникал в других умах, и на него точно уже где-то ответили.
Так, еще через некоторое время с помощью гугла и терпения я узнал о такой организации, как OWASP, о их Топ 10 уязвимостей и методологии тестирования. Именно об этом гайде и пойдет дальше речь. Ты спрашивал, как взломать сайт? Получи ответ.
В этом очень ценном руководстве есть всё, что вам нужно на начальном этапе. Пошагово расписано, что вы должны сделать, как это сделать, в каком порядке и зачем это нужно делать. Несмотря на то, что я совсем не знаю английский язык, я полностью прочитал это руководство с помощью онлайн-переводчика. Это не значит, что я его изучил, нет.
Многие из техник атак и уязвимостей, которые описаны в руководстве, еще не достигли моего понимания. По большому количеству уязвимостей у меня еще небыло реальной практики. Но времени у нас впереди - вся жизнь, а быстро делаются только дети.
Кстати, возьмите на заметку (те, кто не знает английский), пока я читал руководство с переводчиком, уровень моего английского вырос с нуля настолько, что это же руководство я смогу прочитать уже без словаря (ну почти).
В русском переводе в полном виде этого руководства в настоящее время не существует. Неоднократно предпринимались попытки перевода разными людьми (во второй части будут ссылки), даже существует открытый проект по его переводу (OWASP Testing Guide 4.0 — Translation Project on Crowdin), но полностью перевод так никто и не осилил.
Ниже я кратко опишу суть большинства глав руководства. К описанию каждой главы я приведу ссылки на материалы по теме, а вам остается только следовать инструкциям в ссылках и у вас все получится.
В ходе изучения гайда не пренебрегайте другими источниками информации. Например, если вы читаете главу о CSRF, не поленитесь и прочтите об этой уязвимости статью в Википедии, на Хабре, на Кодебай, на Хакере, на других ресурсах. Если вам в ходе изучения материалов непонятны какие-то термины, остановитесь и загуглите их. Так вам будет гораздо легче усваивать знания. А так же не забывайте о практике. Установите себе уязвимую виртуальную машину, например bWAPP (itsecgames.com), и отрабатывайте то, что в настоящий момент изучаете.
Далее, как обещал, вторая часть статьи с краткими описаниями и ссылками.
Внимание: переводы некоторых разделов, которые есть на сайте defcon.ru, могут быть устаревшими, но в целом отражают суть. В любом случае рекомендую читать оригинал, даже если сначала кажется очень трудно и долго. Дальше станет легче и вы даже не заметите, как все реже и реже обращаетесь к переводчику. Статьи по ссылкам тоже могут показаться вам устаревшими, но это не так. Многие уязвимости и техники их эксплуатации не потеряли своей актуальности с нулевых годов по сей день.
Часть вторая. Как взломать сайт. Краткое описание разделов OWASP Testing Guide.
Начать нужно с поиска утечек информации с помощью поисковых систем.
Индексы поисковых систем могут содержать страницы веб-приложения, не предназначенные для индексации. Один из ярких примеров недавнего времени, когда Google документы (в том числе с приватной информацией) были проиндексированы Яндексом, Bing'ом, самим Google и другими поисковиками.
В индексе поисковых систем могут оказаться логины и пароли пользователей, файлы баз данных, скрытые URL (например доступ к админ. интерфейсу), приватная информация о владельцах и админах сайта, и т.д.
Разные поисковики могут выдавать разную информацию. Например я заметил, что выдача Bing зачастую отличается от выдачи Яндекса и Гугла. Кроме того, существуют поисковые системы, специально предназначенные для поиска уязвимых устройств в сети. Я знаю один — Shodan.
Изучите поисковые операторы для каждого поисковика, так вы сможете искать по конкретному сайту, по URL, по файлам, по регионам, по датам и по другим параметрам.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Поиск утечек информации в метафайлах веб-сервера, а так же в комментариях исходного кода веб-страниц и метаданных веб-страниц.
Файл robots.txt, а так же комментарии к исходникам страниц сайта и теги META, могут содержать чувствительную информацию. Например разработчик в ходе написания кода сайта оставил для себя или своего коллеги комментарий в коде, содержащий логин и пароль тестового пользователя и перед релизом приложения забыл подчистить комментарии. Если вы обнаружите что-то подобное, то сможете хакнуть сайт, по существу еще даже не начав его взламывать.
Соответствующий раздел OWASP Testing Guide
Один, Два
Перевод раздела OWASP Testing Guide
Один, Два
Определение всех приложений на сервере.
На одном физическом сервере может находиться много сайтов и приложений. Любое из них может оказаться уязвимым и пустить вас на целевой сервер. Я для этих целей использую онлайн-сервисы, типа 2ip.ru, а так же брут DNS, nmap и поисковые системы.
В первой части статьи я привел пример, чем может грозить уязвимость всего лишь одного сайта для остальных приложений на сервере.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Определение точек входа.
Точки входа веб-приложения - это те места в приложении, где на сервер отправляются какие-то пользовательские данные. Чаще всего это GET и POST запросы, файлы cookie. Это важно, так как огромное количество уязвимостей приложений связано именно с неправильной обработкой пользовательских данных. В дальннейшем каждую из точек входа нужно протестировать на эти уязвимости.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Определение веб-сервера, фреймворка веб-приложения и самого веб-приложения.
Если вам известен вебсервер, фреймворк приложения, то вы сможете изучить его структуру, установив себе этот фреймворк, нагуглить известные уязвимости или слабые места. Тоже самое с веб-приложением, например, это может быть какая-то популярная CMS (Wordpress, OpenCart).
Соответствующий раздел OWASP Testing Guide
Один, Два, Три
Перевод раздела OWASP Testing Guide
Один, Два, Три
Тестирование конфигурации инфраструктуры и конфигурации приложения.
На данном этапе нужно собрать как можно больше информации о том, какой софт используется для работы целевого сайта и как он сконфигурирован. Файерволл, СУБД, почтовые службы, прокси-сервер и тд, все компоненты нужно по возможности определить. Определив версии ПО вы сможете поискать для них эксплоиты и известные уязвимости в открытом доступе, например на сайте https://www.exploit-db.com. Кроме того, зная, какой софт используется в инфраструктуре, вы можете самостоятельно установить его на свой компьютер (если такой софт доступен) и изучить его работу изнутри, а часто и исходный код.
Соответствующий раздел OWASP Testing Guide
Один, Два
Перевод раздела OWASP Testing Guide
Исследование расширений файлов.
Определите, какие расширения используются в приложении - html, php, py, asp, jsp и тд., так можно определить, какие технологии используются в инфраструктуре. Кроме того, проверьте, какие типы файлов и с какими расширениями можно загрузить на сервер.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Обнаружение старых версий сайта, резервных копий, нежелательных файлов.
Иногда в ходе тестирования удается обнаружить на веб-сервере скрытые или забытые файлы, старые версии приложения, резервные копии. В таких файлах может содержаться информация, раскрывающая структуру веб-приложения или учетные данные пользователей.
В поиске вам так же поможет гугл, например вы можете обнаружить в поисковой выдаче что-то вроде “https://old.testsite.com/”. Кроме гугла используйте такие утилиты, как dirb и girbuster (брут директорий), fierce (dns-брут).
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Обнаружение административных интерфейсов и тестирование надежности паролей в найденых интерфейсах.
С помощью тех же dirb, fierce и Гугла постарайтесь найти все админ. интерфейсы. Кроме, собственно, админки, это может быть вход в корпоративную почту через веб, какая-нибудь cPanel, или вообще админка от старой версии сайта. Так же используйте nmap, он покажет открытые порты, на которых тоже могут висеть какие-то интерфейсы для входа, например ssh или telnet.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование HTTP-методов.
Нужно определить, какие HTTP-методы поддерживаются веб-сервером. Кроме GET и POST есть множество других методов и сервер может реагировать на них весьма неожиданно. Стоит обратить внимание на метод TRACE. Если этот метод поддерживается сервером, становится возможной атака XST.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Про атаку XST
Тестирование HSTS.
HTTP Strict Transport Security - механизм, который активирует защищенное соединение по протоколу HTTPS. Нужно проверить, используется ли данный механизм на целевом веб-сайте.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование кросс-доменных политик.
Если файлы, регулирующие кросс-доменный доступ, неправильно сконфигурированы, то появляется возможность проведения атаки Cross-site Request Forgery и доступа к различной чувствительной информации.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Идентификация пользователей.
Определение ролей пользователей.
Определите, какие роли существуют в приложении для пользователей - гость, зарегистрированный пользователь, модератор, администратор и тд.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование процесса регистрации и “угадывание” имен других пользователей, определение политики образования имен пользователей.
Иногда по реакции веб-приложения можно определить, существует ли в системе пользователь с определенными учетными данными. Используя такую особенность приложения, вы можете выявить имена существующих пользователей, что значительно повысит ваши шансы на успех в дальнейшем при подборе паролей. Если пользователям назначаются имена по какому-то алгоритму, то так же есть вероятность угадать имена других юзеров, поняв алгоритм. Имейте ввиду, что кроме имен пользователям может присваиваться какой-нибудь другой идентификатор (id123456, напрмер).
Соответствующий раздел OWASP Testing Guide
Один, Два, Три, Четыре
Перевод раздела OWASP Testing Guide
Один, Два, Три, Четыре
Аутентификация.
Передаются ли учетные данные по защищенным каналам
Проверьте, когда вы логинитесь в приложении, как отправляются ваши логин и пароль? Для сайта хорошо, если данные отправляются по протоколу HTTPS, для хакера - если по HTTP, то есть в открытом виде. В таком случае есть вероятность, что хакер сможет перехватить учетные данные.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование учетных данных по умолчанию.
Часто в веб-приложениях используется программное обеспечение, которое работает “из коробки”. Для первоначальной авторизации в таком софте используются учетные данные по умолчанию. Если после установки программное обеспечение небыло настроено должным образом, дефолтные логин и пароль могут остаться в системе неизменными. Эти дефолтные пары логин/пароль для разного программного обеспечения можно посмотреть в официальной документации к ПО или просто нагуглить.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование механизма блокировки аккаунтов.
Механизмы блокировки аккаунтов используятся для предотвращения атак, связанных с подбором паролей (подбором ответов на секретные вопросы, перебором директорий и тд). Например, аккаунт может блокироваться на какое-то время после 10-ти неудачных вводов пароля, тем самым затрудняя возможность атаки методом перебора.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Обход схемы аутентификации.
Халатность, незнание или простое пренебрежение правилами безопасности часто приводят к схемам аутентификации, которые можно обойти просто пропустив страницу аутентификации и напрямую запросив страницу, доступ к которой должен получать только аутентифицированный пользователь. Довльно частый случай, например, когда приложение позволяет неаутентифицированным юзерам получить доступ к FCKeditor, который в свою очередь позволяет углубить атаку. Кроме того, аутентификацию можно обойти, подделывая запросы и обманывая приложение, заставляя его думать, что пользователь уже аутентифицирован.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Выявление слабых мест в кэше браузера.
Конфиденциальная информация пользователей не должна сохраняться в кэше браузера, так как в некоторых случаях можно извлечь ее из кэша.
Например вы совершаете покупку в интернет-магазине со своего рабочего компьютера. Заполняете форму оплаты на сайте, вводите данные своей карты, а потом передумываете и вводите в адресную строку yg140.servegame.com. Тут вас отвлек начальник или клиент и вы ушли с рабочего места. Злой коллега, который сел за ваш компьютер и обнаружил открытую страницу с yg140.servegame.com, взял да и нажал кнопку «назад» в браузере и попал в интернет-магазин, где вы собирались что-то купить. Если ваши данные были сохранены в кэше браузера, вероятно они отобразятся в полях ввода и предстанут взору вашему коллеге.
Соответствующий раздел OWASP Testing Guide
Тестирование надежности политики паролей.
Самые часто используемые пароли в мире - 123456, password и qwerty. Если приложение позволяет создавать пользователям слишком простые пароли, подобные этим, то политика паролей приложения, очевидно, не является надежной.
Соответствующий раздел OWASP Testing Guide
Тестирование политики секретных вопросов/ответов.
Многие веб-приложения реализуют функцию секретных вопросов/ответов таким образом, что ответы на эти секретные вопросы легко угадываются. Например, такие данные, как дата вашего рождения, любимый фильм или певец, кличка первого домашнего питомца, девичья фамилия матери и тд, обнаруживаются в соц.сетях жертвы либо подбираются методом перебора по словарю.
Соответствующий раздел OWASP Testing Guide
Тестирование функции восстановления, сброса и изменения пароля.
Придет ли забытый пароль на почту в открытом виде? Такое поведение будет указывать на то, что пароли хранятся в базе данных в открытом виде. Если новый пароль генерируется автоматически, можно ли его предсказать? Он придет на ту почту, которую указывали при регистрации или адрес можно как-то изменить в ходе восстановления?
Соответствующий раздел OWASP Testing Guide
Тестирование аутентификации через альтернативные каналы.
Кроме основного веб-приложения иногда можно логиниться через мобильное приложение, через тестовую версию сайта или даже по телефону через колл-центр. Нужно определить все альтернативные каналы и протестировать их.
Соответствующий раздел OWASP Testing Guide
Обнаружение уязвимостей Directory traversal/file include.
Используя эту уязвимость, можно читать директории и файлы, которые обычно нельзя прочитать, получать доступ к данным вне корня сайта или подключать скрипты к сайту и другие виды файлов с внешних ресурсов.
Соответствующий раздел OWASP Testing Guide
Обход схемы авторизации.
На данном мы получим ответы на следующие вопросы: можно ли получить доступ к ресурсу, даже если пользователь не аутентифицирован? Можно ли получить доступ к ресурсу даже после выхода из системы? Можно ли получить доступ к функциям, которые доступны пользователям с другими привелегиями? Можно ли получить доступ к административным функциям обычному пользователю?
Соответствующий раздел OWASP Testing Guide
Повышение привелегий.
Повышение привелегий происходит, когда пользователь получает доступ к большему количеству ресурсов и функций, чем ему разрешено правилами приложения. Различают веритикальное повышение - когда пользователь получает доступ к функциям администратора, и горизонтальное - когда пользователь получает доступ к функциям других пользователей, наделенных теми же правами.
Соответствующий раздел OWASP Testing Guide
Небезопасные ссылки на объекты.
Небезопасные прямые ссылки на объекты позволяют обходить авторизацию и получать прямой доступ к ресурсам, изменяя значение параметра, используемого для прямой ссылки на объект. Такими ресурсами могут быть записи базы данных, принадлежащие другим пользователям, файлы в системе и многое другое.
Соответствующий раздел OWASP Testing Guide
Обход схемы управления сессиями.
Что бы пользователю не пришлось при каждом обращении к сайту вводить свой логин и пароль, сайты используют файлы cookie. С помощью cookie сессия сохраняется активной долгое время. Если cookie слабые (можно понять алгоритм, по которому они формируются и присваиваются), их можно подделать и с их помощью создать новую сессию.
Соответствующий раздел OWASP Testing Guide
Захват сессии.
Файлы cookie должны своевременно обнуляться и переиздаваться. Если этого не происходит, то в случае перехвата cookie возможен захват сессии жертвы.
Соответствующий раздел OWASP Testing Guide
Раскрытие переменных сессии.
Передача файлов cookie от сайта к пользователю должна происходить по защищенному каналу, что бы исключить возможность перехвата. Требования к передаче cookie, токенов сессии и других идентификаторов могут быть выше, чем требования к передаче других конфиденциальных данных.
Соответствующий раздел OWASP Testing Guide
Межсайтовая подделка запросов или CSRF.
В общем случае атака выглядит так: если жертва заходит на сайт, созданный злоумышленником или им взломанный, от её лица тайно отправляется запрос на другой сайт, например, в платежную систему, и без ведома пользователя, но от его имени осуществляется перевод денег на счет злоумышленника или выполняются какие-то другие операции.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
Завершение и таймаут сессии.
Пользователи веб-браузеров часто не обращают внимания на то, что они все еще залогинены в системе, и просто закрывают браузер или вкладку, когда хотят выйти из приложения. Веб-приложение должно знать об этом и автоматически завершать сеанс на стороне сервера через определенный промежуток времени. Из браузера пользователя должны быть удалены cookie, а на сервере сайта дожна обновиться информация, что cookie больше не действительны, иначе пользователь подвержен риску захвата его сессии.
Соответствующий раздел OWASP Testing Guide
Session Puzzling.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
XSS. Межсайтовый скриптинг.
Тип атаки, заключающийся во внедрении вредоносного кода в какую-то из страниц сайта, который будет выполнен на компьютере пользователя при открытии им этой страницы. В этот момент у пользователя могут быть украдены cookie, перехвачены пароли, выполнена подмена выдаваемого контента и другие вредоносные действия.
Различают отраженные XSS и хранимые XSS.
Соответствующий раздел OWASP Testing Guide
Один, Два
Статья на Википедии
Подделка HTTP-методов.
Cпецификация HTTP включает в себя множество методов, отличных от стандартных GET и POST. Веб-сервер может реагировать на альтернативные методы способами, которые не были предусмотрены разработчиком, что в свою очередь может привести к раскрытию конфиденциальной информации, выполнению действий без аутентификации или другим нарушениям работы приложения.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости
Загрязнение HTTP-параметров (HPP).
Данная уязвимость возникает, когда веб-сервер аномально реагирует на получение нескольких HTTP-параметров с одинаковыми именами. Используя эти аномалии, можно обойти фильтрацию входных данных, изменить значения внутренних переменных, вызвать ошибки сервера.
Соответствующий раздел OWASP Testing Guide
Статья об атаке
SQL-инъекции.
Один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода. SQL-инъекция, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и записи файлов и выполнения произвольных команд на атакуемом сервере.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
Статья о SQLi на форуме rdot
NoSQL-инъекции.
В настоящее время довольно популярны базы данных, которые не используют SQL в качестве языка запросов. Нет SQL - нет SQL-инъекций. Однако, если NoSQL закрывает одну потенциальную уязаимость, то при этом открывает несколько других, которые позволяют совершать разнообразные вредоносные действия: манипулировать REST-интерфейсом и подделывать межсайтовые запросы (CSRF), выполнять скрипты на сервере и использовать в запросах регулярные выражения, получать доступ к данным через специальный интерфейс, например BSON в MongoDB.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
LDAP-инъекции.
LDAP-инъекция - это атака на стороне сервера, которая позволяет получить доступ к конфиденциальной информации о пользователях и хостах, представленных в структуре LDAP. Это делается путем манипулирования входными параметрами, которые затем передаются во внутренние функции поиска, добавления и изменения.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости на русском языке
XML-инъекции.
Атака, когда атакующий пытается внедрить в веб-приложение свой XML-документ. Данная атака может привести к раскрытию конфиденциальных данных и удаленному выполнению произвольного кода на сервере.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
SSI-инъекции.
Веб-серверы обычно дают разработчикам возможность добавлять небольшие фрагменты динамического кода в статические HTML-страницы без необходимости работать с полноценными серверными или клиентскими языками. Эта функция воплощена в Server-Side Includes (SSI). В тестировании инъекций SSI мы проверяем, возможно ли внедрить в приложение данные, которые будут интерпретироваться механизмами SSI. Успешное использование этой уязвимости позволяет внедрить произвольный код в HTML-страницы или даже удаленно выполнять код на сервере.
Соответствующий раздел OWASP Testing Guide
Статья о уязвимости + Xpath-injection
Xpath-инъекции.
XPath (XML Path Language) - язык запросов к элементам XML-документа. В тестировании XPath-инъекции мы проверяем, возможно ли внедрить синтаксис XPath в запрос, интерпретируемый приложением, позволяя выполнять произвольные запросы XPath. При успешном использовании эта уязвимость может позволить обойти механизмы аутентификации или получить доступ к информации без надлежащей авторизации.
Соответствующий раздел OWASP Testing Guide
IMAP/SMTP-инъекции.
Также, как и в описанных выше технологиях SQL, LDAP, SSI, Xpath инъекций, технология IMAP/SMTP-инъекций позволяет внедрить произвольные IMAP или SMTP команды почтовому серверу через веб-приложение, если оно некорректно обрабатывает входные данные.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости
Инъекции программного кода.
Данный тест нацелен на серверные скриптовые движки (PHP, ASP, JSP и др.). Мы проверим, возможно ли отправить на сервер данные, которые будут интерпретированы этими движками.
Соответствующий раздел OWASP Testing Guide
Инъекции команд ОС.
Иногда возможно удаленно выполнять команды операционной системы на сервере, внедряя их в HTTP-запрос уязвимого веб-сайта.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости
Переполнение буфера.
Уязвимость возникает, когда приложение пытается поместить в буфер (выделенную область памяти) больше данных, чем может вместить в себя буфер и происходит запись данных в область памяти за пределы буфера. В результате переполнения буфера могут быть повреждены данные, может случиться сбой в работе приложения или выполненен произвольный код на сервере.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
HTTP splitting/smuggling.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
Еще материалы по теме на русском языке
Один, Два
Мониторинг HTTP-запросов.
Таким образом можно выявить подозрительный, ненужный трафик, который может указывать на вредоносные действия, исходящие от уязвимого сайта.
Соответствующий раздел OWASP Testing Guide
Анализ сообщений об ошибках.
Cтраницы с сообщениями об ошибках, которые иногда выдает приложение, могут содержать чувствительную информацию, полезную для атакующего. Например в таких сообщениях могут быть раскрыты пути к корню сервера, относительные пути, структуры запросов к БД, версии используемого ПО и тд.
Соответствующий раздел OWASP Testing Guide
Проверка стойкости шифров SSL/TLS, защиты транспортного уровня.
На данном этапе проверяется, использует ли сервер при передаче чувствительных данных (кроме учетных данных и идентификаторов, которые были проверены ранее) шифрование. Можно ли обойти использование SSL. Применяются ли стойкие алгоритмы шифрования либо устаревшие, подверженные взлому. Кроме того, выполняется проверка цифрового сертификата - выдан ли доверенным центром сертификации, является ли действительным, соответствие имени сайта с именем в сертификате.
Соответствующий раздел OWASP Testing Guide
Один, Два, Три
Padding Oracle.
Уязвимость, которая позволяет расшифровать и зашифровать данные, не зная ключа шифрования.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости на Хабре
Тестирование бизнес-логики приложения.
Проверка валидности отправляемых данных, тест на подделку запросов, предельное количество выполнений одной функции, загрузка непредвиденных типов файлов и вредоносных файлов.
Соответствующий раздел OWASP Testing Guide
DOM-based XSS.
Еще один вид XSS, который в отличии от первых двух, внедряется на стороне клиента.
Соответствующий раздел OWASP Testing Guide
JavaScript-инъекция.
Еще один вид XSS.
Соответствующий раздел OWASP Testing Guide
Client Side URL redirect.
Перенаправление URL-адресов является операцией на стороне клиента, которая предписывает клиенту обратиться к ресурсу по другому адресу, отличному от запрошенного.
Соответствующий раздел OWASP Testing Guide
Манипуляции ресурсами на стороне клиента.
Соответствующий раздел OWASP Testing Guide
HTML- и CSS-инъекции.
Типы атак, при которых атакующему удается встроить свой html-код или css-код на уязвимую страницу. Таким образом возможна подмена содержимого страницы для жертвы.
Соответствующий раздел OWASP Testing Guide
HTMLi, CSSi
Кликджекинг.
Этот тип атаки провоцирует жертву кликнуть по такому элементу веб-страницы, по которому жертва не собиралась кликать.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
Яндекс про кликджекинг
Приведенный выше список шагов, которые вы должны предпринять при тестировании, не исчерпывающий. Еще раз повторюсь, обязательно читайте руководство на официальном сайте OWASP, оно постоянно обновляется и дополняется. В будущих статьях я постараюсь раскрыть каждый из этапов тестирования более подробно.
На этом у меня почти все. Статья получилась объемной, но для полноты картины я приведу Топ 10 уязвимостей по версии 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 дней и, как правило, обнаруживается внешней стороной, а не в результате внутреннего аудита и мониторинга.
Критика приветствуется.
Спасибо за внимание
Здравствуйте.
Как вы уже поняли, в этой статье я попробую ответить на два самых часто задаваемых вопроса на тематических форумах.
Статья состоит из двух частей.
В первой части мои пространные рассуждения о новичках в ИБ и сложном тернистом пути, который предстоит пройти начинающим хакерам. Можете смело пропустить эту часть, если вы любите больше конкретики.
Во второй части я кратко опишу большинство разделов OWASP Testing Guide – методологии тестирования веб-приложений. Данная методология – это и есть ответ на вопрос в заголовке статьи.
Если вы еще не знакомы с данной методологией, с ТОП 10 уязвимостей по версии OWASP и вообще не знаете об организации OWASP, настоятельно рекомендую ознакомиться с их официальным сайтом. Так же на Википедии есть статья об этой организации.
Официальный сайт OWASP
На Википедии об OWASP
OWASP Testing Guide
Конечно работа хакера — это во многом творческая работа и тупое следование методологии не сделает из вас настоящего хакера. Нужно наблюдать, думать, анализировать, эксперементировать, выявлять закономерности и находить необычное поведение в тестируемой системе, искать нестандартные подходы к тестированию и постоянно учиться, учиться, учиться. Вместе с этим во время пентеста вам придется выполнять много рутинной работы, от которой никуда не деться, но эта работа фундаментально важна.
Моя статья предназначена новичкам, которые хотят, наконец, начать свой путь, но не знают, как и с какой стороны подступиться. А начать с нуля, как мы все знаем, не так-то просто.
Во-первых в сфере Информационной Безопасности очень много разных направлений. В одном месте ты прочитал статью о SQL-инъекциях в веб-приложениях, в другом о реверcе андроид-приложений, в третьем о написании эксплоита для повышения привелегий в linux, а в четвертом что-то о каком-то meterpreter... что это вообще? Как разобраться в этой каше?
Во-вторых в сети очень много информации о хакинге в целом и о пентесте веб-приложений в частности. Даже в Рунете ее столько, что из него можно не вылазить пару-тройку лет, изучая эту информацию и перенимая опыт, пока ты наконец поймешь, что можно двинуться дальше и перенимать опыт уже у англоязычных коллег. Ориентироваться в таком количестве информации новичку очень сложно. Ты видишь сотни статей с обзорами разных утилит, сканеров, техник атак, новых и старых уязвимостей, кучу историй успешных взломов с примерами, но все равно спрашиваешь:
“Как взломать сайт?!”.
Я не осуждаю таких вопрошателей, потому что сам считаю себя новичком, и столкнулся (и продолжаю сталкиваться до сих пор) с теми же проблемами, что и вы.
Тем не менее начинать с чего-то надо. Как начал я?
Если начинать с самого начала, то рассказ начнется с приставки СЮБОР, каким-то чудом оказавшейся в нашем доме, когда мне было лет 12. Но тогда текста наберется на широкую и длинную простыню, поэтому постараюсь кратко и начну с тех времен, когда ИБ я занялся довольно плотно.
Несколько лет назад я набрел на один из фрикерских форумов (речь идет о фрикерах, а не фриках), где в одном из разделов обсуждалась сборка и программирование кодграббера на базе Ардуино для автосигнализаций. Для тех, кто не знает, кодграббер - это такая штука, которая перехватывает радиосигналы, которыми обменивается брелок с головной частью сигнализации. Ардуино - это такая плата с микроконтроллером, на базе которой можно построить несложную автоматизированную систему, например робота или кодграббер. Именно в то время я познакомился с программированием близко, хотя попытки писать программы предпринимались и ранее.
Меня так увлекла эта тема, что я заказал на Али себе плату Ардуино, купил на Авито брелок от FM-сигнализации, и принялся конструировать свой собственный кодграббер. Затея почти удалась, но сейчас не об этом. Очень скоро моя любознательность расширилась на сферу безопасности веб-приложений. Так я и нашел этот форум, нашел тут книгу о Кали Линукс и почти сразу же принялся изучать инструменты этой операционной системы.
В первый раз надолго меня не хватило. Гидра совершенно ничего не брутила, вывод nmap'а мне абсолютно ни о чем не говорил, а Метасплоит для меня был вообще чем-то за гранью реальности (собственно и сейчас я не особо им умею пользоваться). В общем я забыл про виртуалку с Кали и надолго забросил это дело.
Шло время, я иногда почитывал статьи по хакингу, продолжал ходить на работу на завод, время от времени поигрывал в Colobot (Colobot — Википедия). Где-то через пол-года после первого знакомства с Codeby и Kali, мне на глаза попалась статья о SQL-инъекциях. Надо сказать, что сама аббревиатура SQL для меня не значила ровным счетом ничего. Так вот, статья мне так понравилась, что я решил попробовать свои силы снова, и на этот раз у меня получилось.
Я никогда не забуду ту ночь. Мой первый взломанный сайт! Воистину, ощущения сравнимы с первым сексом, а может быть даже и ярче
У меня тряслись руки, потели ладони, я бегал курить каждые пол часа, и я совершенно не знал, что мне делать с этим взломанным сайтом. Мне хотелось об этом кому-то рассказать, очень-очень. Но я не мог рассказывать, так как жутко боялся, что в мою дверь постучат и меня уведут куда-то в наручниках, да и к тому же это была глубокая ночь и все мои друзья, слава богу, спали.Тогда с помощью SQL-инъекции, следуя инструкциям из статьи об инъекциях на форуме rdot (ссылку на статью приведу ниже, во второй части статьи), я вручную смог вытащить из базы данных логины и хеши паролей админов сайта. Про sqlmap в то время мне было ничего не известно, что делать с хешами я тоже не знал, но это было совершенно не важно в тот момент. Я был по-настоящему счастлив и горд собой!
Пароли я сбрутил позже с помощью инструмента под названием hashcat (Hashcat – Инструменты Kali Linux). Хешей было несколько десятков (до сих пор не понимаю, зачем на сайт нужно несколько десятков админов, это очень небезопасно) и большинство из них конечно было вида 123456, qwerty, и тд.
Я стал дальше изучать этот сайт с целью найти его админку. Так я познакомился с утилитой под названием dirb (DIRB – Инструменты Kali Linux). Но с его помощью мне не удалось найти ничего интересного. Тогда я узнал об операторах поисковых систем и принялся гуглить, вдруг админка проиндексировалась. Но и тут меня ждала неудача. Поиск по доменам третьего уровня, типа admin.test.com, мне тоже ничего не дал. Я уже начал огорчаться, но удача пришла с другой стороны (и, как выяснилось потом, так происходит часто). Я обнаружил, что на сервере есть еще несколько сайтов того же владельца. И вот на одном из этих сайтов админка нашлась, и как вы понимаете, найденные мной логины и пароли подходили. Бинго!
Именно с тех пор, иногда с перерывами в 3-4 недели, я продолжаю изучать и практиковаться в ИБ и больше не бросал это занятие и не отчаивался, так как тот первый успех окрылил меня.
Через некоторое время мои знания, которые я продолжал получать в основном на форумах, немного утряслись и стали систематезироваться в моей голове. Я стал понимать, где добывать нужную мне информацию и какая именно информация мне нужна в данный момент. Тот темный лес, в котором я блуждал несколькими месяцами ранее, стал приобретать какие-то, едва различимые, очертания.
Пожалуй, самое главное, чему я научился в то время - терпению и гуглению.
Терпение - это то, что нужно новичку. Нам не терпится побыстрее нахакать сайтов. Новичок думает, что хакеры щелкают сайты, как семечки. Нет, мои друзья, это не так. Обычно взлому предшествует долгая и кропотливая, часто рутинная работа, и скоро ты это сам увидишь.
Умение гуглить - едва ли не самый важный фактор, который поспособствует твоему становлению, как хакера. На любом хакерском форуме мы все видим одни и те же вопросы, и одни и те же ответы на них: “Иди ты в Гугл со своими вопросами”.
Однажды я зарегистрировался на одном таком форуме с целью задать вопрос и был очень грубо послан в гугл. С тех пор вопросы на тему взломов я не задавал никому, кроме гугла (яндекса, бинга etc) и с удивлением обнаружил, что в сети есть всё. Примите как факт, что тот вопрос, который у вас возник, уже тысячи раз возникал в других умах, и на него точно уже где-то ответили.
Так, еще через некоторое время с помощью гугла и терпения я узнал о такой организации, как OWASP, о их Топ 10 уязвимостей и методологии тестирования. Именно об этом гайде и пойдет дальше речь. Ты спрашивал, как взломать сайт? Получи ответ.
В этом очень ценном руководстве есть всё, что вам нужно на начальном этапе. Пошагово расписано, что вы должны сделать, как это сделать, в каком порядке и зачем это нужно делать. Несмотря на то, что я совсем не знаю английский язык, я полностью прочитал это руководство с помощью онлайн-переводчика. Это не значит, что я его изучил, нет.
Многие из техник атак и уязвимостей, которые описаны в руководстве, еще не достигли моего понимания. По большому количеству уязвимостей у меня еще небыло реальной практики. Но времени у нас впереди - вся жизнь, а быстро делаются только дети.
Кстати, возьмите на заметку (те, кто не знает английский), пока я читал руководство с переводчиком, уровень моего английского вырос с нуля настолько, что это же руководство я смогу прочитать уже без словаря (ну почти).
В русском переводе в полном виде этого руководства в настоящее время не существует. Неоднократно предпринимались попытки перевода разными людьми (во второй части будут ссылки), даже существует открытый проект по его переводу (OWASP Testing Guide 4.0 — Translation Project on Crowdin), но полностью перевод так никто и не осилил.
Пользуясь случаем, призываю неравнодушных юзеров присоединиться к переводу. Так как в ходе изучения этого гайда я делал множество заметок для себя, то сам присоединяюсь к переводу, несмотря на то, что мой английский оставляет желать лучшего.
Ниже я кратко опишу суть большинства глав руководства. К описанию каждой главы я приведу ссылки на материалы по теме, а вам остается только следовать инструкциям в ссылках и у вас все получится.
В ходе изучения гайда не пренебрегайте другими источниками информации. Например, если вы читаете главу о CSRF, не поленитесь и прочтите об этой уязвимости статью в Википедии, на Хабре, на Кодебай, на Хакере, на других ресурсах. Если вам в ходе изучения материалов непонятны какие-то термины, остановитесь и загуглите их. Так вам будет гораздо легче усваивать знания. А так же не забывайте о практике. Установите себе уязвимую виртуальную машину, например bWAPP (itsecgames.com), и отрабатывайте то, что в настоящий момент изучаете.
Далее, как обещал, вторая часть статьи с краткими описаниями и ссылками.
Внимание: переводы некоторых разделов, которые есть на сайте defcon.ru, могут быть устаревшими, но в целом отражают суть. В любом случае рекомендую читать оригинал, даже если сначала кажется очень трудно и долго. Дальше станет легче и вы даже не заметите, как все реже и реже обращаетесь к переводчику. Статьи по ссылкам тоже могут показаться вам устаревшими, но это не так. Многие уязвимости и техники их эксплуатации не потеряли своей актуальности с нулевых годов по сей день.
Часть вторая. Как взломать сайт. Краткое описание разделов OWASP Testing Guide.
Начать нужно с поиска утечек информации с помощью поисковых систем.
Индексы поисковых систем могут содержать страницы веб-приложения, не предназначенные для индексации. Один из ярких примеров недавнего времени, когда Google документы (в том числе с приватной информацией) были проиндексированы Яндексом, Bing'ом, самим Google и другими поисковиками.
В индексе поисковых систем могут оказаться логины и пароли пользователей, файлы баз данных, скрытые URL (например доступ к админ. интерфейсу), приватная информация о владельцах и админах сайта, и т.д.
Разные поисковики могут выдавать разную информацию. Например я заметил, что выдача Bing зачастую отличается от выдачи Яндекса и Гугла. Кроме того, существуют поисковые системы, специально предназначенные для поиска уязвимых устройств в сети. Я знаю один — Shodan.
Изучите поисковые операторы для каждого поисковика, так вы сможете искать по конкретному сайту, по URL, по файлам, по регионам, по датам и по другим параметрам.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Поиск утечек информации в метафайлах веб-сервера, а так же в комментариях исходного кода веб-страниц и метаданных веб-страниц.
Файл robots.txt, а так же комментарии к исходникам страниц сайта и теги META, могут содержать чувствительную информацию. Например разработчик в ходе написания кода сайта оставил для себя или своего коллеги комментарий в коде, содержащий логин и пароль тестового пользователя и перед релизом приложения забыл подчистить комментарии. Если вы обнаружите что-то подобное, то сможете хакнуть сайт, по существу еще даже не начав его взламывать.
Соответствующий раздел OWASP Testing Guide
Один, Два
Перевод раздела OWASP Testing Guide
Один, Два
Определение всех приложений на сервере.
На одном физическом сервере может находиться много сайтов и приложений. Любое из них может оказаться уязвимым и пустить вас на целевой сервер. Я для этих целей использую онлайн-сервисы, типа 2ip.ru, а так же брут DNS, nmap и поисковые системы.
В первой части статьи я привел пример, чем может грозить уязвимость всего лишь одного сайта для остальных приложений на сервере.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Определение точек входа.
Точки входа веб-приложения - это те места в приложении, где на сервер отправляются какие-то пользовательские данные. Чаще всего это GET и POST запросы, файлы cookie. Это важно, так как огромное количество уязвимостей приложений связано именно с неправильной обработкой пользовательских данных. В дальннейшем каждую из точек входа нужно протестировать на эти уязвимости.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Определение веб-сервера, фреймворка веб-приложения и самого веб-приложения.
Если вам известен вебсервер, фреймворк приложения, то вы сможете изучить его структуру, установив себе этот фреймворк, нагуглить известные уязвимости или слабые места. Тоже самое с веб-приложением, например, это может быть какая-то популярная CMS (Wordpress, OpenCart).
Соответствующий раздел OWASP Testing Guide
Один, Два, Три
Перевод раздела OWASP Testing Guide
Один, Два, Три
Тестирование конфигурации инфраструктуры и конфигурации приложения.
На данном этапе нужно собрать как можно больше информации о том, какой софт используется для работы целевого сайта и как он сконфигурирован. Файерволл, СУБД, почтовые службы, прокси-сервер и тд, все компоненты нужно по возможности определить. Определив версии ПО вы сможете поискать для них эксплоиты и известные уязвимости в открытом доступе, например на сайте https://www.exploit-db.com. Кроме того, зная, какой софт используется в инфраструктуре, вы можете самостоятельно установить его на свой компьютер (если такой софт доступен) и изучить его работу изнутри, а часто и исходный код.
Соответствующий раздел OWASP Testing Guide
Один, Два
Перевод раздела OWASP Testing Guide
Исследование расширений файлов.
Определите, какие расширения используются в приложении - html, php, py, asp, jsp и тд., так можно определить, какие технологии используются в инфраструктуре. Кроме того, проверьте, какие типы файлов и с какими расширениями можно загрузить на сервер.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Обнаружение старых версий сайта, резервных копий, нежелательных файлов.
Иногда в ходе тестирования удается обнаружить на веб-сервере скрытые или забытые файлы, старые версии приложения, резервные копии. В таких файлах может содержаться информация, раскрывающая структуру веб-приложения или учетные данные пользователей.
В поиске вам так же поможет гугл, например вы можете обнаружить в поисковой выдаче что-то вроде “https://old.testsite.com/”. Кроме гугла используйте такие утилиты, как dirb и girbuster (брут директорий), fierce (dns-брут).
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Обнаружение административных интерфейсов и тестирование надежности паролей в найденых интерфейсах.
С помощью тех же dirb, fierce и Гугла постарайтесь найти все админ. интерфейсы. Кроме, собственно, админки, это может быть вход в корпоративную почту через веб, какая-нибудь cPanel, или вообще админка от старой версии сайта. Так же используйте nmap, он покажет открытые порты, на которых тоже могут висеть какие-то интерфейсы для входа, например ssh или telnet.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование HTTP-методов.
Нужно определить, какие HTTP-методы поддерживаются веб-сервером. Кроме GET и POST есть множество других методов и сервер может реагировать на них весьма неожиданно. Стоит обратить внимание на метод TRACE. Если этот метод поддерживается сервером, становится возможной атака XST.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Про атаку XST
Тестирование HSTS.
HTTP Strict Transport Security - механизм, который активирует защищенное соединение по протоколу HTTPS. Нужно проверить, используется ли данный механизм на целевом веб-сайте.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование кросс-доменных политик.
Если файлы, регулирующие кросс-доменный доступ, неправильно сконфигурированы, то появляется возможность проведения атаки Cross-site Request Forgery и доступа к различной чувствительной информации.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Идентификация пользователей.
Определение ролей пользователей.
Определите, какие роли существуют в приложении для пользователей - гость, зарегистрированный пользователь, модератор, администратор и тд.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование процесса регистрации и “угадывание” имен других пользователей, определение политики образования имен пользователей.
Иногда по реакции веб-приложения можно определить, существует ли в системе пользователь с определенными учетными данными. Используя такую особенность приложения, вы можете выявить имена существующих пользователей, что значительно повысит ваши шансы на успех в дальнейшем при подборе паролей. Если пользователям назначаются имена по какому-то алгоритму, то так же есть вероятность угадать имена других юзеров, поняв алгоритм. Имейте ввиду, что кроме имен пользователям может присваиваться какой-нибудь другой идентификатор (id123456, напрмер).
Соответствующий раздел OWASP Testing Guide
Один, Два, Три, Четыре
Перевод раздела OWASP Testing Guide
Один, Два, Три, Четыре
Аутентификация.
Передаются ли учетные данные по защищенным каналам
Проверьте, когда вы логинитесь в приложении, как отправляются ваши логин и пароль? Для сайта хорошо, если данные отправляются по протоколу HTTPS, для хакера - если по HTTP, то есть в открытом виде. В таком случае есть вероятность, что хакер сможет перехватить учетные данные.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование учетных данных по умолчанию.
Часто в веб-приложениях используется программное обеспечение, которое работает “из коробки”. Для первоначальной авторизации в таком софте используются учетные данные по умолчанию. Если после установки программное обеспечение небыло настроено должным образом, дефолтные логин и пароль могут остаться в системе неизменными. Эти дефолтные пары логин/пароль для разного программного обеспечения можно посмотреть в официальной документации к ПО или просто нагуглить.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Тестирование механизма блокировки аккаунтов.
Механизмы блокировки аккаунтов используятся для предотвращения атак, связанных с подбором паролей (подбором ответов на секретные вопросы, перебором директорий и тд). Например, аккаунт может блокироваться на какое-то время после 10-ти неудачных вводов пароля, тем самым затрудняя возможность атаки методом перебора.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Обход схемы аутентификации.
Халатность, незнание или простое пренебрежение правилами безопасности часто приводят к схемам аутентификации, которые можно обойти просто пропустив страницу аутентификации и напрямую запросив страницу, доступ к которой должен получать только аутентифицированный пользователь. Довльно частый случай, например, когда приложение позволяет неаутентифицированным юзерам получить доступ к FCKeditor, который в свою очередь позволяет углубить атаку. Кроме того, аутентификацию можно обойти, подделывая запросы и обманывая приложение, заставляя его думать, что пользователь уже аутентифицирован.
Соответствующий раздел OWASP Testing Guide
Перевод раздела OWASP Testing Guide
Выявление слабых мест в кэше браузера.
Конфиденциальная информация пользователей не должна сохраняться в кэше браузера, так как в некоторых случаях можно извлечь ее из кэша.
Например вы совершаете покупку в интернет-магазине со своего рабочего компьютера. Заполняете форму оплаты на сайте, вводите данные своей карты, а потом передумываете и вводите в адресную строку yg140.servegame.com. Тут вас отвлек начальник или клиент и вы ушли с рабочего места. Злой коллега, который сел за ваш компьютер и обнаружил открытую страницу с yg140.servegame.com, взял да и нажал кнопку «назад» в браузере и попал в интернет-магазин, где вы собирались что-то купить. Если ваши данные были сохранены в кэше браузера, вероятно они отобразятся в полях ввода и предстанут взору вашему коллеге.
Соответствующий раздел OWASP Testing Guide
Тестирование надежности политики паролей.
Самые часто используемые пароли в мире - 123456, password и qwerty. Если приложение позволяет создавать пользователям слишком простые пароли, подобные этим, то политика паролей приложения, очевидно, не является надежной.
Соответствующий раздел OWASP Testing Guide
Тестирование политики секретных вопросов/ответов.
Многие веб-приложения реализуют функцию секретных вопросов/ответов таким образом, что ответы на эти секретные вопросы легко угадываются. Например, такие данные, как дата вашего рождения, любимый фильм или певец, кличка первого домашнего питомца, девичья фамилия матери и тд, обнаруживаются в соц.сетях жертвы либо подбираются методом перебора по словарю.
Соответствующий раздел OWASP Testing Guide
Тестирование функции восстановления, сброса и изменения пароля.
Придет ли забытый пароль на почту в открытом виде? Такое поведение будет указывать на то, что пароли хранятся в базе данных в открытом виде. Если новый пароль генерируется автоматически, можно ли его предсказать? Он придет на ту почту, которую указывали при регистрации или адрес можно как-то изменить в ходе восстановления?
Соответствующий раздел OWASP Testing Guide
Тестирование аутентификации через альтернативные каналы.
Кроме основного веб-приложения иногда можно логиниться через мобильное приложение, через тестовую версию сайта или даже по телефону через колл-центр. Нужно определить все альтернативные каналы и протестировать их.
Соответствующий раздел OWASP Testing Guide
Обнаружение уязвимостей Directory traversal/file include.
Используя эту уязвимость, можно читать директории и файлы, которые обычно нельзя прочитать, получать доступ к данным вне корня сайта или подключать скрипты к сайту и другие виды файлов с внешних ресурсов.
Соответствующий раздел OWASP Testing Guide
Обход схемы авторизации.
На данном мы получим ответы на следующие вопросы: можно ли получить доступ к ресурсу, даже если пользователь не аутентифицирован? Можно ли получить доступ к ресурсу даже после выхода из системы? Можно ли получить доступ к функциям, которые доступны пользователям с другими привелегиями? Можно ли получить доступ к административным функциям обычному пользователю?
Соответствующий раздел OWASP Testing Guide
Повышение привелегий.
Повышение привелегий происходит, когда пользователь получает доступ к большему количеству ресурсов и функций, чем ему разрешено правилами приложения. Различают веритикальное повышение - когда пользователь получает доступ к функциям администратора, и горизонтальное - когда пользователь получает доступ к функциям других пользователей, наделенных теми же правами.
Соответствующий раздел OWASP Testing Guide
Небезопасные ссылки на объекты.
Небезопасные прямые ссылки на объекты позволяют обходить авторизацию и получать прямой доступ к ресурсам, изменяя значение параметра, используемого для прямой ссылки на объект. Такими ресурсами могут быть записи базы данных, принадлежащие другим пользователям, файлы в системе и многое другое.
Соответствующий раздел OWASP Testing Guide
Обход схемы управления сессиями.
Что бы пользователю не пришлось при каждом обращении к сайту вводить свой логин и пароль, сайты используют файлы cookie. С помощью cookie сессия сохраняется активной долгое время. Если cookie слабые (можно понять алгоритм, по которому они формируются и присваиваются), их можно подделать и с их помощью создать новую сессию.
Соответствующий раздел OWASP Testing Guide
Захват сессии.
Файлы cookie должны своевременно обнуляться и переиздаваться. Если этого не происходит, то в случае перехвата cookie возможен захват сессии жертвы.
Соответствующий раздел OWASP Testing Guide
Раскрытие переменных сессии.
Передача файлов cookie от сайта к пользователю должна происходить по защищенному каналу, что бы исключить возможность перехвата. Требования к передаче cookie, токенов сессии и других идентификаторов могут быть выше, чем требования к передаче других конфиденциальных данных.
Соответствующий раздел OWASP Testing Guide
Межсайтовая подделка запросов или CSRF.
В общем случае атака выглядит так: если жертва заходит на сайт, созданный злоумышленником или им взломанный, от её лица тайно отправляется запрос на другой сайт, например, в платежную систему, и без ведома пользователя, но от его имени осуществляется перевод денег на счет злоумышленника или выполняются какие-то другие операции.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
Завершение и таймаут сессии.
Пользователи веб-браузеров часто не обращают внимания на то, что они все еще залогинены в системе, и просто закрывают браузер или вкладку, когда хотят выйти из приложения. Веб-приложение должно знать об этом и автоматически завершать сеанс на стороне сервера через определенный промежуток времени. Из браузера пользователя должны быть удалены cookie, а на сервере сайта дожна обновиться информация, что cookie больше не действительны, иначе пользователь подвержен риску захвата его сессии.
Соответствующий раздел OWASP Testing Guide
Session Puzzling.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
XSS. Межсайтовый скриптинг.
Тип атаки, заключающийся во внедрении вредоносного кода в какую-то из страниц сайта, который будет выполнен на компьютере пользователя при открытии им этой страницы. В этот момент у пользователя могут быть украдены cookie, перехвачены пароли, выполнена подмена выдаваемого контента и другие вредоносные действия.
Различают отраженные XSS и хранимые XSS.
Соответствующий раздел OWASP Testing Guide
Один, Два
Статья на Википедии
Подделка HTTP-методов.
Cпецификация HTTP включает в себя множество методов, отличных от стандартных GET и POST. Веб-сервер может реагировать на альтернативные методы способами, которые не были предусмотрены разработчиком, что в свою очередь может привести к раскрытию конфиденциальной информации, выполнению действий без аутентификации или другим нарушениям работы приложения.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости
Загрязнение HTTP-параметров (HPP).
Данная уязвимость возникает, когда веб-сервер аномально реагирует на получение нескольких HTTP-параметров с одинаковыми именами. Используя эти аномалии, можно обойти фильтрацию входных данных, изменить значения внутренних переменных, вызвать ошибки сервера.
Соответствующий раздел OWASP Testing Guide
Статья об атаке
SQL-инъекции.
Один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода. SQL-инъекция, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и записи файлов и выполнения произвольных команд на атакуемом сервере.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
Статья о SQLi на форуме rdot
NoSQL-инъекции.
В настоящее время довольно популярны базы данных, которые не используют SQL в качестве языка запросов. Нет SQL - нет SQL-инъекций. Однако, если NoSQL закрывает одну потенциальную уязаимость, то при этом открывает несколько других, которые позволяют совершать разнообразные вредоносные действия: манипулировать REST-интерфейсом и подделывать межсайтовые запросы (CSRF), выполнять скрипты на сервере и использовать в запросах регулярные выражения, получать доступ к данным через специальный интерфейс, например BSON в MongoDB.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
LDAP-инъекции.
LDAP-инъекция - это атака на стороне сервера, которая позволяет получить доступ к конфиденциальной информации о пользователях и хостах, представленных в структуре LDAP. Это делается путем манипулирования входными параметрами, которые затем передаются во внутренние функции поиска, добавления и изменения.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости на русском языке
XML-инъекции.
Атака, когда атакующий пытается внедрить в веб-приложение свой XML-документ. Данная атака может привести к раскрытию конфиденциальных данных и удаленному выполнению произвольного кода на сервере.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
SSI-инъекции.
Веб-серверы обычно дают разработчикам возможность добавлять небольшие фрагменты динамического кода в статические HTML-страницы без необходимости работать с полноценными серверными или клиентскими языками. Эта функция воплощена в Server-Side Includes (SSI). В тестировании инъекций SSI мы проверяем, возможно ли внедрить в приложение данные, которые будут интерпретироваться механизмами SSI. Успешное использование этой уязвимости позволяет внедрить произвольный код в HTML-страницы или даже удаленно выполнять код на сервере.
Соответствующий раздел OWASP Testing Guide
Статья о уязвимости + Xpath-injection
Xpath-инъекции.
XPath (XML Path Language) - язык запросов к элементам XML-документа. В тестировании XPath-инъекции мы проверяем, возможно ли внедрить синтаксис XPath в запрос, интерпретируемый приложением, позволяя выполнять произвольные запросы XPath. При успешном использовании эта уязвимость может позволить обойти механизмы аутентификации или получить доступ к информации без надлежащей авторизации.
Соответствующий раздел OWASP Testing Guide
IMAP/SMTP-инъекции.
Также, как и в описанных выше технологиях SQL, LDAP, SSI, Xpath инъекций, технология IMAP/SMTP-инъекций позволяет внедрить произвольные IMAP или SMTP команды почтовому серверу через веб-приложение, если оно некорректно обрабатывает входные данные.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости
Инъекции программного кода.
Данный тест нацелен на серверные скриптовые движки (PHP, ASP, JSP и др.). Мы проверим, возможно ли отправить на сервер данные, которые будут интерпретированы этими движками.
Соответствующий раздел OWASP Testing Guide
Инъекции команд ОС.
Иногда возможно удаленно выполнять команды операционной системы на сервере, внедряя их в HTTP-запрос уязвимого веб-сайта.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости
Переполнение буфера.
Уязвимость возникает, когда приложение пытается поместить в буфер (выделенную область памяти) больше данных, чем может вместить в себя буфер и происходит запись данных в область памяти за пределы буфера. В результате переполнения буфера могут быть повреждены данные, может случиться сбой в работе приложения или выполненен произвольный код на сервере.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
HTTP splitting/smuggling.
Соответствующий раздел OWASP Testing Guide
Статья в журнале Хакер
Еще материалы по теме на русском языке
Один, Два
Мониторинг HTTP-запросов.
Таким образом можно выявить подозрительный, ненужный трафик, который может указывать на вредоносные действия, исходящие от уязвимого сайта.
Соответствующий раздел OWASP Testing Guide
Анализ сообщений об ошибках.
Cтраницы с сообщениями об ошибках, которые иногда выдает приложение, могут содержать чувствительную информацию, полезную для атакующего. Например в таких сообщениях могут быть раскрыты пути к корню сервера, относительные пути, структуры запросов к БД, версии используемого ПО и тд.
Соответствующий раздел OWASP Testing Guide
Проверка стойкости шифров SSL/TLS, защиты транспортного уровня.
На данном этапе проверяется, использует ли сервер при передаче чувствительных данных (кроме учетных данных и идентификаторов, которые были проверены ранее) шифрование. Можно ли обойти использование SSL. Применяются ли стойкие алгоритмы шифрования либо устаревшие, подверженные взлому. Кроме того, выполняется проверка цифрового сертификата - выдан ли доверенным центром сертификации, является ли действительным, соответствие имени сайта с именем в сертификате.
Соответствующий раздел OWASP Testing Guide
Один, Два, Три
Padding Oracle.
Уязвимость, которая позволяет расшифровать и зашифровать данные, не зная ключа шифрования.
Соответствующий раздел OWASP Testing Guide
Статья об уязвимости на Хабре
Тестирование бизнес-логики приложения.
Проверка валидности отправляемых данных, тест на подделку запросов, предельное количество выполнений одной функции, загрузка непредвиденных типов файлов и вредоносных файлов.
Соответствующий раздел OWASP Testing Guide
DOM-based XSS.
Еще один вид XSS, который в отличии от первых двух, внедряется на стороне клиента.
Соответствующий раздел OWASP Testing Guide
JavaScript-инъекция.
Еще один вид XSS.
Соответствующий раздел OWASP Testing Guide
Client Side URL redirect.
Перенаправление URL-адресов является операцией на стороне клиента, которая предписывает клиенту обратиться к ресурсу по другому адресу, отличному от запрошенного.
Соответствующий раздел OWASP Testing Guide
Манипуляции ресурсами на стороне клиента.
Соответствующий раздел OWASP Testing Guide
HTML- и CSS-инъекции.
Типы атак, при которых атакующему удается встроить свой html-код или css-код на уязвимую страницу. Таким образом возможна подмена содержимого страницы для жертвы.
Соответствующий раздел OWASP Testing Guide
HTMLi, CSSi
Кликджекинг.
Этот тип атаки провоцирует жертву кликнуть по такому элементу веб-страницы, по которому жертва не собиралась кликать.
Соответствующий раздел OWASP Testing Guide
Статья на Википедии
Яндекс про кликджекинг
Приведенный выше список шагов, которые вы должны предпринять при тестировании, не исчерпывающий. Еще раз повторюсь, обязательно читайте руководство на официальном сайте OWASP, оно постоянно обновляется и дополняется. В будущих статьях я постараюсь раскрыть каждый из этапов тестирования более подробно.
На этом у меня почти все. Статья получилась объемной, но для полноты картины я приведу Топ 10 уязвимостей по версии 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 дней и, как правило, обнаруживается внешней стороной, а не в результате внутреннего аудита и мониторинга.
Критика приветствуется.
Спасибо за внимание
