Апостроф прошел через фильтр в C #

Question

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

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

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

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

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

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

Редактировать

Wow. Уже на 20 баллов, поэтому я могу редактировать свой вопрос.

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

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

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

Answer 1

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

Answer 2

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

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

var encoding = Encoding.GetEncoding("Latin1") //this should be matched to the column's 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 и т. Д..

Answer 3

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

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

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

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