Единый знак cookie, удаленный программным обеспечением для защиты от шпионских программ

У нас есть единый вход для реализации для семейства веб-сайтов, где cookie аутентификации поступает из корневого домена (например, bar.com), что позволяет им регистрироваться в дочернем домене (например, foo.bar.com). Реализация выполняется на C#, используя стандартную проверку подлинности .net.Единый знак cookie, удаленный программным обеспечением для защиты от шпионских программ

К сожалению, некоторые из наших пользователей имеют свои файлы cookie для проверки подлинности, удаленные антишпионским программным обеспечением. Я смог воссоздать эту ситуацию, используя PC Tools Anti Spyware и IE8.

Практический результат заключается в том, что пользователи заходят на сайт, переходят на другую страницу, а затем снова просят войти в систему.

Печенье помечено как печенье с отслеживанием низкого риска с помощью антишпионского программного обеспечения.

Есть ли способ сделать печенье более привлекательным для явно придирчивых вкусов антишпионского программного обеспечения нашего пользователя?

Update:

Я посмотрел в ведущий "" проблема, и это красная сельдь. IE Doesn't care и, как выяснилось через this post, RFC 2965 Specification требует, чтобы разработчики поставляли ведущую точку.

Дальнейшее чтение привело меня к статье "Privacy alert: Cookie variants can be used to skirt blockers, anti-spyware tools". По сути, многие веб-сайты используют субдомены в качестве способа скрытия файлов cookie.

Похоже, что некоторые антишпионские программы будут уважать объявления P3P (Platform for Privacy Preferences) в родительском домене. К сожалению, из-за отсутствия поддержки от разработчиков браузеров, работа была приостановлена на P3P.

На этом этапе я думаю, что решение проблемы будет, как предложил один пользователь: субдомену необходимо будет создать свой собственный файл cookie для проверки подлинности.

источник

2010-02-16 aboy021

Я думаю, что антишпионское программное обеспечение работает как рекламируемое. Рассмотрите возможность рефакторинга, чтобы у вас был единственный портал signon (например, login.bar.com), который перенаправляет на нужный ресурс после аутентификации. –

Я не рассматриваю это как связанное с программированием. –

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

Вы можете проверить, что ваш auth cookie использует домен .bar.com, который должен работать на www.bar.com, foo.bar.com, etc.bar.com.

Это точное поведение зависит от браузера, но это обычная практика, позволяющая использовать один и тот же файл cookie для нескольких поддоменов. Обратите внимание, что если ваш auth cookie изначально установлен www.bar.com, то хороший браузер должен отклонить его для foo.bar.com, но не для foo.www.bar.com

Имею ли я смысл? :-)

Update: Похоже, вы можете переопределить domain в <forms разделе вашего Web.config, вот link. Я бы начал там.

источник

2010-02-16 23:51:16

Я боюсь, что мы в настоящее время используем _.bar.com_, используя технику, изложенную в полезной ссылке, которую вы предоставили. – aboy021

@ aboy021: Я боялся этого. Если это так, то я не уверен, что вы можете сделать, чтобы преодолеть антишпионское программное обеспечение, которое предпочитает игнорировать стандарты. Вы можете попробовать дублировать куки-файлы на нескольких конкретных доменах, но я полагаю, что антишпионские программы также будут жаловаться на то, что вы создаете файлы cookie для другого домена, чем тот, к которому в данный момент обращается пользователь. Удачи вам в этом. –

Вы можете проверить передачи по умолчанию в спецификациях протокола SAML SSO, чтобы иметь больше идей. Архив со всеми документами находится здесь http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip «Утверждения и протоколы» для описания протокола и «Привязки» для возможных передач (в частности, при перенаправлении и POST).

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

источник

2010-02-17 08:20:55

Я думаю, что этот подход, безусловно, будет работать. Пока я собираюсь посмотреть, могу ли я получить файл cookie в форме, которую антишпионское ПО находит приемлемым. – aboy021

Я построил такую систему. Существует один домен, который делает логин (сайт auth).Если вход успешно завершен, он перенаправляет пользователя с сайта auth на сайт, инициировавший вход с одним маркером. Затем этот сайт устанавливает свой собственный файл cookie и раскапывает вашего дядю. При выходе из системы вы должны перейти непосредственно на сайт auth, который удаляет файл cookie как часть перенаправления на сайт. Затем ваш сайт удаляет свой собственный файл cookie. Хахаха надеется, что это имеет смысл!

источник

2010-02-17 21:32:52 superlogical

К сожалению, мы все равно хотели бы использовать возможности единого входа, поэтому, если они войдут в 'bar.com', они будут эффективно зарегистрированы в' foo.bar.com' и 'cat.bar.com'. Я думаю, что с однократным токеном мы потеряем это. Основываясь на тестах, которые я делал, родительский домен cookie удаляется только через несколько секунд, поэтому мы должны использовать его как одноразовый токен для затронутых пользователей. – aboy021

.. Итак, вы вошли в foo.bar.com. Вы отправляетесь на cat.bar.com, сервер замечает, что вы не вошли в кошку, поэтому перенаправляет вас обратно на foo.bar.com, который знает, что вы вошли в систему, и генерирует токен и отправляет вас обратно на cat.bar.com, который регистрирует вы в. Если вы не вошли в систему на foo.bar.com, он отправляет вас обратно кошке с другим токеном, говорящим, что вы не вошли в систему, поэтому не пытайтесь авто аутентифицировать меня. Это может сработать? – superlogical

Единый знак cookie, удаленный программным обеспечением для защиты от шпионских программ

ответ

Смежные вопросы