Можно ли дезинфицировать код Javascript?
Я хочу разрешить пользователям добавлять Javascript в разделы моего веб-сайта.
- Это совершенно безумие?
- Существуют ли какие-либо сценарии очистки Javascript или хорошие шаблоны регулярных выражений для сканирования предупреждений, окон iframe, удаленных сценариев и других вредоносных сценариев Javascript?
- Следует ли авторизовать этот процесс вручную (человеком, проверяющим Javascript)?
- Было бы разумнее разрешить пользователям использовать только фреймворк (например, jQuery), а не дать им доступ к актуальному Javascript? Так будет проще отслеживать.
Спасибо
7 ответов
1. Это совсем безумие?
Не думаю, но близко. Посмотрим.
2. Существуют ли какие-либо дезинфицирующие сценарии Javascript или хорошие шаблоны регулярных выражений для сканирования предупреждений, фреймов, включенных удаленных сценариев и других вредоносных сценариев Javascript?
Да, по крайней мере, есть Google Caja и ADSafe, чтобы очистить код, позволив его изолировать. Однако я не знаю, до какой степени достоверности они обеспечивают.
3. Должен ли этот процесс авторизоваться вручную (человеком, проверяющим Javascript)?
Возможно, что песочница выйдет из строя, так что это будет разумное решение, в зависимости от риска и компромисса, связанного с атакой злоумышленника (или неверный) код.
4. Было бы разумнее разрешить пользователям использовать только фреймворк (например, jQuery), а не предоставлять им доступ к реальному Javascript? Таким образом, может быть легче контролировать.
JQuery — это обычный Javascript, поэтому, если вы пытаетесь защититься от атак, он совсем не поможет.
Если крайне важно предотвратить такие атаки, вы можете реализовать собственный язык, разобрать его в бэкэнде и создать контролируемый безопасный javascript; или вы можете рассмотреть другую стратегию, например предоставление API и доступ к нему из стороннего компонента вашего приложения.
Подумайте обо всем, что ВЫ можете делать с помощью javascript. Затем подумайте о том, что бы вы сделали, если бы могли делать это на чужом сайте. Это вещи, которые люди будут делать просто потому, что они могут, или чтобы выяснить, могут ли они. Я вообще не думаю, что это хорошая идея.
Вместо того, чтобы проверять вредоносные вещи, такие как включение скриптов, я бы выбрал белый список на основе регулярных выражений для нескольких команд, которые вы ожидаете использовать. Затем пригласите человека для авторизации и добавления новых допустимых команд в белый список.
Я думаю, что правильный ответ – 1.
Как только вы разрешаете Javascript, вы открываете себя и своих пользователей для всевозможных проблем. Не существует идеального способа очистить Javascript, и такие люди, как Армия Троллей, воспримут это как свою личную миссию, чтобы испортить вам жизнь.
- Возможно. Возможности для плохих поступков будут намного больше, чем когда вы просто разрешаете HTML, но пытаетесь избежать выделения JavaScript.
- Не знаю.
- Ну, две вещи: вы действительно хотите тратить свое время на это, и если вы это делаете, вам лучше убедиться, что они видят код javascript, а не реальный живой JavaScript!
- Я не понимаю, почему это может иметь какое-то значение, если только у вас нет кого-то, кто одобряет сообщения, и этот человек лучше разбирается в jQuery, чем в простом JavaScript.
Может быть безопаснее разработать/реализовать собственный ограниченный язык сценариев, который может быть очень похож на JavaScript, но находится под управлением вашего собственного интерпретатора.
Посмотрите на Google Caja:
Caja позволяет веб-сайтам безопасно встраивать веб-приложения DHTML от третьих лиц и обеспечивает расширенное взаимодействие между страницей встраивания и встроенным Приложения. В нем используется модель безопасности с объектными возможностями, позволяющая использовать широкий спектр гибких политик безопасности, чтобы содержащая страница могла эффективно контролировать использование пользовательских данных встроенными приложениями и позволяла гаджетам предотвращать взаимодействие между элементами пользовательского интерфейса гаджетов.