Зачем мне выполнять проверку на стороне сервера?

Question

Спасибо всем, кто прокомментировал или опубликовал ответ! Я сохранил свой оригинальный вопрос и обновление ниже для полноты.

[16 февраля 2011 - Обновление 2] Как отмечают некоторые люди, мой вопрос должен был звучать так: Учитывая стандартную форму asp.net 4, если у меня нет проверки на стороне сервера, какие типы я подвержен злонамеренным атакам?

Вот мой отзыв по этому вопросу.

• Если данные не являются конфиденциальными (комментарии на странице) - с точки зрения безопасности asp.net, следуя стандартным рекомендациям (SqlParameters, проверка запросов включена и т. Д.), Вы защитите себя от злонамеренных атак.
• Для конфиденциальных данных / приложений - вам решать, какой тип проверки на стороне сервера подходит для вашего приложения. Вам необходимо продумать комплексное решение (веб-сервисы, другие системы и т. Д.). Вы можете просмотреть ряд предложений ниже - проверка белого списка и т. Д.
• Если вы используете ajax (запросы xhr) для публикации пользовательского ввода, вам необходимо воспроизвести защиту от других маркеров в вашем коде на сервере. Опять же, множество решений ниже - например, обеспечение того, чтобы данные не содержали html / code и т. Д. (примечание: .net framework requestValidationMode = "4.0" предоставляет некоторую защиту в этом отношении - но я могу ' говорить о том, насколько полно это решение)

Пожалуйста, продолжайте комментировать ... если что-то из перечисленного неверно, пожалуйста, дайте мне знать. Спасибо!

---

[3 февраля 2011 - Обновление 1] Я хочу поблагодарить всех за ответы! Возможно, мне следует задать обратный вопрос:

Предположим, что простая веб-форма asp.net 4.0 (formview + источник данных с включенной проверкой запроса) , которая позволяет зарегистрированным пользователям публиковать комментарии на общедоступной странице (комментарии хранятся в таблице базы данных сервера sql). ) . Какой тип проверки или очистки данных я должен выполнить для новых «комментариев» на стороне сервера?

---

[19 января 2011 - Оригинальный вопрос] На нашем веб-сайте asp.net 4 есть несколько форм, где пользователи могут отправлять данные, и мы используем jquery validate на стороне клиента. Пользователи должны войти в систему с действительной учетной записью, чтобы получить доступ к этим формам.

Я понимаю, что наши правила проверки на стороне клиента можно легко обойти, и клиенты могут публиковать данные без обязательных полей и т. Д. Это не очень меня беспокоит - пользователи должны войти в систему, и я не считаю наши данные очень «Чувствительный», и я бы не сказал, что любая из наших проверок является «критической». Входные данные записываются в базу данных с использованием SqlParameters (для защиты от внедрения SQL), и мы зависим от проверки запроса asp.net для защиты от потенциально опасного ввода HTML.

Действительно ли стоит нашего времени переписать различные правила проверки jquery на сервере? В частности, как злоумышленник может скомпрометировать наш сервер или какие конкретные атаки мы можем открыть?

Я прошу прощения, так как кажется, что этот вопрос обсуждался несколько раз на этом сайте - но мне еще предстоит найти ответ, в котором указаны конкретные риски или проблемы, связанные с отсутствием проверки на стороне сервера. Заранее спасибо

Answer 1

Гипотетическая ситуация:

Допустим, у вас есть поле почтового индекса.На стороне клиента вы подтверждаете, что он должен быть в шаблоне «00000» или «00000-0000».Поскольку вы разрешаете дефис, вы решаете сохранить поле как varchar в базе данных.

Итак, какой-то злой пользователь приходит и решает обойти все проверки на стороне клиента и отправляет что-то, что не в правильном формате, и проходит через проверку запроса.

Ладно, ничего страшного ... вы все равно кодируете его, прежде чем потом отобразить его пользователю.

Но что еще вы делаете с этимпочтовый индекс?Вы отправляете это на веб-сервис для поиска?Вы загружаете его на устройство GPS?Будет ли это когда-либо интерпретироваться чем-то другим в будущем?Ваше поле почтового индекса теперь содержит какой-то JSON или что-то еще странное?

Или что-то вроде этого: http://www.businessinsider.com/livingsocial-server-flaw-2011-1

Answer 2

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

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

Вы можете выполнить свой собственный анализ угроз, задав себе вопрос что произойдет, если пользователь обходит проверку? .

