A2:Broken Authentication OWASP TOP 10
Вернуться назад

Так как тема о тестировании безопасности проектов набирает обороты, решил написать статейку на основе OWASP TOP 10

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

(1) Мы пользователь с именем боб, даем пароль и логин на сайте при авторизации. Этот запрос с этими данными поступает на сервер этого сайта POST login.html, где происходит действие (2) Сервер проверяет мои данные у себя, если я есть в системе с этими данными, он говорит привет Боб, все нормалды, проходи и дает мне ответ 200 OK, что означает, что меня авторизовало. Затем в действии (3), я хочу посмотреть свои данные на странице профиля, чтоб что-то подредачить, пытаюсь перейти на страницу профиля, при этом выполняется на сервер запрос GET profile.html, это означает, что я хочу посетить эту страницу. В действии (4) Сервер начинает проверять меня, так как не получил от меня никаких подтверждающих данных, что я это я. Говорит мне в ответ, ты хто такой братан??? и отдает мне в ответ, вместо запрошенной страницы, какуе-то страницу с выводом ошибки 401 Unauthorized. Это так произошло, так как во втором моем запросе уже не лежали никакие данные с паролем и логином для того, чтоб меня могли распознать. Но согласитель не удобно же при посещении какой-то страницы все время давать свои данные пароля и логина? Поэтому есть такая вещь как сессия, которая хранит в себе все данные о мне, и не заставляет меня все время отправлять свои креденшелы для посещения той или иной страницы. А теперь рассмотрим вариант как это работает с сессией....

Такие валидации можно сравнить таким образом с такими картинками

Дайте попробую вам объяснить немного подробнее, что это и как работает. Допустим у нас есть таблица с креденшилами юзеров, которая хранит в себе данные для авторизации, каждого из существующих юзеров. Я надеюсь у вас в проекте не лежат пароли в открытом виде?)))) Допустим у нас есть колонка Passwd, как в этой таблице, которая должна иметь данные в таком виде как в колонке Hash Passwd. Но для наглядного примера, я внес и эту колонку, чтоб было понятно откуда берутся такие значения которые в колонке Hash Passwd. И так, к примеру возьмем в действия (1) пароль с 4 строки 1111, захешируем его через формат MD5. Добавлю, что есть разные виды хеширования, не только этот тип. Вы можете взять ссылку в действии (2) и практиковаться там, в том как происходит хеширование, закидывая туда значение и нажимать хешировать. В действии (3) мы получаем хеш для пароля 1111 и он уже имеет вид b59c67bf196a4758191e42f76670ceba, это делается для того, чтоб если даже атакующий каким-то образом достанет данные из базы, то чтоб критичные данные были скрыты с его глаз. Но надо помнить с какой легкостью мы захешировали эти данные, с такой же легкостью можем разхешировать, даже на этом сайте есть возможность сделать это. Поэтому стоит применить меры предосторожности, такие как соль и перец, но об этом подробнее я позже расскажу. Вернемся к действию (4) , где захешированные данные попадают в таблицу. На самом деле все происходит быстрее, без участия сайта, хеширование происходит мгновенно в тот формат, который указан у вас в приложении и хеш размещается в колонку паролей без промежуточной колонки с открытым паролем. Надеюсь понятно. А теперь расскажу почему простое хеширование тоже не хорошо...

gallery/broken-authentication-and-session-management
gallery/выделение_009

Вот они во все своей красе)))

И так в этой статье мы рассмотрим вторую уязвимость "Broken Authentication" во всем ее цветении...

 

Эта уязвимость делится на 3 вектора для атаки:

   - Brute-Force

   - Session Hijacking

   - Rainbow Tables

 

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

gallery/выделение_010

1) Brute-Force

Ну что начнем разбирать этот вид уязвимости и начнем с вектора атаки Brute force

 

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

 

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

gallery/выделение_011

