Привет, Codeby!
Продолжаем изучать пентест веб-приложений и OWASP Testing Guide. Сегодня поговорим о ролях пользователей, о процессе регистрации и получении аккаунта, а так же об определении имен и аккаунтов пользователей, зарегистрированных в системе.
Соответствующий раздел OWASP Testing Guide -
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
Роли пользователей.
На современных предприятиях доступ к ресурсам со стороны пользователей должен быть разграничен. Представьте себе завод, на котором для управления процессами производства используется какая-нибудь система вроде 1С. К системе должны иметь доступ складские работники для приемки сырья, хранения продукции, перемещения всего этого между участками производства и тд. К системе должны иметь доступ начальники производственных участков для планирования работы, учета выпуска продукции. К системе могут иметь доступ сотрудники отдела кадров или бухгалтерии, что бы получать показатели рабочих и соответственно начислять зарплату. Сами рабочие могут иметь доступ к этой системе, что бы контролировать собственное рабочее время.
Само собой, что доступ к такой системе для каждой из групп пользователей должен быть настроен так, что бы максимально была обеспечена безопасность системы. Кладовщику незачем знать показатели других рабочих, а бухгалтеру не нужна информация о продукции, хранящейся на складе.
Тоже самое касается и веб-приложений. В приложении, как минимум, должна быть роль администратора и роль обычного пользователя.
Для примера возьмем форум Codeby. Если мы взглянем на документацию XenForo (движок нашего форума), то узнаем, что по умолчанию в системе имеются 4 роли:
- Незарегистрированные пользователи
- Зарегистрированные пользователи
- Администраторы
- Модераторы
Эти роли нельзя отключить, их можно только переименовать, из чего делаем вывод, что они однозначно имеются и в Codeby.
CMS и фреймворки веб-приложений обычно позволяют создавать новые роли и настраивать им уровень доступа в соответствии с потребностями и задачами веб-приложения. Изучив немного разделы форума замечаем, что среди пользователей есть дополнительное разделение по ролям. Каждой из этих ролей соответствует разный уровень доступа к контенту форума:
- Обычный пользователь
- Premium
- Grey team
- Red team
- Gold team
На данном этапе тестирования мы должны определить, какие роли пользователей определены в приложении. Эту информацию можно получить от администратора веб-приложения (если тестирование производится по методам White Box или Grey Box). Если известен фреймворк приложения, можно найти информацию о ролях по умолчанию в документации к фреймворку и в других открытых источниках. Так же мы можем определить роли пользователей изучая функционал и ресурсы самого приложения. При этом нужно помнить, что одному пользователю может быть назначено сразу несколько ролей (к примеру Администратор одновременно может быть и Модератором).
Затем нужно попытаться понять, каким образом присваиваются роли и как меняется уровень доступа к приложению в зависимости от роли.
Будет полезным составить таблицу, вроде такой:
Если есть возможность, нужно залогиниться в приложении под разными ролями и проверить, можно ли получить доступ к привилегированным функциям не привилегированным юзерам.
К примеру:
- Входим в приложение под учетной записью админа
- Посещаем какую-нибудь админскую страницу вроде site.com/adminpage.php
- Выходим из учетки админа
- Входим, как обычный пользователь
- Пробуем посетить страницу site.com/adminpage.php
Само собой, что к странице adminpage.php у обычного пользователя доступа быть не должно, в противном случае вы нашли уязвимость.
Так же, выполнив вход под каждой ролью нужно пройтись по сайту веб-спайдером. Так можно обнаружить новые точки входа. После этого можно выполнить поиск скрытых файлов и директорий в тех местах, которые недоступны для пользователей с другими ролями.
Для того, что бы выполнить этот этап тестирования, нужно пройти регистрацию на веб-сайте во всех ролях, которые доступны.
Регистрация пользователей и аккаунт пользователя.
Многие веб-приложения предоставляют пользователю возможность зарегистрироваться. Регистрация, как правило, дает пользователю более широкий доступ к функциям и ресурсам приложения. Процесс регистрации нового пользователя чаще всего происходит в автоматическом режиме, так как пользователей может быть много и регистрировать каждого вручную будет невозможно. Однако во многих корпоративных веб-приложениях для регистрации пользователя требуется участие администратора.
Тестирование процесса регистрации заключается в том, что бы получить ответы на следующие вопросы:
- Возможна ли регистрация в целевом приложении?
- Регистрация происходит в автоматическом или ручном режиме?
- Может ли один и тот же человек зарегистрироваться несколько раз?
- Можно ли зарегистрироваться в разных ролях?
- Требуется ли подтверждение личности при регистрации и какое?
- Можно ли предоставлять ложные или чужие идентификационные данные?
После регистрации пользователю предоставляется аккаунт, который мы тоже должны протестировать.
Аккаунт можно получить и без процесса регистрации, если веб-приложение позволяет это сделать. Например в XenForo админ может создать нового пользователя, указав имя, почту, пароль и присвоить ему любую роль из доступных:
Так же админ может удалить любого пользователя:
Обратите внимание, при удалении пользователя мы видим предупреждение, что контент, созданный данным пользователем, не будет удален. Значит файлы пользователя при его удалении остаются на сервере.
В ходе тестирования аккаунта ответьте на следующие вопросы:
- Может ли администратор создавать новых пользователей? С какими ролями?
- Может ли администратор удалять учетные записи пользователей?
- Может ли администратор или пользователь удалить свою учетную запись?
- Что происходит с ресурсами удаленных пользователей? Они удаляются или остаются на сервере?
Перечисление имен пользователей.
Целью этого теста является проверка возможности определения имен существующих аккаунтов путем взаимодействия с механизмом аутентификации веб-приложения. Иначе говоря, мы будем отправлять приложению верные/неверные учетные данные и смотреть, как оно реагирует. В случае успеха теста в дальнейшем это поможет при подборе паролей к аккаунтам.
1. Мы можем определить имя существующего пользователя при попытке логина. Например, если пользователь с указанным именем не существует, приложение возвращает такой ответ:
Если пользователь существует, но введен неверный пароль, веб-приложение возвращает другой ответ:
Кроме того, есть возможность определить имена пользователей в процессе регистрации нового пользователя:
Как видим, при попытке зарегистрироваться вернулся ответ, что пользователь с таким именем уже существует. Таким же образом можно попытаться определить зарегистрированные email-ы.
Другой пример. В WordPress можно определить имена пользователей, которым доступен вход через админку.
Если пользователь существует:
Если пользователь не существует:
Другие способы определения аккаунтов:
2. Проанализируйте коды ответа от сервера при попытке логина с верным и неверным именем пользователя.
3. Имена пользователей форума, к примеру, можно спарсить, пройдясь по всем веткам форума и мониторя раздел «Пользователи онлайн».
4. Так же обратите внимание на URL, если при попытке логина происходит перенаправление. Например:
и
В первом случае были отправлены неверный логин и неверный пароль, а во втором случае правильный логин, но неверный пароль.
5. Иногда можно перечислить аккаунты, изменяя имя пользователя прямо в URL.
Пользователь Hacker существует, мы можем просмотреть некоторые данные его аккаунта:
Пользователь SuperHacker тоже существует:
Пользователь SuperMegaHacker не существует, поэтому мы видим страницу, не связанную ни с каким аккаунтом:
6. Еще один вариант, это URL такого вида:
Такой подход применяется в соц. сети Вконтакте. В этом случае можно перечислять аккаунты просто изменяя значение id.
7. Имена пользователей могут формироваться на основе реальных имен. Например, если мы точно знаем, что у Фредди Меркьюри имя аккаунта fmercury, то можем предположить, что у Роджера Тейлора имя аккаунта будет rtaylor.
После выполнения вышеописанных тестов у вас должно быть понимание, какие роли пользователей имеются в приложении, как они присваиваются, какие роли можно получить при регистрации на сайте или другими путями. Вероятно, у вас будет список имен зарегистрированных пользователей, к аккаунтам которых в дальнейшем можно попробовать подобрать пароли. Особенно будут интересны аккаунты с ролями админов, модераторов и тд., так как в случае получения более высоких привилегий расширятся возможности для дальнейшей атаки. Сейчас подбирать пароли к ним рано, так как мы еще знаем, какова политика приложения в отношении паролей, есть ли ограничения на количество символов, на сложность пароля и тд. Выяснив это, мы сможем подобрать или составить наиболее подходящий словарь паролей.
Если в ходе тестирования были обнаружены новые точки входа, нужно записать их и указать условия, при которых эти точки входа доступны (например только при логине в приложении от имени обычного пользователя). Тоже самое касается найденых файлов и директорий. Они должны быть изучены на предмет утечек информации и скрытого функционала.
На этом все. Всем пока! )
Продолжаем изучать пентест веб-приложений и OWASP Testing Guide. Сегодня поговорим о ролях пользователей, о процессе регистрации и получении аккаунта, а так же об определении имен и аккаунтов пользователей, зарегистрированных в системе.
Соответствующий раздел OWASP Testing Guide -
Ссылка скрыта от гостей
Как стать хакером и как взломать сайт или беглое знакомство с OWASP Testing Guide
В этой статье я попробую ответить на два самых часто задаваемых вопроса на тематических форумах
Введение в пентест веб-приложений: поиск утечек информации с помощью поисковых систем
Сегодня получим небольшую дозу теории и приступим к практической части
Пентест веб приложений: определение веб-сервера, изучение robots.txt, определение приложений на веб-сервере.
Сегодня научимся определять поставщика и версию веб-сервера, искать веб-приложения на сервере и взглянем на robots.txt.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
При тестировании веб-приложений методом BlackBox у нас, как правило, не будет доступа ко всем исходным кодам приложения
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Сегодня мы научимся определять фреймворк и веб-приложение, а так же составим карту архитектуры приложения
Пентест веб-приложений: Тестирование конфигурации инфраструктуры приложения. Расширения файлов.
Тестирование безопасности платформы, на которой развернуто веб-приложение
Пентест веб-приложений: Обнаружение резервных копий, старых и забытых файлов. Поиск административных интерфейсов и подбор паролей к ним.
В данной статье будет рассмотрена тема забытых файлов на сервере, устаревших файлов, бэкапов, временых файлов
Пентест веб-приложений: Тестирование HTTP-методов, HSTS, кроссдоменных политик, прав доступа к файлам.
В этой статье определим, какие HTTP-методы поддерживаются веб-сервером; узнаем, как метод TRACE связан с атакой XST
Роли пользователей.
На современных предприятиях доступ к ресурсам со стороны пользователей должен быть разграничен. Представьте себе завод, на котором для управления процессами производства используется какая-нибудь система вроде 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. Проанализируйте коды ответа от сервера при попытке логина с верным и неверным именем пользователя.
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.
После выполнения вышеописанных тестов у вас должно быть понимание, какие роли пользователей имеются в приложении, как они присваиваются, какие роли можно получить при регистрации на сайте или другими путями. Вероятно, у вас будет список имен зарегистрированных пользователей, к аккаунтам которых в дальнейшем можно попробовать подобрать пароли. Особенно будут интересны аккаунты с ролями админов, модераторов и тд., так как в случае получения более высоких привилегий расширятся возможности для дальнейшей атаки. Сейчас подбирать пароли к ним рано, так как мы еще знаем, какова политика приложения в отношении паролей, есть ли ограничения на количество символов, на сложность пароля и тд. Выяснив это, мы сможем подобрать или составить наиболее подходящий словарь паролей.
Если в ходе тестирования были обнаружены новые точки входа, нужно записать их и указать условия, при которых эти точки входа доступны (например только при логине в приложении от имени обычного пользователя). Тоже самое касается найденых файлов и директорий. Они должны быть изучены на предмет утечек информации и скрытого функционала.
На этом все. Всем пока! )
Последнее редактирование:
