Предотвращение атак XSS на пользовательский HTML-контент в PHP, eBay
Я читал так много статей, описывающих методы предотвращения атак XSS в представленном пользователем HTML-контенте, используя такие функции, как htmlspecialchars и регулярные выражения, whitelisting/blacklisting и использование html-фильтров, таких как HTML Purifier, HTMLawed и т.д.
К сожалению, ни один из них не объясняет, как такой сайт, как eBay, способен разрешить такой огромный массив потенциально вредоносных тегов HTML, таких как <link>, <script>, <object> и стили CSS и атрибуты HTML, такие как фон: url() и т.д. Кажется, что они позволяют пользователям отправлять почти что-либо в свои описания предметов. Я видел некоторые из самых сложных HTML, Javascript и Flash-шаблонов в описаниях элементов.
Что делает eBay по-другому? Есть ли еще один метод или слой, который мне не хватает, что позволяет им блокировать атаки XSS, сохраняя при этом все, что можно включить в описание пользовательских элементов?
Любые идеи или понимание этого будут очень признательны!
Ответы
Ответ 1
Легко, когда у вас есть армия программистов и военный сундук, полный денег.
Это не ракетостроение. Они идентифицируют случай уязвимости и кодируют вокруг него, вероятно, через Regex и Javascript на front-end, а также для проверки подлинности на внутреннем сервере, чтобы гарантировать, что данные не будут скомпрометированы до вставки. Это то же самое, что мы все должны делать, за исключением того, что для Ebay гораздо более зрелым, чем большинство из нас работает, и FAR больше.
Если это что-то вроде банка, на котором я работал, у них есть команда PAS, которая занимается поиском минутных ошибок в prod, открытием билетов с инженерами и последующим процессом в приоритетном порядке. Между разработчиками, тестировщиками, управлением качеством и PAS нет причин, по которым уязвимость должна выйти, но если это произойдет, то нужно быстро реагировать.
Вам следует подумать о том, чтобы подходить к этой проблеме с помощью "прогрессивного повышения", если вы планируете пройти этот маршрут. Начните с первоначальной блокировки javascript. Затем улучшите, чтобы позволить - некоторое - с помощью метода, который вы считаете безопасным, - и только разрешите, насколько безопасно продолжать работу. Продолжайте этот процесс, позволяя все больше и больше ловить края, когда они появляются в процессе тестирования или производства. Постепенно вы перейдете от разрешения того, что разрешено блокировать то, что НЕ. Хотя это не должно быть проблемой, даже самые современные компании пропускают лодку по базовой концепции управления жизненным циклом и улучшения.
При этом при попытке дезинформировать входные данные лучше всего сочетать методы проверки как на фронте, так и на заднем плане. Передняя часть обеспечивает более интуитивно понятную быструю обратную связь с клиентами, но, как и любой клиентский язык, могут быть преодолены со стороны пользователей. Проверка бэкэнд - это ваш брандмауэр, гарантирующий, что все, что проскальзывает мимо интерфейса, обрабатывается соответствующим образом. Ваша БД - это ваш жизненный путь, поэтому защитите ее любой ценой!
Если у вас нет армии и огромного бюджета, пытаясь кодировать для каждого случая края что-то столь же широкое, как CMS, что позволяет почти карт-бланш-вход почти всегда заканчивается убыточным финансовым предприятием.
Ответ 2
Я провел некоторое время с этим, и я смог alert(document.cookie) - что-то, что их черные списки явно пытаются предотвратить, - опираясь на многолетний эксплойт, перечисленный здесь:
http://menno.b10m.net/blog/blosxom.cgi/web/ebay-xss.html
Я фактически не опубликовал список, поэтому могу только сказать наверняка, что это работает в режиме предварительного просмотра списка.
Если это какое-то указание, тогда ответ на ваш вопрос таков: ebay действительно не предотвращает атаки xss. У них есть некоторые черные списки на месте, но они кажутся довольно тривиальными, чтобы уклоняться.
Изменить: Кажется, я работаю над своей страницей ebay "обо мне" фактическая живая страница. Короче говоря, попытки Ebay по фильтрации XSS выглядят довольно жалко.
Ответ 3
Хотя я не могу сказать точно, есть много методов, чтобы помочь.
Основным компонентом для этого является наличие активного и доступного отдела безопасности + разработки.
Хотя они, безусловно, имеют механизм фильтрации, код, вероятно, оценивается в тренажерах и оценивается по определенным критериям (например, подозрительный контент, обфускация и т.д.).
Затем существует также "Механический турк" , который Amazon использует дико (в основном, они используют людей "дешевой рабочей силы", чтобы судить о чем-то разумном).
