Подход безопасности в веб-приложении
Я разрабатываю веб-приложение в ASP.NET / C#, где у каждого зарегистрированного пользователя есть способность добавить/изменить/удалить строки на основе их идентификатора пользователя.
Возьмите этот пример:
Я собираюсь отредактировать свой маршрут на странице /route.aspx?routeid=854 который принадлежит мне (идентификатор пользователя: 1).
Но потому что я - любопытный парень, я пытаюсь получить доступ /route.aspx?routeid=855 который принадлежит другому пользователю (идентификатор пользователя: 2).
Как я могу лучше всего избежать людей от доступа к другим данным народов? Я должен отправить каждый идентификатор пользователя (от сессии) с каждым вызовом базы данных, я должен проверить пользователя/пароль на каждой загрузке страницы или каков лучший и самый безопасный подход?
Я надеюсь, что сделал это достаточно ясным.
2 ответа
НЕ ПОВТОРИТЕ КОЛЕСО
Редактировать: Сохранение UserId - вам не обязательно. Вы можете получить его от MembershipProvider в любое время, если пользователь, конечно, вошел в систему:
MembershipUser user = Membership.GetUser();
Guid UserID = user.ProviderUserKey;
Мне кажется, вам нужно реализовать поставщик членства ASP.NET. Прочтите этот ресурс: http://odetocode.com/articles/427.aspx
Также хорошая серия от Скотта Гатри: http://weblogs.asp.net/scottgu/ archive / 2006/02/24 / ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx
В общем, используйте следующий подход: используйте проверку подлинности с помощью форм для проверки личности пользователя. Это сторона безопасности аутентификации. То есть определение пользователя - это то, кем они себя называют, обычно с помощью имени пользователя и пароля.
Вторая часть безопасности - это авторизация, которая происходит, когда вы знаете, кто является пользователем. Это в основном состоит из определения того, к каким ресурсам имеет доступ аутентифицированный пользователь.Зрелая система будет включать в себя следующие объекты:
User: may contain extended profile information captured on registration
Resource: a page or other resource that can be restricted.
Group: a group of users who can access resources due to their group membership (groups are granted resource access)
Role: a type of user such as Administrator/Developer/Salesperson.
Таким образом, чтобы предоставить пользователю доступ к routeid 854 (ресурс), вы можете предоставить ресурс непосредственно пользователю или если есть несколько пользователей, которые должны иметь доступ к этому ресурсу, а те пользователи образуют естественную группу, затем создают эту группу, предоставляют ресурс группе и добавляют пользователя в группу.
Затем вы можете получить доступ к User.Resources по идентификатору ресурса или вы можете защитить всю страницу с помощью
if(!User.IsInRole("RoleName"))
{
//redirect to access denied page
}
. Есть много хороших вещей, доступных с использованием модели поставщика.
Изменить: кое-что, о чем следует помнить, если вы решите сохранить информацию профиля о своих пользователях: реализация ProfileProvider по умолчанию не особенно хороша. Скотт Гатри написал хорошую статью о провайдере, основанном на таблицах, который лучше: http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx
Лучше всего отправить userId в базу данных с routeId, чтобы узнать, может ли пользователь получить к нему доступ.
что-то вроде:
select * from route where routeId=@routeId and userId=@userId
Если вы используете что-то вроде Linq, вы можете создать гораздо лучшую модель безопасности, применив ограничение пользователя, например, с помощью многоразовой функции, например:
public Route Get(int routeId, int userId)
{
var query repository.Get<Route>().Where(r => r.Id == routeId);
query = applySecurityModel(query, userId);
return query.FirstOrDefault();
}
private IQueryable<T> applySecurityModel<T>(IQueryable<T> query, int userId) where T : ISecurable
{
return query.Where(t => t.UserId == userId);
}
public interface ISecurable
{
int UserId { get; set; }
}
public class Route
{
int Id { get; set; }
int UserId { get; set; }
}