И так, допустим у нас есть файл с огромным списком подготовленных email (Логинов), на картинке выше это цифра 1. Затем у нас есть список подготовленных паролей, можем взять список самых популярных паролей, по статистике он выглядит примерно так:

 

Пароль             Количество использований

123456              120511

12345                48452

password           39448

DEFAULT           34275

123456789         26620

qwerty                20778

12345678           14172

abc123               10869

pussy                 10683

1234567             9468

696969               8801

ashley                 8793

fuckme                7893

football                7872

baseball              7710

fuckyou               7458

111111                 7048

1234567890       6572

ashleymadison   6213

password1          5959

madison              5219

asshole               5052

superman           5023

mustang             4865

harley                 4815

654321               4729

123123               4612

hello                   4425

monkey              4296

000000               4240

hockey                4191

 

Не правда ли смешно, что пользователи юзают такие пароли в качестве защиты своих учеток?)))) Наверное они себя никак не уважают. Более больший список можете найти тут

 

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

gallery/выделение_012

2) Session hijacking

А теперь перейдем ко второму вектору атаки Session hijacking

 

Session hijackingэто кража правильного сеанса пользователя, с какого-то сайта. Цель такой атаки подразумевает собой получение доступа к информации, которой владеет этот пользователь, либо к его услугам. Давайте немного разберем подробнее на примере, так как наверно из вышесказанного не совсем понятно как это работает.

 

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

gallery/выделение_016
gallery/выделение_017

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

(1) Опять таки мы пользователь с именем боб, даем пароль и логин на сайте при авторизации, этот запрос с этими данными поступает на сервер этого сайта POST login.html, где происходит действие (2) Сервер проверяет мои данные у себя и если я есть в системе с этими данными, после создаёт мне уникальную сессию, кладет ее в базу. Затем он говорит мне "привет Боб, все нормалды, проходи, но запомни этот ID сессии", в которой хранятся все данные о мне с моими креденшилами, и давай мне эту ID при выполнении любого запроса на сайте, и в конце концов дает мне ответ 200 OK, что означает, что меня авторизовало, а также дало мне уникальною айдишку. Теперь при следующих запросах, я буду просто вместе с запросом на какуе-то страницу сайта, давать еще ID сессии, для того, чтоб меня воспринимали как своего пользователя сайтом. Рассмотрим еще, что будет происходить при другом запросе на сайт.....

gallery/выделение_019

На этой картинке уже показано как, при дальнейших наших запросах, выполняется передача вместе с ним и ID сессии. Для того, чтоб сервер мог понять, что мы его пользователи, и не даст там отказа, как охранник при входе на дискотеку. Эхх были времена)))) (1) Опять таки мы пользователь с именем боб, делаем запрос GET profile.html, что мы хотим посмотреть страницу профиля, чтоб потом ее подредачить, но в этом запросе мы также передаем и ID сессии, в которой лежит и пароль Set-Coockie:jf6b0mit6tjot946hrrsoqv2v3, для определения нас, как пользователь этого сайта, где происходит действие (2) Сервер проверяет мои данные у себя в базе, есть ли такой пользователь, с таким ID сессии. Если я есть в системе с этими данными, он говорит мне "привет Боб, братуха, все нормалды, проходи, и держи то, что хотел увидеть, давая мне 200 OK, что означает, что я являюсь подлинным юзером своей учетки. А теперь посмотрим, что делает хакер в этом всем сценарии, для своих злодеяний....

gallery/выделение_020

Так, а вот тут самое интересное... У нас есть тот же Боб, который посылает какой-то запрос на сервер, обозначим его действие (1). Затем в действии (2), сервак обрабатывает его данные и отдает ему ID сессии, которую в это время перехватывает хакер, в действии (3), с помощью всяких вспомогательных утилит типа Wireshark или ettercap. Можно добавить, что не обязательно делать перехваты, если ID сессий слишком просты, то их можно просто подобрать, методом перебора. В действии (4) этот хацкер в своем браузере прописывает все те данные что перехватил, рефрешит страницу и оказывается под учеткой юзера, которого он перехватил. Опасно, не так ли?

 