Две группы ответов, например:

Группа 1 (критическая)

1. Пользователь может покупать статьи, платя меньше их цены
2. Пользователю может быть предоставлена ​​информация о других пользователях
3. Пользователь получает привилегии, которые он / она не имеетдолжен иметь

Группа 2 (некритично)

1. Пользователь отображает несогласованные данные на следующей странице
2. Обработка продолжается, но приводит к несогласованностик ошибке, требующей вмешательства человека
3. Данные пользователя (но только , которые пользователь, а не другие) скомпрометированы
4. Возвращается странная страница с ошибкойd пользователю, с большим количеством технической информации, которую нельзя использовать в любом случае

В первом случае вы обязательно должны решить вашу проблему проверки, потому чтоВы можете потерять деньги после атаки или потерять доверие публики (подумайте о подделке URL-адресов Facebook и показе фотографий кого-либо, даже если вы не являетесь друзьями).

Во втором случае, если вы уверены, чтонесоответствующее поле не подвергает риску вашу компанию или данные, вы все равно можете избежать исправления

Реальная проблема заключается в

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

Так вот почему вы теряете меньше времени на исправление проверки, а не на обдумывание

Answer 3

Честно говоря, пользователям все равно, что вы считаете "чувствительными" или "критическими" данными. Эти критерии должны решать.

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

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

Так что ... хотя вы, возможно, и не считаете атаку ввода вводной информации важной, ваши пользователи будут признавать, что - вот почему вы все равно должны выполнять проверку ввода на стороне сервера.

Answer 4

Ваши данные могут не стоить много, я в порядке.

НО, злоумышленники могут внедрить CSRF код атаки "межсайтовый запрос подделки" в ваше приложение; пользователи вашего сайта могут получить данные на других сайтах. Да, это потребовало бы ошибок на «других сайтах», но это происходит. Да, это потребовало бы, чтобы пользователи не использовали кнопки «выход» на этих сайтах, но недостаточно людей использовали их. Подумайте обо всех вкусных данных, которые ваши пользователи хранят на других веб-сайтах. С вашими пользователями не случится ничего плохого.

Злоумышленники могут внедрить HTML, который предлагает пользователям загрузить и установить «плагины, необходимые для просмотра этого контента» - плагины, которые являются кейлоггерами, или искать на жестких дисках номера кредитных карт или налоговые декларации. Может плагин стать спамботами или порно хостов. Ваши пользователи доверяют вашему сайту не рекомендовать плагины, принадлежащие Yakuza, верно? Они могут не чувствовать себя дружелюбно, если ваш сайт рекомендует устанавливать злые вещи.

В зависимости от того, какие виды ошибок недействительные данные могут вызвать, вы могли бы найти себе Spambot или порно хозяина. Это во многом зависит от того, насколько вы защитили кодирование других аспектов вашего приложения. Слишком много приложений слепо доверяют входным данным.

И самое приятное: ваши пользователи не люди. Ваши пользователи - браузеры , которые могут выполнять атаки других сайтов, которые не удосужились выполнить хорошую проверку входных данных и очистку выходных данных. Ваши пользователи - это вирусы или черви, которые случайно или случайно обнаруживают вас. Вы можете доверять людям, но насколько вы доверяете их компьютерам? Я не очень далеко.

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

Answer 5

Это отличный и смелый вопрос. Короткий (и, возможно, смелый) ответ: нет. Если вы знаете обо всех уязвимостях в системе безопасности и по-прежнему не считаете это необходимым, тогда это ваш выбор.

Это действительно зависит от того, кто ваши пользователи, кому сайт открыт (с точки зрения интранета или Интернета) и насколько легко получить учетную запись. Вы говорите, что ваши данные не являются конфиденциальными, но вы по-прежнему требуете, чтобы пользователи входили в систему. Как плохо было бы, если бы неавторизованный пользователь мог получить доступ к системе, прыгнув на компьютер другого пользователя, пока они были в другом месте?

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

Однако это должен быть ваш выбор, и вы поступаете правильно, чтобы выяснить последствия отказа от этого.

Answer 6

Я считаю, что вам нужно проверить как на стороне клиента, так и на стороне сервера, и вот почему.

