Пользовательская проверка Asp.net-MVC - NULL против пустых

Question

Пользовательская проверка Asp.net-MVC - NULL против пустых

1

Для безопасности и согласованности я бы хотел проверить на пост-обратно, если поле отсутствует? В Java (например, сервлеты), когда мы выполняем request.getParameter(key) результатом является либо значение String, либо иначе NULL, если поле отсутствует. В MVC я создал пользовательскую проверку, которую я называю "ThrowOnNull". Поведение, которое я пытаюсь захватить, - это: Если нужного поля отсутствует (null), я хочу бросить, иначе вернем успех.

Рассмотрим этот пользовательский валидатор (который не работает):

public class ThrowOnNull: ValidationAttribute
{
   public ThrowOnNull() { }

   protected override ValidationResult IsValid(object value, ValidationContext validationContext)
   {            
       if (value == null)
           throw new Exception(validationContext.MemberName + " field expected, but missing."));            

       return ValidationResult.Success;
   }
}

Можно ли делать то, что я хочу здесь? (этот валидатор работает не так, как ожидалось, и потому, что структура присваивает NULL пустое значение [oh dear].)

ОБНОВЛЕНИЕ: В примере @emodendroket следующий пример кода теперь работает так, как ожидалось:

public class ThrowOnMissing: ValidationAttribute
{
    public ThrowOnMissing() { }

    protected override ValidationResult IsValid(object value, ValidationContext validationContext)
    {
        if (!HttpContext.Current.Request.Form.AllKeys.Contains(validationContext.MemberName))
            throw new Exception(validationContext.MemberName + " field expected, but missing.");

        return ValidationResult.Success;
    }
}

EDIT: Я тщательно очистил код вопроса и примера, чтобы сделать его намного понятнее, надеюсь, что это поможет.

Casey 04 сен. 2014, в 02:07

Источник

0

Я не понимаю, как ответ, который вы приняли, решает проблему, о которой вы так непреклонны ....
Erik Funkenbusch 04 сен. 2014, в 22:13
0

Короче говоря: это решает, потому что объясняет, как это возможно для того, что я хочу. Что такое: Проверьте необработанную входящую передачу на согласованность через пользовательский валидатор. Далее: обеспечение того, что мое приложение ожидает от входящих данных (полей). Если нет, киньте, войдите и перенаправьте. Этот метод рассматривает структуру (и любую зависимость от нее), просматривая необработанный поток, что позволяет мне проводить упреждающую (предварительную) проверку и сертификацию. Я приветствую подход MVC, если предложен или объяснен разумный (чего не было). В противном случае, я посмотрю на фреймворк и проверим его сам.
user1068477 04 сен. 2014, в 22:28

Теги:

c#

validation

asp.net-mvc

4 ответа

3

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

Вероятно, вам следует переопределить, что означает "недостающее значение".

РЕДАКТИРОВАТЬ:
После некоторого обсуждения кажется, что вас действительно не интересуют нулевые значения, а о безопасности (ложные формы с отсутствующими полями и тому подобное). В этом случае вы должны просто использовать стандартную марку antiforgery и, возможно, проверить происхождение запроса. Вы должны быть более чем прекрасным таким образом. Проверка недостающих полей не поможет, потому что злоумышленник может легко отправить эти поля.

Перегрузка/Под проводкой является реальной проблемой. Кроме того, если поля не отправлены (из-за какой-либо взлома или атаки DOS)

На самом деле, нет.

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

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

DDOS-атака не может быть предотвращена, поверьте, некоторые проверки отсутствующих полей не помогут, если у кого-то есть сеть, достаточно мощная, чтобы вызвать DDOS. Просто просмотрите последние случаи при атаках, и вы поймете, что если ОГРОМНЫЕ серверы не могут этого выдержать, вы, конечно же, не сможете это предотвратить.

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

walther 03 сен. 2014, в 21:26

0

Все поля, принадлежащие этой форме, не существуют, если кто-то (хакер) отправляет только подмножество полей. Смысл проверки состоит в том, чтобы фактически подтвердить, что ВСЕ ожидаемые поля действительно были возвращены. Это проверка безопасности, согласованности. Это предназначено, чтобы помешать / войти и сообщить о неожиданном поведении.
user1068477 03 сен. 2014, в 23:31
0

@JasonCaldwell, Обязательный атрибут будет достаточно в этом случае ..
walther 03 сен. 2014, в 23:32
0

@JasonCaldwell Честно говоря, это не очень серьезная мера безопасности, поэтому я бы не стал так думать ... хакер мог бы легко посмотреть и посмотреть, какие поля отправляет ваша форма, и это не займет больше 5 минут.
Casey 03 сен. 2014, в 23:32
0

Я не согласен. Over / Under posting - реальная проблема. Кроме того, если поля не отправлены (из-за взлома или какой-либо атаки DOS), выполнение такого рода проверки (и выбрасывания) предотвращает дальнейшую и, возможно, дорогостоящую проверку (для оставшихся полей).
user1068477 03 сен. 2014, в 23:35
0

Walther - Обязательный атрибут недостаточен, поэтому я создал собственный атрибут. Обязательный атрибут возвращает «Обязательное поле», даже если поле полностью отсутствует. Это потому, что он считает NULL пустым.
user1068477 03 сен. 2014, в 23:41
0

