Как я могу отслеживать, отправляется ли cookie на домен, отличный от того, с которого он был создан?

Question

Я пытаюсь написать программу, которая проверит, что все файлы cookie, отправленные с этого компьютера, фактически отправляются в домен, с которого они пришли. Это часть более крупного проекта безопасности по обнаружению вредоносных атак на основе файлов cookie (таких как XSS). Основная загвоздка в этом проекте - обнаружение исходящих файлов cookie. Может ли кто-нибудь указать мне правильное направление для мониторинга исходящего HTTP-трафика на информацию cookie? Другая информация о проекте: Это приложение для Windows, написанное на C и многочисленных языках сценариев. Большое спасибо за помощь.

Answer 1

Вы можете использовать надстройку Firefox для чтения всех файлов cookie, которые использует браузер, браузер знает, какие файлы cookie у него есть, и домен, которому они принадлежат. Затем вы можете изменить Tamper-Data , чтобы прослушивать все исходящие http-запросы и искать значение cookie, более того, вы можете отбросить запрос или изменить его перед его передачей.

Это никогда не остановит атакующего. Для злоумышленника тривиально обфусцировать / зашифровать / зашифровать значение куки перед передачей.

HttpOnlyCookies - лучшее (но не полное) решение этой проблемы. Если этот элемент заголовка установлен, и браузер поддерживает его, то javascript не сможет получить доступ к document.cookie. Но злоумышленник может использовать XmlHttpRequest для подделки запросов к системе, таким образом, «катаясь» по аутентифицированному сеансу.

Вам следует ЗАПИСАТЬ XSS , защитить от XSRF, использовать https для всего сеанса и включить HttpOnlyCookies. Я рекомендовал вам прочитать A3: «Сломанная аутентификация и управление сеансами» в 10 лучших Owasp за 2010 год.

Answer 2

Вы можете прослушивать не-SSL-контент, который ваш браузер отправляет по вашему желанию, запустив свой трафик через прокси-сервер и выполнив этот журнал. Вы также можете использовать прокси-сервер для перехвата SSL, если хотите мириться с предупреждениями «небезопасный сертификат».

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

Я согласен со всеми, кто предполагает, что подобное прослушивание не обязательно что-либо доказывает. Также, что своенравное приложение может передавать что-то, но вы пропустите это из-за запутывания.

Answer 3

Вы не можете прослушивать файлы cookie в исходящем запросе.Предполагая, что вы получаете правильные регулярные выражения для обычных форматов идентификаторов сеансов, это все равно ничего не решает.Злоумышленник просто взломает несколько запросов и уклонится от вашего фильтра.Или, возможно, он каким-то образом его зашифрует.

Если это веб-сайт электронной почты / форума с уязвимостью XSS, злоумышленник может просто опубликовать файл cookie на том же общедоступном веб-сайте, а затем прочитать идентификатор сеанса.Ваш фильтр не имеет смысла, потому что даже если он обнаружил cookie в запросе, он отправляется на тот же веб-сайт ... поэтому вы не можете вызвать исключение.

Существует бесчисленное множество способовуклоняться от вашего фильтра.Я не думаю, что это осуществимый проект.