Безопасный способ удалить запись в ASP.Net MVC - PullRequest
Новая
       26

Безопасный способ удалить запись в ASP.Net MVC

0 голосов
/ 29 августа 2018

Я хочу удалить продукт с моего веб-сайта ASP.Net MVC 5. Я хочу знать, достаточно ли добавления [AntiForgeryToken] и [Authorize] для защиты операции удаления?

View 

 <p>Delete: @Model.Name</p>
 @using (Html.BeginForm("Delete", "ProductController", FormMethod.Post, new { ProductId = Model.ProductId }))
 {
    @Html.AntiForgeryToken()
    <button type="submit">Delete</button>
 }

Контроллер 

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult Delete(long ProductId)
{
    /* Do I need to check if the logged in User has permission to delete the product?
    var product = ProductRepository.Get(Id);
    if (product.Creator == User.Identity.GetUserId<long>())
    {
        ProductRepository.Delete(ProductId);
    }
    */

    // or, can I avoid the trip to DB and just delete the record?        
    ProductRepository.Delete(ProductId); 
}

Сценарий: Хакер регистрируется на моем сайте и создает действительный аккаунт. Теперь хакер просматривает свой собственный продукт и, очевидно, у него есть AntiForgeryToken. Может ли он теперь просто изменить ProductId в браузере и опубликовать запрос на удаление чужого продукта?

1 Ответ

0 голосов
/ 29 августа 2018

Краткий ответ. Этого недостаточно.

Маркеры защиты от подделки просто говорят, что лицо, отправляющее запрос на исходную страницу, является лицом, производящим обновление.

Атрибут base authorize только подтверждает, что пользователь вошел в систему.

То, что вы ищете, это безопасность данных. На собственном сайте Microsoft есть пример .

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

Скажем, у вас есть URL

https://example.com/product/edit/13

что мешает пользователю / хакеру угадать

https://example.com/product/edit/12 или же https://example.com/product/edit/14

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

Это точный сценарий, который FISERV обнаружил для раскрытия другой информации о клиенте

из статьи

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

...