Апостроф получил фильтр в С#

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

У нас есть script, который принимает комментарии пользователей (все комментарии написаны на английском языке). Через два года мы собрали около 3 000 000 комментариев. Я проверял таблицу комментариев за любые признаки злонамеренного поведения, и на этот раз я просмотрел апостроф. Это должно было быть преобразовано в объект HTML (') во всех случаях, но я нашел 18 записей (из 3 миллионов), в которых сохранился персонаж. То, что действительно ломает голову, состоит в том, что в одном из этих 18 комментариев один апостроф фактически был успешно преобразован - другой выжил.

Это указывает на то, что у нас есть возможная уязвимость XSS.

Моя теория для того, что происходит, заключается в том, что пользователь нажимает на страницу в компьютерной системе, которая использует незападную кодовую страницу, и что их браузер игнорирует нашу спецификацию кодировки utf-8 нашей страницы, что его/ее вход не получает преобразуется в локальную кодовую страницу сервера, пока не попадет в базу данных (поэтому С# не распознает символ как апостроф и, следовательно, не может его преобразовать, но база данных, когда она пытается записать ее в таблицу LATIN1). Но это общее предположение.

Кто-нибудь сталкивался с этим раньше или знал, что происходит?

И что еще более важно, кто-нибудь знает, как я могу проверить свой script? Перемещение на HttpUtility, вероятно, исправит ситуацию, но пока я не знаю, как это произошло, я не могу понять, что проблема исправлена. Мне нужно проверить это, чтобы узнать, как работают наши решения.

Edit

Ого. Уже в 20 точках, поэтому я могу изменить свой вопрос.

Я упомянул в одном из своих комментариев, что нашел несколько символов, которые кажутся проблематичными. Они включают: 0x2019, 0x02bc, 0x02bb, 0x02ee, 0x055a, 0xa78c. Они проходят прямо через наш фильтр. К сожалению, они проходят через все методы кодирования HttpUtility. Но как только они встают в базу данных, они преобразуются либо в фактический апостроф, либо в "?".

В обзоре, я думаю, проблема в том, что эти персонажи сами по себе не представляют угрозы, поэтому у HttpUtility нет причин для их преобразования. В блоке Javascript они безвредны. В блоке HTML они являются только символьными данными и безвредны. А в блоке SQL они безвредны (если база данных разделяет одну и ту же кодовую страницу). Проблема в том, что, поскольку кодовая страница, которую мы используем в базе данных, различна, процесс вставки в базу данных включает в себя преобразование этих "непечатаемых" символов в "известные эквиваленты" (которые в данном случае являются "плохими" ) неизвестные эквиваленты "(которые получают как"? "). Это полностью ослепило нас, и я немного разочарован в MS, чтобы не создавать больше функций HttpUtility для кодирования.

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

Ответ 1

Это похоже на то, что ваше хранилище внутри СУБД использует тип столбца, отличного от юникода, в то время как .net использует юникод.

Вы можете в .net изначально преобразовать Юникод в свою сортировку dbms, а затем вернуться в Юникод, чтобы удалить любые неподдерживаемые символы на уровне приложения, а не оставить это в dbms/connector.

var encoding = Encoding.GetEncoding("Latin1") //this should be matched to the column collation
foo = encoding.GetString (encoding.GetBytes (foo)); // couldn't see a more efficient way to do this.

Как уже упоминалось ранее, в идеале вы должны были сохранить фактические символы в СУБД и оставить кодировку на этапе представления. Из чего вы попытаетесь настроить структуру таким образом, вы не можете забыть кодировать строковые данные, например asp.net 4 использует <%: %>, JSON с использованием JSON.Net, а не для конкатенации строк, для XML XLINQ и т.д..

Ответ 2

Вы фильтруете не то место, ИМХО. База данных должна содержать фактические символы, введенные пользователем. Вы должны оставить экранирование HTML на уровень презентации, который лучше знает, как это сделать.

Ответ 3

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

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

Как и в - HtmlEncode() все данные, отображаемые на странице для начала, и делают это для каждого поля, которое пользователь может редактировать. Даже базовые поля имени и т.д., А не просто данные тела тела.

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