Как защитить MVC RESTful URL от взлома? - PullRequest
Новая
       1

Как защитить MVC RESTful URL от взлома?

3 голосов
/ 15 июня 2011

Недавно я прочитал интересную статью об инциденте с CitiGroup Hacking. http://www.nytimes.com/2011/06/14/technology/14security.html?_r=2&pagewanted=1&ref=technology

Это заставило меня задуматься, скажем, у меня есть таблица конфиденциальных данных о сотрудниках в моей базе данных с 100 000 строк. Таблица имеет первичный ключ с именем Id, который является столбцом Identity.

Сотрудник может войти на веб-портал, и его данные будут получены через URL-адрес RESTful ({Controller} / {Action} / {Id}), например, / Сотрудник / Подробности / 31

Теперь, что мешает мне заменить параметр {Id} на любой параметр (например, Id = 32) и получить детали для Сотрудника № 32? Это то, что случилось с CitiGroup?

Как вы это предотвращаете? то есть когда пользователь уже прошел аутентификацию на веб-портале но не авторизован для просмотра записей других пользователей? Должен ли я использовать какой-то другой конкретный «токен» для клиент в дополнение к Id?

Ответы [ 3 ]

3 голосов
/ 15 июня 2011

Это то, что я сделал для точно такой же ситуации, сначала я объявил расширение объекта: 

public static bool Editable(this EXPENSE_OBJ e)
{
    if (e != null)
    {
       UserRepository ur = new UserRepository();

       if (ur.CurrentUser().UserId == e.UserId) //Check if the user owns the claim
       {
           return true; //User owns the claim
       }
       else
       {
           return false; //User does not own the claim
       }

    }
}

А затем в контроллере: 

public ActionResult Details(id)
{
    var item = repo.GetItem(id);
    if(!item.Editable())
    {
         return View("InvalidURL");
    }

    ...

}
0 голосов
/ 15 июня 2011

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

Другая вещь, которую вы можете сделать, это использовать Guid вместо int для вашего первичного ключа. Это не позволит людям угадать первичный ключ.

0 голосов
/ 15 июня 2011

Вы можете использовать API ролей и членства ASP.NET. Если вы уже делаете это, все, что вам нужно сделать, чтобы начать, это пометить контроллер проверкой IsUserInRole. Вы можете найти больше информации о классе ролей здесь:

Класс ролей MSDN

...