Существует тип атаки, к которой мы склонны и которую мы часто упускаем из виду, это подделка межсайтовых запросов или CSRF, которая отвечает за обман нашего приложения для получения данных, которые не поступают из домена, где оно размещено.
Этот тип атаки весьма вреден, поскольку он позволяет обманутому пользователю использовать свою аутентификацию для ввода данных в нашу базу данных. Представьте, что при атаке такого типа может быть введен административный пользователь или, возможно, ложные новости. в нашем разделе новостей.
Как работает CSRF?
Как мы объяснили, эта атака обманывает наше приложение, чтобы получать данные, которые не поступают от него самого, для этого он использует преимущества работы протоколов, таких как HTTP и его различные методы, с этим злоумышленник может создать форму и указать на наш контроллер.
Чтобы проиллюстрировать эту атаку, давайте посмотрим на следующий контроллер, который уязвим для этих типов атак:
Здесь мы можем наблюдать, как мы получаем данные непосредственно из нашей формы, и это неплохо, единственная проблема заключается в том, что мы не говорим нашему приложению, что оно должно проверять его происхождение, и злоумышленник может сгенерировать скрипт, подобный следующему:
Здесь ясно, что происходит, при загрузке этой страницы отправляется форма, которая указывает на конкретную запись базы данных, эта форма указывает на действительный контроллер, поэтому, если аутентифицированный пользователь направляется на эту страницу Вероятно, у нас проблемы.
Как избежать этой атаки?
Несмотря на фатализм, который можно увидеть, эту атаку можно избежать, для этого нам нужно только сделать некоторые проверки, которые гарантируют, что данные получены из нашего приложения, для этого мы можем использовать некоторые из этих методов:
Ссылка на домен
Это состоит в проверке того, из какого домена поступил запрос, и мы гарантируем, что это справедливо по отношению к домену, где размещено наше приложение, единственная проблема или недостаток в том, что если мы перенесем наше приложение домена, нам может понадобиться пересмотреть проверку в случае, если мы не динамический факт. Также можно сделать ложную ссылку, воспользовавшись уязвимостями таких приложений, как Adobe Flash .
Токен создан
С помощью этой опции мы делаем то, что в нашей форме генерируется токен, который уникален для каждого пользователя, поэтому наше приложение после получения форм проверяет, что токен совпадает, что позволяет принимать данные или нет. Это наиболее часто используемый вариант, поскольку он очень прост в реализации и имеет мало недостатков или вообще не имеет их.
В случае сгенерированного токена ASP.NET MVC содержит несколько методов, которые могут нам помочь, основным из которых является @ Html.AntiForgeryToken (), который генерирует секретный ключ, с помощью которого наше приложение может проверять формы.
Затем мы видим, что есть больше областей, чем мы думаем, и что мы должны заботиться о наших приложениях, поэтому мы должны информировать себя и знать о том, как происходят атаки, чтобы найти способы их избежать.
СТАТЬИ