@JasonCaldwell То, что я имею в виду, это абсолютно тривиально, чтобы обойти, поэтому вам нужно что-то более сильное, чтобы поддержать это.
Casey 03 сен. 2014, в 23:41
1

Согласованный - required атрибут и четко определенная модель связанного представления - вот путь, по которому можно перейти - если поля не отправлены или установлено слишком много полей, привязка будет выброшена, предотвращая «дальнейшую и, возможно, дорогостоящую проверку», и если поле отправлено, но пусто, обязательный атрибут его перехватит (но не помешает дальнейшей проверке, поскольку вы, вероятно, хотите сообщить пользователю обо всех проблемах, а не по одной за раз ...)
Zhaph - Ben Duguid 04 сен. 2014, в 00:07
0

Zhaph: «если поля не отправлены или установлено слишком много полей, привязка сгенерирует ...» - на самом деле этого не происходит. Если я отмечу Обязательное и опускаю (закомментирую) мое поле в представлении и отправляю сообщение обратно, привязка не сбрасывается, а просто показывает ее как ошибку проверки «Поле обязательно для заполнения». Я проверил это, прежде чем я отправил вопрос - подмигивание.
user1068477 04 сен. 2014, в 00:21
0

emodendroket: «Что я имею в виду, это просто тривиально обойти ...» Вы имеете в виду, что из-за слоя модели, который обеспечивает свойства независимо от того, делает постбэк или нет?
user1068477 04 сен. 2014, в 00:26
1

but instead simply shows it as a validation error "Field is Required" и что еще вы ожидаете от проверки? Если у вас есть проблемы с некоторыми хакерами, это предотвратит, возможно, 15-ти летних хакеров, и даже у меня есть некоторые сомнения. Если вас беспокоит XSS, создание вредоносных форм или что-то в этом роде, вам следует использовать методы, разработанные для такого рода вещей (использование токенов, проверка происхождения запроса, если он такой же и т. Д.). Такого рода вещи. Проверка на ноль не поможет немного.
walther 04 сен. 2014, в 00:35
0

Вальтер: «Что еще вы ожидаете от проверки»? Существуют разные формы проверки. Есть проверка ввода пользователя, а также согласованность и проверка ошибок системы / данных. У каждого есть свое место. Последовательность гарантирует, что то, что встречается по проводам, - это то, что я ожидаю, и если это не так, кто-то либо напортачил с моим сайтом, либо у меня возникла ошибка. Ошибки такого рода не предназначены для конечных пользователей и лучше всего устраняются в тот момент, когда это происходит, чтобы избежать других возможных эксплойтов или проблем. Хотя я согласен, что угроза такого рода низка, она все же возникает.
user1068477 04 сен. 2014, в 00:43
1

@JasonCaldwell, а почему именно вы отказываетесь использовать токен подделки и проверку происхождения POST-запроса? Я немного не вижу, что бы сделать, если бы вы могли найти пропущенные поля. Если вы используете стандартные подходы безопасности, вы более чем хорошо.
walther 04 сен. 2014, в 01:04
0

токен antiforgery - это просто случайная строка, которую можно скопировать и повторно вернуть на сайт. Он не проверяет данные или согласованность членов вообще. Это полумера и хорошо для того, чтобы помешать любителям.
user1068477 04 сен. 2014, в 01:33
0

@JasonCaldwell Если бы я собирался отправить автоматизированный POST, первое, что я сделал бы, это проанализировал, что на самом деле отправляется, когда я обычно использую веб-страницу. Не так ли?
Casey 04 сен. 2014, в 02:24
0

@JasonCaldwell Я думаю, что этот метод слабее, чем токен подделки. По крайней мере, с помощью маркера защиты от подделки я должен имитировать поведение, подобное браузеру.
Casey 04 сен. 2014, в 02:25
0

«По крайней мере, с помощью маркера защиты от подделки я должен имитировать поведение, похожее на браузер» - это очень легко сделать с помощью CURL.
user1068477 04 сен. 2014, в 04:55
1

@JasonCaldwell, забавно, что вы думаете, что использовать маркер защиты от подделки очень просто, но вы считаете, что поиск пропущенных полей - лучшее решение. Эрик Фанкенбуш сказал почти то же самое, но более подробно остановился на этой теме. Asp.net имеет много встроенных функций безопасности, и ваш страх, кажется, исходит от мира Java. .NET также очень гибок, вероятно, больше, чем вы сейчас видите. Если вы не согласны с нами и по-прежнему хотите изобретать велосипед, не проблема.
walther 04 сен. 2014, в 09:42
0

Похоже, вы сравниваете токен антифа с проверкой согласованности полей, как будто один лучше другого - я не понимаю этих рассуждений. Это не соревнование. Мы используем все доступные или все соответствующие меры. Токен Antif + проверка поля, состоящего из элементов + проверка данных + проверка входных данных клиента и т. Д. Я нахожу эту дискуссию с вами, ребята, очень странной, и для меня теперь неудивительно, почему сайты MS взламываются так явно, если вы, ребята, придерживаетесь такого подхода и подхода. Зависимость или доверие от «безопасности» происходит за кулисами ASP.NET, вы все должны знать лучше.
user1068477 04 сен. 2014, в 10:36
0

А что касается токена Antif - попробуйте сами. Скопируйте токен, создайте форму полумера и отправьте ее обратно. Но я должен сказать (как продолжение того, что я только что сказал) - если это ваша линия защиты, то LOL на вас!
user1068477 04 сен. 2014, в 10:38
0

