Веб-безопасность: наихудшая ситуация

Question

В настоящее время я создал систему, которая проверяет IP-адрес пользователя, браузер и файл cookie со случайной строкой, чтобы определить, является ли он администратором.

В худшем случае кто-то крадет мой cookie, использует тот же браузер, что и я, и маскирует его IP-адрес, чтобы он отображался как мой. Есть ли еще один уровень безопасности, который я должен добавить в свой сценарий, чтобы сделать его более безопасным?

РЕДАКТИРОВАТЬ: Чтобы уточнить: мой сайт не принимает абсолютно никаких комментариев от пользователей. Я просто создаю внутреннюю административную панель, чтобы упростить обновление записей в базе данных.

Answer 1

Проверка браузера - это полная и полная трата кода. Нет смысла писать защищенную систему, которая является тривиальной , которую злоумышленник может обойти. Если злоумышленник получит идентификатор сеанса через xss или прослушивание строки, он также получит ваш «пользовательский агент».

Проверка IP-адреса заставит злоумышленника «покататься» на сеансе с XSS + XHR или XSRF. Это потому, что похищенный токен не будет работать на его коробке. К сожалению, это также создает проблемы для корпоративных сетей, которые используют балансировку исходящей нагрузки между несколькими IP-адресами.

HTTPS - это , который должен использоваться для всего сеанса . Ни в коем случае ваш токен не может быть отправлен по HTTP. Это ясно изложено в «Сломанной аутентификации и управлении сессиями» в Топ-10 OWASP за 2010 год , которую вы обязательно должны прочитать, если пишете обработчик сеанса.

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

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

Я также подозреваю, что вы не приняли во внимание XSS и XSRF. Неважно, насколько сильна ваша сессия в других областях, если вы оставите без внимания основную уязвимость. Убедитесь, что вы сканируете свое приложение, используя бесплатный xss сканер или wapiti с открытым исходным кодом. Имейте в виду, что ни один тест не будет точно определять XSRF, и каждый отдельный запрос в вашем приложении уязвим, если вы не исправите его.

Answer 2

Правильный способ защиты доступа администратора - использование HTTPS .

Есть две атаки на HTTPS:

1. Троян на вашем компьютере
2. Злоумышленник использует легитимные, но вредоносные сертификаты

Ясно, что (1) является наиболее вероятным. Но, с другой стороны, ваш троянец, скорее всего, исчезнет после получения банковских реквизитов и тому подобного, и злоумышленник не собирается просеивать всю вашу информацию, чтобы обнаружить и изучить ваши отношения с администратором на веб-сайте.

Ясно, что если атакующий изощрен в отношении (2), вы не в состоянии выиграть.

Это настолько маленькая поверхность атаки, насколько вы можете.

Answer 3

Одна вещь, которую я скучаю, помимо всего, что упоминается, это исправление "всех других проблем безопасности".

• Если у вас есть SQL-инъекция, ваши усилия по созданию cookie-файлов - пустая трата времени.
• Если у вас есть VSR XSRF, ваши усилия на печенье - пустая трата времени.
• Если у вас XSS, ....
• Если у вас есть ГЭС, ...
• Если у вас есть ...., ....

Вы получаете точку.

Если вы действительно хотите охватить все, я предлагаю вам очистить ландшафт уязвимости и построить дерево атак (Брюс Шнайер).

Answer 4

Https является обязательным, но вы также должны согласиться с тем, что ни один сайт не может быть на 100% безопасным. Единственный способ добиться значительного улучшения безопасности - это очень короткие тайм-ауты сеансов и предоставление пользователям аппаратных токенов, но даже токены могут быть украдены.