Оставляя значение ASPNET_SessionId в скрытом поле html, есть проблемы с безопасностью? - PullRequest
1 голос
/ 03 сентября 2011

существует ли проблема безопасности, связанная с оставлением значения идентификатора сеанса ASP.NET в скрытом поле html?

Это для того, чтобы обойти проблему при использовании uploadify , которая основана на работающей флэш-памяти и имеет известные проблемы ( эта ссылка, ищите 'STEP 6' ) в отправляю правильные куки на сервер через ajax-запрос, поэтому у меня возникают проблемы при попытке аутентификации в моем сеансе аутентификации.

Путем помещения значения SessionId в скрытое поле, оно позволяет мне получить правильное значение и после некоторого кода в global.asax успешно обойти эту проблему.

Я что-то делаю не так? Кстати, я использую 128-битное SSL-шифрование.

Спасибо !!!

EDIT: Дело в том, что если идентификаторы сессии всегда присутствуют в сообщении / запросе https, какая разница, если я сохраню их в качестве аргумента записи или в виде значения cookie, отправленного в запросе http? Если кто-то, кто перехватывает мое требование и получает мой SessionId, может легко обойти защиту, каков наилучший способ реализовать аутентификацию ???

Ответы [ 2 ]

3 голосов
/ 03 сентября 2011

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

Записав его на страницу, вы упростите кражу с помощью методов XSS.и другие.Сессия не совсем безопасна, поэтому .NET имеет свою собственную схему аутентификации с использованием шифрования и полностью отделена от сессии.

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

Способ реализации аутентификации - использование файла cookie аутентификации .NET и, при необходимости, использование MembershipProvider.Это создает зашифрованный файл cookie на основе уникального ключа компьютера.Только этот сервер может расшифровать cookie для аутентификации пользователя.Если кто-то присвоит вам идентификатор сеанса или украдет его, он все равно не сможет аутентифицироваться как вы.

Конечно, кто-то также может украсть ваш файл cookie для аутентификации, но есть возможность обслуживать этот файл только через SSL длязащититесь от этого, и он не может быть навязан вам из-за шифрования.

1 голос
/ 03 сентября 2011

Это открывает дыру в безопасности, но ничем не отличается от использования сессий без файлов cookie, в которых идентификатор сессии хранится в URL.

Использование HTTPS помогает.

...