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

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

Статья Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.

larchik

larchik

Grey Team
07.06.2019
114
263
Привет, Codeby!

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


Роли пользователей.

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

Тоже самое касается и веб-приложений. В приложении, как минимум, должна быть роль администратора и роль обычного пользователя.
Для примера возьмем форум Codeby. Если мы взглянем на документацию XenForo (движок нашего форума), то узнаем, что по умолчанию в системе имеются 4 роли:
- Незарегистрированные пользователи
- Зарегистрированные пользователи
- Администраторы
- Модераторы

Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


Эти роли нельзя отключить, их можно только переименовать, из чего делаем вывод, что они однозначно имеются и в Codeby.

CMS и фреймворки веб-приложений обычно позволяют создавать новые роли и настраивать им уровень доступа в соответствии с потребностями и задачами веб-приложения. Изучив немного разделы форума замечаем, что среди пользователей есть дополнительное разделение по ролям. Каждой из этих ролей соответствует разный уровень доступа к контенту форума:
- Обычный пользователь
- Premium
- Grey team
- Red team
- Gold team

На данном этапе тестирования мы должны определить, какие роли пользователей определены в приложении. Эту информацию можно получить от администратора веб-приложения (если тестирование производится по методам White Box или Grey Box). Если известен фреймворк приложения, можно найти информацию о ролях по умолчанию в документации к фреймворку и в других открытых источниках. Так же мы можем определить роли пользователей изучая функционал и ресурсы самого приложения. При этом нужно помнить, что одному пользователю может быть назначено сразу несколько ролей (к примеру Администратор одновременно может быть и Модератором).

Затем нужно попытаться понять, каким образом присваиваются роли и как меняется уровень доступа к приложению в зависимости от роли.
Будет полезным составить таблицу, вроде такой:

Роль
Как назначается
Уровень доступа
АдминистраторВручнуюСоздание пользователей
Назначение ролей
Удаление пользователей
Создание, редактирование, удаление любого контента
МодераторВручнуюРедактирование и удаление контента пользователей
Блокировка и разблокировка пользователей
Незарегистрированный пользовательАвтоматическиДоступ к бесплатному контенту
read only
Зарегистрированный пользовательАвтоматически при регистрацииДоступ к бесплатному контенту и функциям, возможность оставлять комментарии, загружать файлы на сервер, редактировать свой профиль
Премиум-пользовательАвтоматически после оплаты подписки или администратором вручнуюТо же, что зарегистрированный пользователь + доступ к платному контенту и функциям
.........

Если есть возможность, нужно залогиниться в приложении под разными ролями и проверить, можно ли получить доступ к привилегированным функциям не привилегированным юзерам.

К примеру:
- Входим в приложение под учетной записью админа
- Посещаем какую-нибудь админскую страницу вроде site.com/adminpage.php
- Выходим из учетки админа
- Входим, как обычный пользователь
- Пробуем посетить страницу site.com/adminpage.php

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

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


Регистрация пользователей и аккаунт пользователя.

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

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

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

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


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


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

В ходе тестирования аккаунта ответьте на следующие вопросы:
- Может ли администратор создавать новых пользователей? С какими ролями?
- Может ли администратор удалять учетные записи пользователей?
- Может ли администратор или пользователь удалить свою учетную запись?
- Что происходит с ресурсами удаленных пользователей? Они удаляются или остаются на сервере?


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

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

1. Мы можем определить имя существующего пользователя при попытке логина. Например, если пользователь с указанным именем не существует, приложение возвращает такой ответ:
Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


Если пользователь существует, но введен неверный пароль, веб-приложение возвращает другой ответ:
Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


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


Как видим, при попытке зарегистрироваться вернулся ответ, что пользователь с таким именем уже существует. Таким же образом можно попытаться определить зарегистрированные email-ы.

Другой пример. В WordPress можно определить имена пользователей, которым доступен вход через админку.
Если пользователь существует:
Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


Если пользователь не существует:
Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.



Другие способы определения аккаунтов:

2. Проанализируйте коды ответа от сервера при попытке логина с верным и неверным именем пользователя.
Обратите внимание, что в то время, когда сервер возвращает ответ с кодом 200, веб-приложение может возвращать кастомную страницу 404.
3. Имена пользователей форума, к примеру, можно спарсить, пройдясь по всем веткам форума и мониторя раздел «Пользователи онлайн».

4. Так же обратите внимание на URL, если при попытке логина происходит перенаправление. Например:
http://www.foo.com/err.jsp?User=baduser&Error=0
и
http://www.foo.com/err.jsp?User=baduser&Error=2
В первом случае были отправлены неверный логин и неверный пароль, а во втором случае правильный логин, но неверный пароль.

