Риски, позволяющие пользователям создавать ссылки?

Question

Я настраиваю веб-среду, где пользователи могут создавать ссылки , но они могут изменять только атрибут href, а не сами теги <a>.

В принципе, допустимо любое значение href; HTTP/FTP/MAILTO/все.

Есть ли какой-либо XSS или другие риски для моего сайта, если я оставляю атрибут href открытым следующим образом? Если да, каковы они будут и как я должен их обрабатывать?

Answer 1

Вы должны убедиться, что значение href будет действительным URL. Если бы вы не избежали ввода пользователя, это сделало бы инъекции mySQL возможными.

также пользователь может ввести JavaScript:

<a href="javascript:window.close();">Javascript will close the browser window on click</a> 

Answer 2

Есть схемы URL, такие как javascript: или, возможно, data:, которые могли бы сами по себе служат в качестве векторов XSS, если пользователь обманут в щелкая их. Вы должны сохранить белый список известных, безопасных схем URL (например, http, https, ftp и т. Д.) И запретить любые URL-адреса, которые не начинаются с такой схемы.

Обратите внимание, что просто черных списки известных опасные схемы URL является не безопасным подходом, так как вы не можете знать все схемы, которые могут быть использованы в качестве векторов атаки (так как это может зависеть от таких вещей, как то, что программное обеспечение сторонних производителей пользователь установил). В частности, имейте в виду, что схемы URL должны быть нечувствительны к регистру; наивная реализация черного списка, которая просто запретила URL-адреса, начинающиеся с javascript:, может быть тривиально обойдена URL-адресом jAvAsCrIpT:.

(Вы могли позволить schemeless относительных URL-адресов, если вы хотите, но если это так, убедитесь, что вы разбираете их консервативно и according to the standard, так что злоумышленник не может скрыть вредный абсолютный URL как относительное. В в частности, я бы рекомендовал, чтобы любой URL-адрес, который содержит двоеточие (:), перед первым косой чертой (/), если таковой имеется, следует рассматривать как абсолютный URL-адрес, подчиненный whitelisting. Чтобы быть уверенным, вы также можете добавить строку " ./ "на любые относительные URL-адреса, которые еще не начинаются с" / "или" ./ ", чтобы устранить любую возможную разницу в синтаксическом анализе.)

Еще одна вещь, которую вам нужно убедиться в том, что вы правильно HTML-escape любые строки, включая URL-адреса (особенно пользовательских), которые будут внедрены в атрибуты HTML. В частности, любые символы & необходимо заменить символом-символом & и (для атрибутов с двойными кавычками) любыми " символами с ". Замена < на < и ' с ' также может быть хорошей идеей, и самым безопасным подходом может быть замена любых символов (кроме известных безопасных, таких как буквенно-цифровые) с соответствующими объектами символов HTML. В любом случае, для языка программирования, вероятно, есть стандартная функция или библиотека для этого (например, htmlspecialchars() в PHP).

Ps. См. Также OWASP XSS Filter Evasion Cheat Sheet для некоторых примеров возможных атак, которые ваша реализация должна уметь сопротивляться.