# Кейс на defensive ## Проблемы и уязвимости схемы 1. Передача пароля в открытом виде GET-запросом. При таком способе пароли будут попадать в логи в незащищенном виде на прокси-серверах. Лучше использовать POST. Только через HTTPS. 2. Передача cookie с именем пользователя. Это не нужно, соответствия между именем пользователя и id сессии должны храниться в БД. Best practice - не передавать вместе с SessionID пользовательские данные. 3. Ограниченный словарь и длина SessionID. Cookie длиной в 11 символов состоит только из цифр, это делает ее уязвимой для брутфорса. Нужно добавить букв и дополнительных символов в алфавит и увеличить длину SessionID. 4. Межсайтовая подделка запроса. Смотрю на запрос с переводом суммы между счетами, так и хочется написать: ``` <input type="hidden" name="to" value="my_account"/> ``` Для [защиты от CSRF](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) можно передавать Anti-CSRF-Token. 5. Username enumeration При неправильно введенном логине выводится сообщение "username admin not found". Это упрощает злоумышленнику работу по подбору валидного логина. Пример более безопасного сообщения - "incorrect username or password". ## Источники * [CSRF](https://portswigger.net/web-security/csrf#:~:text=Cross-site%20request%20forgery%20also,do%20not%20intend%20to%20perform.) * [Session Security](https://beaglesecurity.com/blog/article/session-security.html) * [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) * [Usernane enumeration](https://portswigger.net/web-security/authentication/password-based)