Файл: Web'cepbep.docx

роли есть разрешение), щелкните второй раз — и зеленая галочка изменится на красный крестик, означающий запрет.




Рис. 6.2. Права доступа




Обязательно заблокируйте административную учетную запись sa и лучше исполь­зуйте авторизацию Windows. В MS SQL Server есть два вида авторизации:

• 
  авторизация Windows — для подключения к MS SQL Server используется учет­ная запись Windows. В MS SQL Server 2000 и более поздних версиях этот режим предполагается по умолчанию, как более безопасный;
  
• 
  смешанный режим — помимо учетных записей Windows, может быть создана учетная запись MS SQL Server. Этот режим использовать не рекомендуется.
  

Смешанный режим не рекомендуется, сейчас Microsoft советует использовать Ac­tive Directory и возлагать на нее управление паролями и авторизацию.

2. 1   ...   10   11   12   13   14   15   16   17   18

---

Защита от инъекции в .NET

Для работы с базами данных в C# есть класс Sqlcommand, которому нужна строка с SQL-запросом и объект подключения к базе данных.

string sql = "select * from user where username= @u";

SqlCommand cmd = new SqlCommand(sql, connection);

cmd.Parameters.Add(

new SqlParameter() { ParameterName = "u", Value = "admin" }

);

SqlDataReader reader = cmd.ExecuteReader();

Если в PHP параметры начинаются с двоеточия, то в C# — с символа @, после чего идет имя параметра.

Теперь мы должны предоставить параметру значение. Параметры связываются со значениями в свойстве Parameters.

В случае с C# правило защиты от SQL Injection остается тем же самым - использу­ем параметры и в SQL-запросе не используем + для того, чтобы получить финаль­ный запрос. Например, следующая строка подвержена уязвимости, если перемен­ная u будет содержать значение, на которое может повлиять пользователь, то есть если мы получаем его от пользователя:

string sql = "select * from user where username = " + u;

Начиная с C# 6, в языке появилась поддержка интерполяции строк, — это когда переменные можно вставлять прямо в текст строки:

string sql = $"select * from user where username= {u}";

Казалось бы, нет знаков сложения, нет никакого объединения, и, по идее, у нас не должно быть уязвимости, но, к сожалению, это не так: интерполяция строк не за­щищает от инъекции SQL, поэтому используйте параметры, только параметры.

ГЛАВА 7

CSRF, или XSRF-уязвимость

CSRF (cross-site request forgery или межсайтовая подделка запроса), также известна как XSRF — достаточно серьезная уязвимость, которая стала популярной в 2010-х годах, хотя первые упоминания датируются где-то началом двухтысячных.

Идея атаки заключается в том, что пользователь выполняет какое-то действие на сайте X, но реально они направляются на сайт Y, и если пользователь реально заре­гистрирован на этом сайте, то результат может быть достаточно плачевным.

---

1. 
   Примеры межсайтовой атаки
   

Рассмотрим самый простой и для начала безобидный пример CSRF-атаки. На моем сайте есть страница поиска https://www.flenov.info/search/index, и чтобы эта стра­ница отобразила результат поиска какого-то текста, достаточно методом get пере­дать ей параметр search и после знака равно установить значение, например: https://www.flenov.info/search/index?search=test

Этот URL заставит мой сайт найти все заметки на сайте, где упоминается слово test.

Если вы разместите эту ссылку на своем сайте и его посетители кликнут по этой ссылке, то вы заставите их выполнить действие поиска на моем сайте.

Как я уже сказал, это безобидное действие, но оно все же произошло.

Допустим, что у меня есть учетная запись на сайте банка и на сайте есть страница, где я могу управлять своей учетной записью, в том числе поменять пароль. Чтобы сделать это, нужно загрузить форму смены пароля, ввести новый пароль и сохра­нить его. А что, если я размещу форму для смены пароля на своем сайте, и она бу­дет отправлять введенные пользователем данные на сайт банка по URL, который меняет пароль? Если я назову переменные так же, как они называются у банка, и если на атакуемом сервере нет защиты от межсайтовых скриптов, атака может за­вершиться успешно.

Вот пример формы, которая отображает два поля для имени и пароля, и если пользо­ватель кликнет на кнопку, то данные полетят на страницу /account/changepassword банка:

User name:

Password:

Обратите внимание, что тут у формы action указывает на URL банка, а в самой форме три параметра:

• 
  имя username для ввода пользователя, куда должны ввести имя;
  
• 
  поле ввода fakepassword, куда пользователь будет указывать новый пароль, но имя поля специально так названо, потому что нам все равно, что туда введут, мы это хотим игнорировать;
  
• 
  скрытое поле password, которое содержит значение xyz, и именно имя этого поля должно совпадать с тем именем, которое ожидает банк. Так что мы поменяем пароль на xyz.
  

---

Итак, располагаем эту форму у себя на сайте и начинаем нагонять жертв на страни­цу. Если атакуемый пользователь авторизован в данный момент на сайте и на сер­вере нет защиты, то при отправке этой формы пароль смениться на xyz. Единствен­ная проблема — какое будет имя пользователя? Мы знаем пароль, потому что он прописан прямо в коде, а вот имя пользователя мы можем не знать. Эта проблема решаема. С помощью JavaScript можно без проблем по нажатию кнопки направить на свой сервер дополнительный запрос, который сообщит хакеру, какое имя поль­зователя мы поймали.

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

Слишком много если: пользователь должен быть зарегистрирован, он должен быть авторизован, сайт должен не иметь защиты. Однако в начале 2000-х годов это была не проблема. Сессии даже у банков были бесконечными, главное, чтобы человек был зарегистрирован. В США не так много крупных банков. В Канаде еще недавно банки можно было пересчитать на пальцах одной руки (их было четыре), так что вероятность, что пользователь пользуется одним из них очень высока. Захватив управление финансовым аккаунтом, можно украсть его деньги.

Даже если пароль недоступен, хакеры могут использовать подобную атаку, чтобы вызвать перевод денег на свой счет, поэтому даже если пароль не получится ук­расть, возможно удастся украсть деньги.

А представьте, если подобная уязвимость будет найдена у Facebook, "ВКонтакте", "Одноклассниках", Google, Microsoft и т. д. Тут вероятность того, что кто-то заре­гистрирован, очень высокая.

Подобную атаку можно использовать и для осуществления распределенной DDoS- атаки на определенный сайт.

2. 
   Плохая защита от межсайтовой уязвимости
   

Первое, что приходит в голову, — добавить в форму необходимость ввести теку­щий пароль, и если он введен неверно, то отказывать смене. Самая бесполезная за­щита, потому что хакер может добавить такое же поле у себя на сайте и заставить пользователя вводить не только имя и новый пароль, но и существующий.

Можно добавить каптчу. Этот метод уже сработает, потому что хакер на свой сайт каптчу добавить не сможет. Хотя нет, он сможет, но это будет его каптча, и она не будет совпадать с оригинальным сайтом, если только... Если только каптча не яв­ляется простой картинкой. Если это изображение, то хакер может с помощью JavaScript направить GET-запрос на сайт банка, найти URL с изображением каптчи и забрать его себе.

---

Правда, обход каптчи зависит от того, как она реализована на сервере, далеко не каждую реализацию можно обойти. Самое простое, если каптча не привязана к оп­ределенной сессии пользователя. Мне доводилось видеть подобные реализации, когда пользователь загружал страницу, на сервере создавался код безопасности, который действовал примерно 5 минут, но этот код мог отправить кто угодно, не обязательно, чтобы это был тот же пользователь, кто изначально загрузил сайт.

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

В этом отношении Google-каптча более безопасна, ее так не обмануть. Тут нужно не просто загрузить страницу, чтобы на сервере сгенерировался код, но и выпол­нить определенные действия на странице: кликнуть "Я не робот" и выбрать картин­ки из списка по определенному шаблону.

От загрузки страницы со стороны чужого сайта позволяет защититься и политика CORS — это когда мы контролируем, кто может обращаться к ресурсам сервера. Об этом поговорим в разд. 7.4.

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

2. 
   Хорошая защита
   

Самая простая защита, которая может сработать, — проверка Referer. Когда поль­зователь загружает страницу, то браузер отправляет серверу в качестве одного из параметров еще и URL-страницы, с которой пользователь перешел на сайт или от­правил данные.

Если форма расположена на сайте хакера www.hacksite.ru и с него отправляется на сайт банка www.

---