---
# System prepended metadata

title: Кейс на defensive

---

# Кейс на 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)