5. Иногда можно перечислить аккаунты, изменяя имя пользователя прямо в URL.
Пользователь Hacker существует, мы можем просмотреть некоторые данные его аккаунта:
Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


Пользователь SuperHacker тоже существует:
Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


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


6. Еще один вариант, это URL такого вида:
http://www.foo.com/user.php?id=1
Такой подход применяется в соц. сети Вконтакте. В этом случае можно перечислять аккаунты просто изменяя значение id.

7. Имена пользователей могут формироваться на основе реальных имен. Например, если мы точно знаем, что у Фредди Меркьюри имя аккаунта fmercury, то можем предположить, что у Роджера Тейлора имя аккаунта будет rtaylor.

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

На этом все. Всем пока! )
 
Последнее редактирование:
C

Citizen4433

Member
12.09.2019
11
22
Привет, Codeby!

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


Роли пользователей.

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

Тоже самое касается и веб-приложений. В приложении, как минимум, должна быть роль администратора и роль обычного пользователя.
Для примера возьмем форум Codeby. Если мы взглянем на документацию XenForo (движок нашего форума), то узнаем, что по умолчанию в системе имеются 4 роли:
- Незарегистрированные пользователи
- Зарегистрированные пользователи
- Администраторы
- Модераторы

Посмотреть вложение 33065

Эти роли нельзя отключить, их можно только переименовать, из чего делаем вывод, что они однозначно имеются и в Codeby.

CMS и фреймворки веб-приложений обычно позволяют создавать новые роли и настраивать им уровень доступа в соответствии с потребностями и задачами веб-приложения. Изучив немного разделы форума замечаем, что среди пользователей есть дополнительное разделение по ролям. Каждой из этих ролей соответствует разный уровень доступа к контенту форума:
- Обычный пользователь
- Premium
- Grey team
- Red team
- Gold team

На данном этапе тестирования мы должны определить, какие роли пользователей определены в приложении. Эту информацию можно получить от администратора веб-приложения (если тестирование производится по методам White Box или Grey Box). Если известен фреймворк приложения, можно найти информацию о ролях по умолчанию в документации к фреймворку и в других открытых источниках. Так же мы можем определить роли пользователей изучая функционал и ресурсы самого приложения. При этом нужно помнить, что одному пользователю может быть назначено сразу несколько ролей (к примеру Администратор одновременно может быть и Модератором).

Затем нужно попытаться понять, каким образом присваиваются роли и как меняется уровень доступа к приложению в зависимости от роли.
Будет полезным составить таблицу, вроде такой:

Роль
Как назначается
Уровень доступа
АдминистраторВручнуюСоздание пользователей
Назначение ролей
Удаление пользователей
Создание, редактирование, удаление любого контента
МодераторВручнуюРедактирование и удаление контента пользователей
Блокировка и разблокировка пользователей
Незарегистрированный пользовательАвтоматическиДоступ к бесплатному контенту
read only
Зарегистрированный пользовательАвтоматически при регистрацииДоступ к бесплатному контенту и функциям, возможность оставлять комментарии, загружать файлы на сервер, редактировать свой профиль
Премиум-пользовательАвтоматически после оплаты подписки или администратором вручнуюТо же, что зарегистрированный пользователь + доступ к платному контенту и функциям
.........

Если есть возможность, нужно залогиниться в приложении под разными ролями и проверить, можно ли получить доступ к привилегированным функциям не привилегированным юзерам.

К примеру:
- Входим в приложение под учетной записью админа
- Посещаем какую-нибудь админскую страницу вроде site.com/adminpage.php
- Выходим из учетки админа
- Входим, как обычный пользователь
- Пробуем посетить страницу site.com/adminpage.php

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

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


Регистрация пользователей и аккаунт пользователя.

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

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

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

Аккаунт можно получить и без процесса регистрации, если веб-приложение позволяет это сделать. Например в XenForo админ может создать нового пользователя, указав имя, почту, пароль и присвоить ему любую роль из доступных:
Посмотреть вложение 33066

Так же админ может удалить любого пользователя:
Посмотреть вложение 33067

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

В ходе тестирования аккаунта ответьте на следующие вопросы:
- Может ли администратор создавать новых пользователей? С какими ролями?
- Может ли администратор удалять учетные записи пользователей?
- Может ли администратор или пользователь удалить свою учетную запись?
- Что происходит с ресурсами удаленных пользователей? Они удаляются или остаются на сервере?


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

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

1. Мы можем определить имя существующего пользователя при попытке логина. Например, если пользователь с указанным именем не существует, приложение возвращает такой ответ:
Посмотреть вложение 33068

Если пользователь существует, но введен неверный пароль, веб-приложение возвращает другой ответ:
Посмотреть вложение 33069

Кроме того, есть возможность определить имена пользователей в процессе регистрации нового пользователя:
Посмотреть вложение 33070

