Уязвимости регистрации: максимизация угрозы

Небольшое изучение уязвимостей в процессах регистрации и отправки приглашений пользователям
​

Неоднократно сталкивался с подобным кейсом в различных компаниях:

1. Используем функцию приглашения пользователя и указываем там свою резервную почту
2. Получаем приглашение себе на резервную почту
   
   
3. Переходим по ссылке из приглашения, задаем пароль, перехватываем запрос и изменяем адрес электронной почты в запросе через параметр "email" на почту жертвы
   
   
4. Получаем аккаунт, зарегистрированный на чужую почту без подтверждения от её владельца.

​

Но как можно повысить импакт?

• попробовать подставить почту существующего пользователя, что может привести к смене его пароля и, как следствие, захвату аккаунта
  
  
• если предыдущий трюк не сработал, то можно еще проверить на CSRF. Недавно на багбаунти попался похожий кейс, где просто подстановка почты жертвы не работала, но при CSRF с куками жертвы позволяла поменять ему адрес почты и/или пароль без подтверждения
  
  
• попробовать зарегистрировать корпоративные учетки, например, такие как shdw@company.com, admin@company.com и т.д. Для корпоративных учеток может быть доступен дополнительный (в том числе админский) функционал, недоступный обычным пользователям.

​