stackoverflow.com/questions/1655144/...
user1068477 04 сен. 2014, в 10:47
1

@JasonCaldwell, ты смеешься надо мной (какая зрелая вещь из тебя, но хорошо), но твоё решение - проверить пропущенное поле, чтобы предотвратить взлом. Ух ты, я должен признать, что я действительно ошеломлен твоими рассуждениями. Я обновил ответ час назад, возьми его или оставь. Это действительно не место для длительных дебатов, и я думаю, что мы с Эриком уже достаточно сказали по этому вопросу.
walther 04 сен. 2014, в 10:50
0

Вальтер: вы не видите большую картину. это не просто проверка пропущенного поля, это проверка пропущенных полей (под сообщениями), границы массива полей (над сообщениями). Этот метод используется ПРОСТО, чтобы обнаружить любое несоответствие. Вот и все. Подумайте об этом, скажем, у вас есть массив полей, и ваш сайт настроен для обработки счетчика 5, но затем скажите, что хакер генерирует 1000 полей при попытке DOS или попытке взломать / использовать. ТЫ не хочешь знать об этом? Разве вы не хотите бросить и войти на такое событие? Честно говоря, вы, ребята, должны получить контроль.
user1068477 04 сен. 2014, в 10:58
1

@JasonCaldwell Да, но, по крайней мере, написание сценария требует просмотра страницы каждый раз. С другой стороны, согласованность полей - это всего лишь задание на копирование и вставку из Fiddler или чего-то еще, и как только я получу правильную форму, я могу просто POST столько раз, сколько захочу. Я не против безопасности, но это все равно что охранять твой дом, наклеивая липкую ленту на дверь.
Casey 04 сен. 2014, в 13:36
0

эмодендрокет: вы недоразумение. Прочтите мои комментарии к Вальтеру, чтобы выяснить, какие у вас могут быть неправильные представления.
user1068477 04 сен. 2014, в 19:24
0

Вальтер: Я только что видел твои правки. мои комментарии здесь остаются в силе, и, кажется, есть какое-то недопонимание намерения и цели моей техники. Я бы также добавил, что это не является мерой по предотвращению DOS-атак (надеюсь, вы не считаете меня таким наивным), но он ограничивает воздействие на систему в случае чрезмерной отправки. Дорогая проверка означает просто проверку, которая может произойти, скажем, с сервером SQL или другим внешним вводом-выводом. Underpost не просто не заполняет поля формы, а overpost также включает границы массива.
user1068477 04 сен. 2014, в 20:09
0

Это метод проверки необычной или неожиданной активности или поведения вашего приложения или против него. Это один из многих используемых методов. Это не столько мера безопасности (хотя и есть), сколько способ помешать, бросить, записать и перенаправить на определенную серию атак ИЛИ несоответствий. Это не вместо использования других методов, но вместо этого используется в сочетании с другими методами для защиты вашего онлайн-приложения. Я надеюсь (наконец-то), что это прояснит вашу путаницу в этом вопросе.
user1068477 04 сен. 2014, в 20:26
1

@JasonCaldwell Я только что заметил ваш комментарий здесь, но я не думаю, что имеет смысл проверять вашу модель представления по внешнему хранилищу данных - это первое место. Если это то, что вам нужно, то более обычный подход - проверить ModelState.IsValid в вашем контроллере, прежде чем вы начнете просматривать базу данных (в коде, который существует отдельно от обычного средства проверки формы MVC). В этом контексте «валидация» действительно относится только к валидации на уровне формы. Если атрибут броска работает для вас, нет проблем, но я думаю, что вы и Уолтер говорите о разных вещах.
Casey 05 сен. 2014, в 15:00
0

«Я думаю, что вы и Вальтер говорите о разных вещах», - согласен. ModelState.IsValid + SQL / external IO - ценим это, полезно. Исходя из Java, ASP.NET MVC - это настоящий уход. Тем не менее, очень быстро подбираю его, стараясь соответствовать правильному способу кодирования в нем.
user1068477 05 сен. 2014, в 19:33

Показать ещё 26 комментариев

1

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

Во-первых, давайте проанализируем "угрозы" и определим риски. Вы представили несколько аргументов:

Чрезмерная проводка
Под-проводок
Проверка пустой vs null

Первый элемент не является проблемой в MVC, если вы используете View Model. Вы просто не можете публиковать информацию, которую вид не ожидает (ну, можно, но он игнорируется). Если вы не используете модель представления (или не используете правильно определенный), вы можете использовать атрибуты привязки, чтобы предотвратить публикацию элементов, которые вы не хотите связывать.

