Насколько безопасно использовать переменные сеанса - asp.net/С#

Так что в основном мне интересно, насколько безопасен мой способ использования переменных Session.

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

когда у меня есть это значение, вот где мне интересно, является ли этот способ безопасным способом хранения идентификатора пользователя внутри переменной сеанса uID? во всяком случае, вот как я это делаю,

Session["uID"] = (int)dt.DefaultView[0]["userID"];

FormsAuthentication.RedirectFromLoginPage(username.Text, false);

Response.Redirect("userPage.aspx", false);

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

Заранее благодарим за ваши отзывы

Ответ 1

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

Таким образом, если ваш сервер не взломан, переменные сеанса безопасны. И в случае, если ваш сервер будет взломан, хакер будет иметь доступ только к данным на своей собственной сессии, если только он не найдет способ анализа памяти IIS.

Ответ 2

Очень безопасно, переменные сеанса .NET не совпадают с переменными cookie, которые можно просмотреть с клиентской стороны, переменные сеанса в этом экземпляре доступны только из кода С#.

Таким образом, вы можете быть в безопасности, зная, что переменная Session не может быть отредактирована кем-либо другим, кроме кода, выполняющего фоновый рисунок.

Не полностью связан с вашим вопросом, но может быть полезно знать в вашем случае:

Вы также можете сохранить целый объект в сеансе, чтобы вы могли сохранить пользовательский объект в сеансе, например

user_Class user = new user_Class();
user.UID = 1;
Session["User"] = user;

Затем вы загружаете его обратно при загрузке каждой страницы.

user_Class user = (user_Class)Session["User"];

Затем вы можете получать user.UID с сеанса каждый раз.

Ответ 3

Все хорошо, пока ваш сайт не перерастет один сервер. Затем вам нужно перенести ваш провайдер сеанса на сервер состояния или вернуть его с помощью сервера sql, который в конечном итоге немного сосут.

См. http://msdn.microsoft.com/en-us/library/ms178201%28v=vs.80%29.aspx для получения полного списка проблем, связанных с безопасностью сеанса.

Ответ 4

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

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

Помимо постоянной адресации любого скриптового потенциала кросс-сайта на вашем веб-сайте, вы действительно не можете сделать это без безопасного соединения. Даже тогда это может быть неправильно реализовано.

Ответ 5

Вы все еще уязвимы, даже если ВЫ НЕ СЕРВЕРЫ НЕ КОМПРОМИССИРОВАНЫ сеанс может быть легко захвачен с помощью MITM Attack, и когда злоумышленник получает вашу сессию, он может делать все, что вы можете сделать.

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

Использование SSL

SSL ваш сайт

Создать Hash

Защита сеанса