Перейдем к тому как обезопасить себя в этом случаи:

 

1) Проверка сеанса:

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

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

 

2) Защита сессии IDs:

- ID сессии должна быть уникальна и рандомная. Дабы, чтоб никто не мог работать под той же сессией, что и вы.

- ID сессии должны защищаться флагами Secure и HTTPonly. С этими атрибутами, при попытке атакующего перехватить ваш запрос, будет скрыта вся информация про ваши куки и сессии вообще.

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

 

3) Защита хранимой сессии:

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

- Подчищать куки в сессии не дожидаясь даты окончания кук

- При разлогиннивании пользователя убивать сессию

 

 

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

gallery/if-you-know-what-i-mean-funnyjunk1-601x316
gallery/выделение_022
gallery/выделение_021

на этой ноте закончим и перейдем к третьему вектору атаки это уязвимости...

 

 

3) Rainbow tables

 

Rainbow tables - либо на наш "Радужные таблицы", используются для раскрытия паролей, преобразованных при помощи различных хеш-функции. Но эти таблицы бессильны для хакерских атак. На данные хешей к, которым применяется и соль, и перец, а еще лучше если хешируется по несколько тысяч раз, последовательно хеш. Вы спросите, а как же потом разхешировать? Все просто надо разшешировать такое количество раз, как и хешировали, в той последовательности раз по заразом как происходил хеш.

gallery/выделение_023
gallery/выделение_024

Так, вот наша таблица, уже сразу с захешеными паролями, но тут еще добавилась колонка Hint, сейчас это распространенная дичь, спрашивать любимое имя собаки и тому подобное, чтоб при забытом пароле могли с легкостью вспомнить что они вводили в поле пароль. Но знайте облегчая жизнь простым пользователям вы и облегчаете работу и злоумышленникам. Допустим у вас увели базу, у вас используется простое хеширование MD5 и есть эти подсказки на пароли. Злоумышленник смотрит, ага вот есть 2 похожих хеша, но разница лишь в подсказке. Смотрим картинку ниже...

gallery/выделение_025

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

gallery/выделение_027

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

gallery/выделение_028

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

 

А теперь давайте перейдем к Соль и Перец, что это такое и для чего оно нужно.

 

gallery/выделение_029

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

gallery/выделение_030

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

gallery/выделение_031

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

 

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

gallery/выделение_032

Тут можно посмотреть побольше инфы о слитых базах, а также их причины. Фейсбук впечатляет))))

 

Как понять что уязвимы:

 

- Разрешаем автоматические атаки (не имеем капчи)

- Разрешаем слабые или известные пароли, такие как «Пароль: 1» или «admin / admin»

- Использует простые текстовые, зашифрованные или слабо хешированные пароли

- Отсутствует или неэффективна многофакторная аутентификация

- Выдает идентификаторы сеанса в URL-адресе, для тех кто отправляет пароли, куки, юзеров в урле либо через GET запросы в API

 

Как защитится:

 

- Многофакторная аутентификация для предотвращения автоматических атак

- Не отправляйте в URL данные для работы с приложением

- Внедрение проверок с плохими паролями 

- Используйте пароли с инструкциями NIST 800-63  в разделе 5.1.1

- Ограничение или увеличение задержки неудачных попыток входа в систему, с появлением капчи

И ПОМНИТЕ ВСЕ ПОКАЗАННОЕ ВЫШЕ, СДЕЛАНО В ЦЕЛЯХ ОБУЧЕНИЯ!!!

МОЖНО ПРИМЕНЯТЬ ТОЛЬКО НА СВОИХ ПРОЕКТАХ, ПОСЛЕ РАЗРЕШЕНИЯ