Можем ли мы сказать, что защищены от XSS-атак, если удалим из ввода все слова script и java?

Я использую asp.net htmleditorextender и, к сожалению, сейчас нет рабочего XSS-санитайзера. Итак, для быстрого решения я заменяю все слова script и java из пользовательского ввода, как показано ниже.

    var regex = new Regex("script", RegexOptions.IgnoreCase);
    srSendText = regex.Replace(srSendText, "");

    regex = new Regex("java", RegexOptions.IgnoreCase);
    srSendText = regex.Replace(srSendText, "");

Могу ли я предположить, что я защищен от XSS-атак?

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


c# asp.net xss sanitization
person MonsterMMORPG    schedule 23.04.2013    source источник
comment
Как предотвратить межсайтовый скриптинг в ASP.NET   -  person Habib    schedule 23.04.2013
comment
Просто убедитесь, что вы правильно экранируете ввод, прежде чем отображать его как HTML (или экранируете его, когда он приходит), — это то, как вы обычно предотвращаете XSS.   -  person jbabey    schedule 23.04.2013
comment
Вы пробовали атаковать его сами?   -  person Paul    schedule 23.04.2013
comment
Одна из причин, по которой я люблю бритву: если вы совершите ошибку, вы, как правило, будете дважды кодировать данные, а не открывать XSS-дыру. Одна из этих двух вещей легко обнаруживается и не сопряжена с риском; другой тонкий и действительно опасный ...   -  person Marc Gravell    schedule 23.04.2013
comment
Некоторые другие потенциальные уязвимости: stackoverflow.com/questions/5779875/   -  person MichaelD    schedule 23.04.2013
comment
@jbabey, можешь объяснить подробнее. что вы подразумеваете под экранированием ввода =?   -  person MonsterMMORPG    schedule 23.04.2013

Ответы (2)


arrow_upward
4
arrow_downward

Нет, ты не можешь.

Злоумышленник может легко обойти такую ​​проверку, например, закодировав script как script.

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

person Guffa    schedule 23.04.2013
comment
я понимаю. поэтому мне нужно сначала декодировать, заменить, затем закодировать и сохранить :) - person MonsterMMORPG; 23.04.2013
comment
@MonsterMMORPG: Нет. Замена нескольких ключевых слов не защитит вас. Вы должны кодировать текст, когда вы помещаете его на страницу, чтобы разметка вообще не выполнялась, вместо того, чтобы пытаться удалить опасные ключевые слова, чтобы разметка могла быть выполнена. - person Guffa; 23.04.2013
comment
Как мне это сделать ? можешь показать пример? Разве я не должен декодировать и отображать пользователю? - person MonsterMMORPG; 23.04.2013
comment
@MonsterMMORPG: это зависит от того, какой тип приложения вы используете. Например, в приложении веб-формы вы используете <%= Server.HtmlEncode(text) %> для кодирования вывода. - person Guffa; 23.04.2013
comment
я полагаю, закодированный текст декодируется браузером, но не выполняется как скрипт, верно? - person MonsterMMORPG; 23.04.2013
comment
@MonsterMMORPG: Да. Любые теги HTML будут отображаться на странице в виде текста, а не разбиваться на элементы. - person Guffa; 24.04.2013

arrow_upward
1
arrow_downward

Пользовательское предотвращение XSS, на мой взгляд, обычно недопустимо, поскольку вы всегда должны использовать библиотеку. Однако удаления script и java недостаточно, все, что передается на сервер, должно использовать HttpUtility.HtmlEncode, который будет кодировать любой ввод от пользователя.

Также убедитесь, что в файле конфигурации установлено значение validateRequest="true".

Другие опасные теги могут включать:

  • апплет
  • тело
  • вставлять
  • Рамка
  • сценарий
  • набор фреймов
  • HTML
  • iframe
  • изображение
  • стиль
  • слой
  • ссылка на сайт
  • слой
  • мета
  • объект

http://msdn.microsoft.com/en-us/library/ff649310.aspx

person Darren    schedule 23.04.2013
comment
@MonsterMMORPG вы можете использовать AntiXSS — msdn.microsoft.com/en-us/security /aa973814.aspx - person Darren; 23.04.2013