Второе, недопоставление, если это действительно является проблемой для вашей модели (99.999% времени, просто рассматривая ее по мере необходимости, более чем нормально, но нормально давайте рассмотрим ваш аргумент. Проблема здесь не в атрибуте проверки, это модель вам просто нужно зарегистрировать настраиваемое связующее устройство, которое ищет отсутствующие значения в вашей модели представления и выбрасывает, если они равны нулю. Это легко осуществить, отразив над связанной моделью и сравнив ее с опубликованными значениями, а затем выбросьте.

Проблема с вашим подходом RequiredThrowIfNull заключается в том, что, если это не требуется, и оно опубликовано? Это все еще ошибка в соответствии с вашими аргументами.

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

Причина, по которой ваш атрибут не работает, заключается в том, что атрибуты проверки уже включены в блок try/catch уже с помощью фреймворка, и если он обнуляет его, тот самый механизм, который обрабатывает его как пустым (этот механизм также делает такие вещи, как ловли ошибки синтаксического анализа, когда тип неверен, например, символы в поле даты и времени.)

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

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

Честно говоря, это переработанное решение, которое ищет проблему, и есть много хороших.net конкретных способов решения проблем, которые вы пытаетесь решить.

Erik Funkenbusch 03 сен. 2014, в 22:36

0

Я в значительной степени не согласен. Здесь недостаточно места, чтобы взять вас по пунктам, но, как я сказал Вальтеру: «Существуют разные формы проверки. Есть проверка ввода пользователя и есть согласованность и проверка ошибок системы / данных. У каждого есть свое место. Согласованность гарантирует то, что приходит». то, что я ожидаю, - это то, чего я не ожидаю, и если это не так, то кто-то либо напортачил с моим сайтом, либо у меня где-то возникла ошибка. Такие ошибки не для конечных пользователей, и лучше всего их устранять в тот момент, когда их избегают. другие возможные подвиги или проблемы. Хотя я согласен с тем, что угроза такого рода невелика, она все же возникает "
user1068477 04 сен. 2014, в 01:21
0

Кроме того, я понимаю различие между Java и ASP-MVC и не пытаюсь переворачивать одно поверх другого. Однако я ожидаю, что смогу сказать, соответствует ли то, что я ожидаю, тому, что я излучаю. И, конечно, не из-за параноика, но, сказав это, - это проект Microsoft.
user1068477 04 сен. 2014, в 01:23
0

Я просто беспокоюсь о безопасности, работая с сотнями плохо написанных веб-сайтов и исправив сотни взломов. Обеспечение согласованности проходит долгий путь к безопасному сайту и сокращает накладные расходы системы, если в противном случае возникает эксплойт.
user1068477 04 сен. 2014, в 01:25
1

@JasonCaldwell - я предлагаю вам перечитать то, что я написал, поскольку вы, кажется, спорите против того, что вы воспринимаете, я сказал, а не то, что я сделал. Я хочу сказать, что вещи, которые вы рассматриваете как недостаток безопасности в Java, как правило, отсутствуют в ASP.NET, потому что они предназначены для смягчения этих ситуаций и имеют механизмы для их решения, но вы хотите обойти все это и сделать что-то Java. как то, что неправильно делать. В частности, прочитайте мое последнее предложение ясно.
Erik Funkenbusch 04 сен. 2014, в 02:53
0

Я спорю с вашей общей точкой (или точками). Более того, я никогда не утверждал, что в Java это недостаток, если бы вы спросили, я бы сказал, что наоборот, гибкость, которую Java предоставляет в этой области и некоторых других, весьма превосходна. В Java многое НЕ сделано для вас, а это означает, что вы знаете, что он делает, потому что вы его кодировали. Хотя вы утверждаете, что ASP.NET предназначен для смягчения «таких» ситуаций, вы не предлагаете объяснения, как это сделать. Я призываю вас перечитать мой оригинальный пост, а также ссылку, содержащуюся внутри. Тестирование NULL для NULL не является эксклюзивным для Java, так что не обращайте внимания на Java.
user1068477 04 сен. 2014, в 05:06
0

Ответ сделан на сайте ASP.NET, который кратко заявляет, что «по умолчанию MVC преобразует пустую строку в нулевую строку»: forums.asp.net/t/2006146.aspx?Custom+Validation+and+NULL
user1068477 04 сен. 2014, в 05:11
0

Это все, что мне нужно было прочитать после моего вопроса: «Можно ли здесь делать то, что я хочу?»
user1068477 04 сен. 2014, в 05:12

Показать ещё 5 комментариев

0

@ignatandrei из ASP.NET ответил на вопрос:

по умолчанию MVC преобразует пустую строку в пустую строку.

http://forums.asp.net/t/2006146.aspx?Custom+Validation+and+NULL

user1068477 04 сен. 2014, в 03:56

0

Я не думаю, что это влияет на Request.Form ... была причина, по которой вам не понравилось это решение? Например, вы можете посмотреть на AllKeys и увидеть, что ключа там нет.
Casey 04 сен. 2014, в 13:38
0

Пожалуйста, объясните, что вы имеете в виду? Я не думаю, что вы понимаете мой первоначальный вопрос или этот ответ.
user1068477 04 сен. 2014, в 19:20
1

if (!HttpContext.Current.Request.Form.AllKeys.Contains("prop")){throw new Exception();}
Casey 04 сен. 2014, в 19:25
0

По сути, вы вообще обходите MVC и привязку моделей и просто смотрите на форму.
Casey 04 сен. 2014, в 19:26
0

Ну, я не думаю, что обхожу связывание моделей и, конечно, не совсем. Я просто смотрю на значение, которое использует Binder, да?
user1068477 04 сен. 2014, в 19:28
0

Извините, если то, как я это сказал, сбивает с толку; я имею в виду, что ваш ответ здесь говорит о том, что происходит после привязки модели; Я говорю, что вы можете обойти это поведение, посмотрев непосредственно на данные формы. Да, это правда, что данные формы также используются связывателем модели.
Casey 04 сен. 2014, в 19:32
0

Кстати: спасибо за этот пример кода! Это то, что я ищу.
user1068477 04 сен. 2014, в 19:33
0

Да, это именно то, что мне нужно, чтобы напрямую "обойти" данные модели и формы. Я надеялся, что смогу достичь этого без необходимости, но ответ ignatandrei в ASP.NET (выше) подтвердил мой первоначальный вопрос. Ваш ответ здесь, однако, улучшает идею Request.Form, позволяя этой проверке действительно происходить либо в модели, либо в пользовательском валидаторе.
user1068477 04 сен. 2014, в 19:37
1

Я пытался намекнуть на это раньше, но я отредактировал свой ответ, чтобы быть более ясным. Во всяком случае, надеюсь, что это поможет вам.
Casey 04 сен. 2014, в 19:40
0

Обновил мой пост. Если вы удалите пустую строку из своего ответа выше и оставите здесь ответ, который вы прокомментировали, я отмечу ваш ответ.
user1068477 04 сен. 2014, в 19:45
0

Лучшее решение - передать FormsCollection вашему методу действия, который делает то же самое, за исключением того, что он передается в качестве параметра. то есть: public ActionResult Index(FormsCollection collection) {}
Erik Funkenbusch 04 сен. 2014, в 22:17
0

В качестве альтернативы, вы можете использовать [Required(AllowEmptyStrings=true)] , и если любое из полей вашей модели на самом деле имеет значение null, то вы знаете, что они отсутствуют, а не просто пусты. Я действительно не понимаю, как это отвечает на вопрос, учитывая все ваши другие требования ...
Erik Funkenbusch 04 сен. 2014, в 22:21
0

Привет, Эрик. Суть этого метода заключается в упреждающем обнаружении несоответствий во входящей передаче, чтобы обеспечить соответствие поступающих данных (полей) тому, что ожидает мое приложение. С самого начала, регистрируйте и перенаправляйте, избегая дальнейших проверок от возникновения в случае обнаружения проблемы.
user1068477 04 сен. 2014, в 22:31
0

Я не ясно, на AllowEmptyStrings. Я посмотрел это после того, как Эмодендрокет предложил это. Похоже, это не то, чего я хочу, не могли бы вы подтвердить его назначение или как его использовать?
user1068477 04 сен. 2014, в 22:32
0

@JasonCaldwell - Смысл AllowEmptyStrings в вашем случае заключается в том, что если строка пуста, то значение будет равно «», если пропущенное значение будет равно нулю. Это поведение, которое исходный код предполагал иметь место, и терпело неудачу, потому что значение было пустым для пустых строк.
Erik Funkenbusch 04 сен. 2014, в 22:34
0

Хорошо, это не ясно в описании, которое гласит: «Когда вы устанавливаете AllowEmptyStrings в true для поля данных, Dynamic Data не выполняет проверку и преобразует пустую строку в нулевое значение».
user1068477 04 сен. 2014, в 22:37
0

@JasonCaldwell - это для DynamicData, который также использует эти атрибуты ... MVC этого не делает. Вы также хотели бы установить [DisplayFormat(ConvertEmptyStringToNull = false)] в свойстве, а также, если вы используете любой EditorFor's
Erik Funkenbusch 04 сен. 2014, в 22:41
0

Brilliant. Я посмотрю на них.
user1068477 04 сен. 2014, в 22:52

Показать ещё 16 комментариев

Ещё вопросы

Я не понимаю, как ответ, который вы приняли, решает проблему, о которой вы так непреклонны ....
Короче говоря: это решает, потому что объясняет, как это возможно для того, что я хочу. Что такое: Проверьте необработанную входящую передачу на согласованность через пользовательский валидатор. Далее: обеспечение того, что мое приложение ожидает от входящих данных (полей). Если нет, киньте, войдите и перенаправьте. Этот метод рассматривает структуру (и любую зависимость от нее), просматривая необработанный поток, что позволяет мне проводить упреждающую (предварительную) проверку и сертификацию. Я приветствую подход MVC, если предложен или объяснен разумный (чего не было). В противном случае, я посмотрю на фреймворк и проверим его сам.
Все поля, принадлежащие этой форме, не существуют, если кто-то (хакер) отправляет только подмножество полей. Смысл проверки состоит в том, чтобы фактически подтвердить, что ВСЕ ожидаемые поля действительно были возвращены. Это проверка безопасности, согласованности. Это предназначено, чтобы помешать / войти и сообщить о неожиданном поведении.
@JasonCaldwell, Обязательный атрибут будет достаточно в этом случае ..
@JasonCaldwell Честно говоря, это не очень серьезная мера безопасности, поэтому я бы не стал так думать ... хакер мог бы легко посмотреть и посмотреть, какие поля отправляет ваша форма, и это не займет больше 5 минут.
Я не согласен. Over / Under posting - реальная проблема. Кроме того, если поля не отправлены (из-за взлома или какой-либо атаки DOS), выполнение такого рода проверки (и выбрасывания) предотвращает дальнейшую и, возможно, дорогостоящую проверку (для оставшихся полей).
Walther - Обязательный атрибут недостаточен, поэтому я создал собственный атрибут. Обязательный атрибут возвращает «Обязательное поле», даже если поле полностью отсутствует. Это потому, что он считает NULL пустым.
@JasonCaldwell То, что я имею в виду, это абсолютно тривиально, чтобы обойти, поэтому вам нужно что-то более сильное, чтобы поддержать это.
Согласованный - required атрибут и четко определенная модель связанного представления - вот путь, по которому можно перейти - если поля не отправлены или установлено слишком много полей, привязка будет выброшена, предотвращая «дальнейшую и, возможно, дорогостоящую проверку», и если поле отправлено, но пусто, обязательный атрибут его перехватит (но не помешает дальнейшей проверке, поскольку вы, вероятно, хотите сообщить пользователю обо всех проблемах, а не по одной за раз ...)
Zhaph: «если поля не отправлены или установлено слишком много полей, привязка сгенерирует ...» - на самом деле этого не происходит. Если я отмечу Обязательное и опускаю (закомментирую) мое поле в представлении и отправляю сообщение обратно, привязка не сбрасывается, а просто показывает ее как ошибку проверки «Поле обязательно для заполнения». Я проверил это, прежде чем я отправил вопрос - подмигивание.
emodendroket: «Что я имею в виду, это просто тривиально обойти ...» Вы имеете в виду, что из-за слоя модели, который обеспечивает свойства независимо от того, делает постбэк или нет?
but instead simply shows it as a validation error "Field is Required" и что еще вы ожидаете от проверки? Если у вас есть проблемы с некоторыми хакерами, это предотвратит, возможно, 15-ти летних хакеров, и даже у меня есть некоторые сомнения. Если вас беспокоит XSS, создание вредоносных форм или что-то в этом роде, вам следует использовать методы, разработанные для такого рода вещей (использование токенов, проверка происхождения запроса, если он такой же и т. Д.). Такого рода вещи. Проверка на ноль не поможет немного.
Вальтер: «Что еще вы ожидаете от проверки»? Существуют разные формы проверки. Есть проверка ввода пользователя, а также согласованность и проверка ошибок системы / данных. У каждого есть свое место. Последовательность гарантирует, что то, что встречается по проводам, - это то, что я ожидаю, и если это не так, кто-то либо напортачил с моим сайтом, либо у меня возникла ошибка. Ошибки такого рода не предназначены для конечных пользователей и лучше всего устраняются в тот момент, когда это происходит, чтобы избежать других возможных эксплойтов или проблем. Хотя я согласен, что угроза такого рода низка, она все же возникает.
@JasonCaldwell, а почему именно вы отказываетесь использовать токен подделки и проверку происхождения POST-запроса? Я немного не вижу, что бы сделать, если бы вы могли найти пропущенные поля. Если вы используете стандартные подходы безопасности, вы более чем хорошо.
токен antiforgery - это просто случайная строка, которую можно скопировать и повторно вернуть на сайт. Он не проверяет данные или согласованность членов вообще. Это полумера и хорошо для того, чтобы помешать любителям.
@JasonCaldwell Если бы я собирался отправить автоматизированный POST, первое, что я сделал бы, это проанализировал, что на самом деле отправляется, когда я обычно использую веб-страницу. Не так ли?
@JasonCaldwell Я думаю, что этот метод слабее, чем токен подделки. По крайней мере, с помощью маркера защиты от подделки я должен имитировать поведение, подобное браузеру.
«По крайней мере, с помощью маркера защиты от подделки я должен имитировать поведение, похожее на браузер» - это очень легко сделать с помощью CURL.
@JasonCaldwell, забавно, что вы думаете, что использовать маркер защиты от подделки очень просто, но вы считаете, что поиск пропущенных полей - лучшее решение. Эрик Фанкенбуш сказал почти то же самое, но более подробно остановился на этой теме. Asp.net имеет много встроенных функций безопасности, и ваш страх, кажется, исходит от мира Java. .NET также очень гибок, вероятно, больше, чем вы сейчас видите. Если вы не согласны с нами и по-прежнему хотите изобретать велосипед, не проблема.
Похоже, вы сравниваете токен антифа с проверкой согласованности полей, как будто один лучше другого - я не понимаю этих рассуждений. Это не соревнование. Мы используем все доступные или все соответствующие меры. Токен Antif + проверка поля, состоящего из элементов + проверка данных + проверка входных данных клиента и т. Д. Я нахожу эту дискуссию с вами, ребята, очень странной, и для меня теперь неудивительно, почему сайты MS взламываются так явно, если вы, ребята, придерживаетесь такого подхода и подхода. Зависимость или доверие от «безопасности» происходит за кулисами ASP.NET, вы все должны знать лучше.
А что касается токена Antif - попробуйте сами. Скопируйте токен, создайте форму полумера и отправьте ее обратно. Но я должен сказать (как продолжение того, что я только что сказал) - если это ваша линия защиты, то LOL на вас!
@JasonCaldwell, ты смеешься надо мной (какая зрелая вещь из тебя, но хорошо), но твоё решение - проверить пропущенное поле, чтобы предотвратить взлом. Ух ты, я должен признать, что я действительно ошеломлен твоими рассуждениями. Я обновил ответ час назад, возьми его или оставь. Это действительно не место для длительных дебатов, и я думаю, что мы с Эриком уже достаточно сказали по этому вопросу.
Вальтер: вы не видите большую картину. это не просто проверка пропущенного поля, это проверка пропущенных полей (под сообщениями), границы массива полей (над сообщениями). Этот метод используется ПРОСТО, чтобы обнаружить любое несоответствие. Вот и все. Подумайте об этом, скажем, у вас есть массив полей, и ваш сайт настроен для обработки счетчика 5, но затем скажите, что хакер генерирует 1000 полей при попытке DOS или попытке взломать / использовать. ТЫ не хочешь знать об этом? Разве вы не хотите бросить и войти на такое событие? Честно говоря, вы, ребята, должны получить контроль.
@JasonCaldwell Да, но, по крайней мере, написание сценария требует просмотра страницы каждый раз. С другой стороны, согласованность полей - это всего лишь задание на копирование и вставку из Fiddler или чего-то еще, и как только я получу правильную форму, я могу просто POST столько раз, сколько захочу. Я не против безопасности, но это все равно что охранять твой дом, наклеивая липкую ленту на дверь.
эмодендрокет: вы недоразумение. Прочтите мои комментарии к Вальтеру, чтобы выяснить, какие у вас могут быть неправильные представления.
Вальтер: Я только что видел твои правки. мои комментарии здесь остаются в силе, и, кажется, есть какое-то недопонимание намерения и цели моей техники. Я бы также добавил, что это не является мерой по предотвращению DOS-атак (надеюсь, вы не считаете меня таким наивным), но он ограничивает воздействие на систему в случае чрезмерной отправки. Дорогая проверка означает просто проверку, которая может произойти, скажем, с сервером SQL или другим внешним вводом-выводом. Underpost не просто не заполняет поля формы, а overpost также включает границы массива.
Это метод проверки необычной или неожиданной активности или поведения вашего приложения или против него. Это один из многих используемых методов. Это не столько мера безопасности (хотя и есть), сколько способ помешать, бросить, записать и перенаправить на определенную серию атак ИЛИ несоответствий. Это не вместо использования других методов, но вместо этого используется в сочетании с другими методами для защиты вашего онлайн-приложения. Я надеюсь (наконец-то), что это прояснит вашу путаницу в этом вопросе.
@JasonCaldwell Я только что заметил ваш комментарий здесь, но я не думаю, что имеет смысл проверять вашу модель представления по внешнему хранилищу данных - это первое место. Если это то, что вам нужно, то более обычный подход - проверить ModelState.IsValid в вашем контроллере, прежде чем вы начнете просматривать базу данных (в коде, который существует отдельно от обычного средства проверки формы MVC). В этом контексте «валидация» действительно относится только к валидации на уровне формы. Если атрибут броска работает для вас, нет проблем, но я думаю, что вы и Уолтер говорите о разных вещах.
«Я думаю, что вы и Вальтер говорите о разных вещах», - согласен. ModelState.IsValid + SQL / external IO - ценим это, полезно. Исходя из Java, ASP.NET MVC - это настоящий уход. Тем не менее, очень быстро подбираю его, стараясь соответствовать правильному способу кодирования в нем.
Я в значительной степени не согласен. Здесь недостаточно места, чтобы взять вас по пунктам, но, как я сказал Вальтеру: «Существуют разные формы проверки. Есть проверка ввода пользователя и есть согласованность и проверка ошибок системы / данных. У каждого есть свое место. Согласованность гарантирует то, что приходит». то, что я ожидаю, - это то, чего я не ожидаю, и если это не так, то кто-то либо напортачил с моим сайтом, либо у меня где-то возникла ошибка. Такие ошибки не для конечных пользователей, и лучше всего их устранять в тот момент, когда их избегают. другие возможные подвиги или проблемы. Хотя я согласен с тем, что угроза такого рода невелика, она все же возникает "
Кроме того, я понимаю различие между Java и ASP-MVC и не пытаюсь переворачивать одно поверх другого. Однако я ожидаю, что смогу сказать, соответствует ли то, что я ожидаю, тому, что я излучаю. И, конечно, не из-за параноика, но, сказав это, - это проект Microsoft.
Я просто беспокоюсь о безопасности, работая с сотнями плохо написанных веб-сайтов и исправив сотни взломов. Обеспечение согласованности проходит долгий путь к безопасному сайту и сокращает накладные расходы системы, если в противном случае возникает эксплойт.
@JasonCaldwell - я предлагаю вам перечитать то, что я написал, поскольку вы, кажется, спорите против того, что вы воспринимаете, я сказал, а не то, что я сделал. Я хочу сказать, что вещи, которые вы рассматриваете как недостаток безопасности в Java, как правило, отсутствуют в ASP.NET, потому что они предназначены для смягчения этих ситуаций и имеют механизмы для их решения, но вы хотите обойти все это и сделать что-то Java. как то, что неправильно делать. В частности, прочитайте мое последнее предложение ясно.
Я спорю с вашей общей точкой (или точками). Более того, я никогда не утверждал, что в Java это недостаток, если бы вы спросили, я бы сказал, что наоборот, гибкость, которую Java предоставляет в этой области и некоторых других, весьма превосходна. В Java многое НЕ сделано для вас, а это означает, что вы знаете, что он делает, потому что вы его кодировали. Хотя вы утверждаете, что ASP.NET предназначен для смягчения «таких» ситуаций, вы не предлагаете объяснения, как это сделать. Я призываю вас перечитать мой оригинальный пост, а также ссылку, содержащуюся внутри. Тестирование NULL для NULL не является эксклюзивным для Java, так что не обращайте внимания на Java.
Ответ сделан на сайте ASP.NET, который кратко заявляет, что «по умолчанию MVC преобразует пустую строку в нулевую строку»: forums.asp.net/t/2006146.aspx?Custom+Validation+and+NULL
Это все, что мне нужно было прочитать после моего вопроса: «Можно ли здесь делать то, что я хочу?»
Я не думаю, что это влияет на Request.Form ... была причина, по которой вам не понравилось это решение? Например, вы можете посмотреть на AllKeys и увидеть, что ключа там нет.
Пожалуйста, объясните, что вы имеете в виду? Я не думаю, что вы понимаете мой первоначальный вопрос или этот ответ.
if (!HttpContext.Current.Request.Form.AllKeys.Contains("prop")){throw new Exception();}
По сути, вы вообще обходите MVC и привязку моделей и просто смотрите на форму.
Ну, я не думаю, что обхожу связывание моделей и, конечно, не совсем. Я просто смотрю на значение, которое использует Binder, да?
Извините, если то, как я это сказал, сбивает с толку; я имею в виду, что ваш ответ здесь говорит о том, что происходит после привязки модели; Я говорю, что вы можете обойти это поведение, посмотрев непосредственно на данные формы. Да, это правда, что данные формы также используются связывателем модели.
Кстати: спасибо за этот пример кода! Это то, что я ищу.
Да, это именно то, что мне нужно, чтобы напрямую "обойти" данные модели и формы. Я надеялся, что смогу достичь этого без необходимости, но ответ ignatandrei в ASP.NET (выше) подтвердил мой первоначальный вопрос. Ваш ответ здесь, однако, улучшает идею Request.Form, позволяя этой проверке действительно происходить либо в модели, либо в пользовательском валидаторе.
Я пытался намекнуть на это раньше, но я отредактировал свой ответ, чтобы быть более ясным. Во всяком случае, надеюсь, что это поможет вам.
Обновил мой пост. Если вы удалите пустую строку из своего ответа выше и оставите здесь ответ, который вы прокомментировали, я отмечу ваш ответ.
Лучшее решение - передать FormsCollection вашему методу действия, который делает то же самое, за исключением того, что он передается в качестве параметра. то есть: public ActionResult Index(FormsCollection collection) {}
В качестве альтернативы, вы можете использовать [Required(AllowEmptyStrings=true)] , и если любое из полей вашей модели на самом деле имеет значение null, то вы знаете, что они отсутствуют, а не просто пусты. Я действительно не понимаю, как это отвечает на вопрос, учитывая все ваши другие требования ...
Привет, Эрик. Суть этого метода заключается в упреждающем обнаружении несоответствий во входящей передаче, чтобы обеспечить соответствие поступающих данных (полей) тому, что ожидает мое приложение. С самого начала, регистрируйте и перенаправляйте, избегая дальнейших проверок от возникновения в случае обнаружения проблемы.
Я не ясно, на AllowEmptyStrings. Я посмотрел это после того, как Эмодендрокет предложил это. Похоже, это не то, чего я хочу, не могли бы вы подтвердить его назначение или как его использовать?
@JasonCaldwell - Смысл AllowEmptyStrings в вашем случае заключается в том, что если строка пуста, то значение будет равно «», если пропущенное значение будет равно нулю. Это поведение, которое исходный код предполагал иметь место, и терпело неудачу, потому что значение было пустым для пустых строк.
Хорошо, это не ясно в описании, которое гласит: «Когда вы устанавливаете AllowEmptyStrings в true для поля данных, Dynamic Data не выполняет проверку и преобразует пустую строку в нулевое значение».
@JasonCaldwell - это для DynamicData, который также использует эти атрибуты ... MVC этого не делает. Вы также хотели бы установить [DisplayFormat(ConvertEmptyStringToNull = false)] в свойстве, а также, если вы используете любой EditorFor's

Casey · Accepted Answer · 2014-09-03T22-20-00.000Z

2

Лучший ответ

Если вам нужен собственный валидатор, вы можете посмотреть словарь HttpContext.Current.Request.Form. Затем вы можете сделать то, что вы предложили с помощью этого кода:

if (!HttpContext.Current.Request.Form.AllKeys.Contains("prop"))
  {
    throw new Exception();
  }

Casey 03 сен. 2014, в 22:20

0

Проблема в том, что вы не сможете выполнить этот код, пока связыватель модели не выполнит полную проверку. Таким образом, ваше требование прервать валидацию не удовлетворяется этим подходом.
Erik Funkenbusch 04 сен. 2014, в 22:02
0

@ErikFunkenbusch Ну, теперь, когда вы упомянули об этом, вы правы в этом, поскольку к тому времени, когда вы находитесь внутри своего действия, модель уже связана. Помещение этого внутрь пользовательского модельного переплета предположительно будет работать. Можно даже просто связать модель, наследуя ее от значения по умолчанию, и отразить все свойства с помощью атрибута, а затем выбросить, если какой-либо из их ключей отсутствует, а затем перейти к базовому методу.
Casey 04 сен. 2014, в 22:09
0

Вам не нужно помещать этот код в пользовательский механизм связывания, потому что этот механизм уже использует отражение, чтобы просмотреть все свойства и сравнить их со свойствами размещенных объектов. И действительно, ваш вывод именно то, что я описал в своем посте.
Erik Funkenbusch 04 сен. 2014, в 22:11
0

«Проблема в том, что вы не сможете выполнить этот код, пока не произойдет полная проверка», - правда ли это, даже если я использую Custom Validator и выбрасываю в этот момент?
user1068477 04 сен. 2014, в 22:36
0

Уточнены вопросы и примеры кода, чтобы сделать его более понятным, и включен пример, который работает на @emodendroket.
user1068477 05 сен. 2014, в 02:04

Показать ещё 3 комментария