Как видим, при попытке зарегистрироваться вернулся ответ, что пользователь с таким именем уже существует. Таким же образом можно попытаться определить зарегистрированные email-ы.

Другой пример. В WordPress можно определить имена пользователей, которым доступен вход через админку.
Если пользователь существует:
Посмотреть вложение 33071

Если пользователь не существует:
Посмотреть вложение 33072


Другие способы определения аккаунтов:

2. Проанализируйте коды ответа от сервера при попытке логина с верным и неверным именем пользователя.


3. Имена пользователей форума, к примеру, можно спарсить, пройдясь по всем веткам форума и мониторя раздел «Пользователи онлайн».

4. Так же обратите внимание на URL, если при попытке логина происходит перенаправление. Например:
http://www.foo.com/err.jsp?User=baduser&Error=0
и
http://www.foo.com/err.jsp?User=baduser&Error=2
В первом случае были отправлены неверный логин и неверный пароль, а во втором случае правильный логин, но неверный пароль.

5. Иногда можно перечислить аккаунты, изменяя имя пользователя прямо в URL.
Пользователь Hacker существует, мы можем просмотреть некоторые данные его аккаунта:
Посмотреть вложение 33073

Пользователь SuperHacker тоже существует:
Посмотреть вложение 33074

Пользователь SuperMegaHacker не существует, поэтому мы видим страницу, не связанную ни с каким аккаунтом:
Посмотреть вложение 33075

6. Еще один вариант, это URL такого вида:
http://www.foo.com/user.php?id=1
Такой подход применяется в соц. сети Вконтакте. В этом случае можно перечислять аккаунты просто изменяя значение id.

7. Имена пользователей могут формироваться на основе реальных имен. Например, если мы точно знаем, что у Фредди Меркьюри имя аккаунта fmercury, то можем предположить, что у Роджера Тейлора имя аккаунта будет rtaylor.

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

На этом все. Всем пока! )
Привет, спасибо за статью. Но есть пару моментов которые мне хотелось бы уточнить.
Значит файлы пользователя при его удалении остаются на сервере.
О каких файлах речь? В XenForo почти всё хранится в базе данных, есть только файлы связанные с вложениями (attachments), кэшем шаблонов и виджетов, фраз ну и конечно же аватарами пользователей, поэтому непонятно о каких файлах идёт речь.
Само собой, что к странице adminpage.php у обычного пользователя доступа быть не должно, в противном случае вы нашли уязвимость.
В большинстве случаев - верно, но конкретно с XenForo - это не так. Даже у codeby открыта страница с админкой, но это не значит что она не защищена. Сама по себе админ панель защищена (даже разработчики XF и люди из русской тех.поддержки даже не рекомендуют изменять путь до админки либо ещё что), да и про двухфакторную аутентификацию не стоит забывать.
Что-то не вижу нигде про CSRF токены которые есть в XenForo.
Про роли верно, но не стоит забывать что у XenForo есть приоритет оформления группы, так что у пользователя может быть скрытая админка, к примеру.

Также в таблице о правах админа не увидел о том, что может редактировать плагины, настраивать и т.д. cron задачи и прочее. Вообще, XenForo стал гораздо лучше во второй версии и использует MVC подход, обычно раньше взламывали и сейчас наверное форумы на XF только из-за кривых дополнений. Сейчас же, во второй версии появились finder'ы/ Repository и так далее, прямых каких-то запросов в базу в файлах вы не найдёте, если это конечно не код от Andy, где напрямую используются $db->query.
 
  • Нравится
Реакции: larchik
С

Сергей webware

New member
29.02.2016
4
1
Наконец-то продолжение. Уж было подумал что автор забросил цикл статей. Огромное спасибо тебе автор!!!
 
  • Нравится
Реакции: larchik
c0mb0

c0mb0

Active member
02.10.2018
41
15
Еще такую штуку пробовал, есть ресурс, скажем gazeta-codeby.hy... тут речь идет о крупных проектах, правительственные, газеты, футбольные клубы например... изучаем ресурс, изучаем имя хоста, а затем в шодане гуглим,
например так gazetacodeby, gazeta_codeby, тут включаем фантазию, гуглим с операторами, есть варик нагуглить прошлые хостинг сервера (по имени хоста), ну или прочий стаф связаный с ресурсом, может бекапы, может вебка со схожим хостнеймом, думаю суть ясна, так сказать вектор расширить, хех
 
SooLFaa

SooLFaa

Администратор
15.07.2016
811
1 326
Ещё одно. Много текста ни о чем. Найди байпасс в системе промышленной какой нибудь. Поверь, они там есть.
 
Мы в соцсетях:  ТелеграмВконтактеДзенФейсбукТвиттерЮтуб