На стороне клиента , вы часто спасаете пользователя от отправкиданные, которые явно неверны.Они не заполнили обязательное поле.Они поместили буквы в поле, которое должно содержать только цифры.Они указали дату в будущем, когда будет использоваться только дата в прошлом (например, дата рождения).И так далее.Предотвращая подобные ошибки на стороне клиента, вы избегаете разочарования пользователей, а также сокращаете количество ненужных обращений к вашему веб-серверу.

На стороне сервера обычно следуетповторите все проверки, которые вы сделали на стороне клиента.Это потому, что, как вы заметили, умные пользователи могут обойти проверку на стороне клиента и представить неверные данные.Кроме того, существует некоторая проверка, которая неэффективна или невозможна на стороне клиента.Иногда вы проверяете, что ввод данных соответствует бизнес-правилам.Вы можете проверить это по существующим данным в базе данных.Если вы просто позволите пользователям вводить что-либо (особенно пропуская обязательные поля), веб-сайт не будет работать для них должным образом.

Answer 7

Проверьте расширение Tamper Data для firefox. Вы можете очень легко кормить сервер чем угодно

Answer 8

Чтобы ответить на ваш второй вопрос:

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

Проверка запросов .NET Framework отлично справляется с остановкойПолезные нагрузки XSS во входящих запросах POST.Однако он не может препятствовать проникновению в комментарии других вредоносных или вводящих в заблуждение HTML-кодов (тегов изображений, гиперссылок и т. Д.).

Поэтому, если возможно, я бы настроил проверку белого списка на стороне сервера для разрешенных символов.Регулярное выражение должно покрывать это очень хорошо.Вы должны разрешить A-Za-z0-9, пробел и несколько знаков препинания.Если регулярное выражение не соответствует, верните сообщение об ошибке пользователю и остановите транзакцию.Относительно SQL-инъекций: в этом случае я бы разрешил апострофы (если только вы не любите ужасную грамматику в комментариях), но поместите комментарии кода вокруг ваших параметризованных SQL-запросов с эффектом: «Это единственная защита от SQL, поэтому будьте осторожны, когдаизменения «.Также следует заблокировать разрешения учетной записи базы данных, используемой веб-процессом (только чтение / запись, но не права владельца базы данных).Чего я не хотел бы делать, так это пытаться выполнить проверку черного списка на входе, так как это требует много времени для правильной работы (см. Шпаргал XSS RSnake по адресу http://ha.ckers.org/xss.html, чтобы получить представление о количестве вещей, которые вам понадобятсяпредотвратить только для XSS).

Между платформой .NET и вашей собственной проверкой белого списка вы должны быть защищены от атак на основе HTML, таких как XSS и CSRF *.Внедрение SQL будет предотвращено с помощью параметризованных запросов.Если данные комментария касаются каких-либо других ресурсов, вам может потребоваться установить дополнительные элементы управления, но они охватывают атаки, относящиеся к описанной вами форме представления основных данных.

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

И, как всегда, OWASP.org (http://www.owasp.org)является хорошим справочником по всем вопросам, связанным с webappsec. Ознакомьтесь с их проектами «Десятка» и «Руководство по развитию».

* CSRF может не касаться вас напрямую, поскольку мошеннические публикации на вашем сайте могут не иметь для вас значения, нопредотвращение XSS имеет побочное преимущество - сохранение полезных нагрузок CSRF, нацеленных на другие сайты, с вашего сайта.

Answer 9

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

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

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

Answer 10

Любой, кто выполняет HTTP POST на ваш сервер через ваш веб-сайт (с проверкой jQuery), может также выполнять HTTP POST с помощью некоторых других средств, которые обходят проверку jQuery.Например, я мог бы использовать System.Net.HttpWebRequest для размещения некоторых данных на вашем сервере с соответствующими файлами cookie, которые внедряют вредоносный контент в поля формы.Мне нужно было бы правильно настроить поля __EVENT_VALIDATION и __VIEWSTATE, но если мне это удастся, я бы обошел проверку.

Если у вас нет проверки данных на стороне сервера, то вы эффективно не проверяет входные данные вообще.Проверка jQuery удобна для работы с пользователем, но не является реальной линией защиты.

Это особенно верно для таких входов, как поле комментариев в свободной форме.Вы определенно хотите убедиться, что поле не содержит HTML или другой вредоносный скрипт.В качестве дополнительной меры защиты вы также должны избегать содержимого комментариев, когда оно отображается в вашем веб-приложении с помощью библиотеки, подобной AntiXss (см. http://wpl.codeplex.com/).