Уязвимости безопасности внешнего интерфейса, обнаруженные в общедоступной учетной записи WeChat

внешний интерфейс JavaScript

Вчера в официальном аккаунте была обнаружена уязвимость безопасности XSS, конкретный процесс воспроизведения выглядит следующим образом:

  1. Отправить статью в публичный аккаунт, заголовок содержит<input onfocus="alert('1')">
  2. После того, как пользователь откроет статью, он обнаружит, что заголовок не экранируется на странице написания сообщения и обычно отображается в HTML.
  3. Выполнить код после того, как пользователь щелкнет отображаемое поле ввода.

Вот видео, которое воспроизводит уязвимость

ссылка на видео

Если видео не открывается снова, вы можете перейти кВ статье моего пабликаСмотреть.

Теперь давайте проанализируем процесс генерации этой уязвимости.

Первый HTML существует в заголовке<input onfocus="alert('1')">, если эта часть текста не экранирована на веб-странице, она будет отображаться как HTML в обычном режиме.

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

Однако эта проблема возникла на странице сообщений, то есть разработчик не ушел от заголовка, что и привело к возникновению этой проблемы.

Хотя условие запуска этой проблемы не так просто, появление такой низкоуровневой проблемы безопасности в таком продукте, как WeChat, неожиданно.

Мы называем такие проблемы безопасности атакой XSS. По источнику атаки мы можем разделить такие атаки на три типа:

  • Светоотражающий
  • тип хранения
  • тип документа

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

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

function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}
// "&lt;script&gt;alert(1)&lt;&#x2F;script&gt;"
escape('<script>alert(1)</script>')

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

// 使用 js-xss 开源项目
const xss = require('xss')
let html = xss('<h1 id="title">XSS</h1><script>alert("xss");</script>')
// -> <h1>XSS</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html)

В случае белого спискаh1Метки не экранируются, аscriptможно нормально сбежать.

Наконец

Безопасность — дело нетривиальное, при работе над проектом всегда нужно обращать внимание на возможные проблемы с безопасностью в подобных сценариях.

Если вы считаете, что контент полезен, вы можете обратить внимание на мой официальный аккаунт «Внешняя часть действительно забавная» и регулярно делиться следующими темами:

  • Внешнее мало знаний, холодное знание
  • Основное содержание
  • Повысить эффективность работы
  • персональный рост

Категории