Существует червь javascript worm, распространяющийся на facebook. Червь вводит в действие javascript копирование и вставка полезной нагрузки в адресную строку. Это не xss, это социальная инженерия. Если вы прочтете исходный код червя, вы увидите, что он едет на сессии и подделывает запросы, такие как червь Sammy. Каким образом веб-приложение может предотвратить такой тип атаки?
Предотвращение червя Osama Facebook
Ответ 1
Образование - лучший и единственный способ.
Ответ 2
Если мы говорим о вредоносном пользователе script, манипулирующем DOM (как это, похоже, делает):
Вы можете убедиться, что весь собственный JS-код скрыт от глобальной области (через закрытие), а затем убьет свойство document
window
. Могут быть способы, которыми червь может обойти это, но это, безусловно, усложнит ситуацию.
Это не то, что я действительно пытался и доказал, что работаю, но основная идея:
(function () {
// Initialize page
// When we're done, make document inaccessible
window.document = null;
})();
Предполагается, что весь собственный код, выполняемый во время инициализации страницы (включая код jQuery и т.д.), должен быть привязан к фактическому объекту document
через закрытие. Невозможно, чтобы код "javascript:" в адресной строке получал доступ к фактическому документу, выполняя его в глобальной области.
Опять же, я мог бы пропустить что-то откровенно ошибочное с этой идеей, и я готов принять все downvotes. Возможно, есть дополнительные шаги, которые необходимо предпринять, чтобы полностью скрыть document
.
Ответ 3
Для червей социальной инженерии, таких как этот чрезвычайно простой, все должно было сводиться к образованию. Это проблема осведомленности, как и большинство проблем социальной инженерии.
Я вижу так много людей, которые, похоже, попадают на все мошенники в facebook, и это должно быть проще, чем большинство других, поскольку на самом деле требуется, чтобы пользователь вводил команды. Но люди отчаянно хотят увидеть фотографии мертвого террориста. WTF?
Трудная вещь заключается в том, как убедить их в том, что, хотя то, что они делают, может не повредить их напрямую, это действительно стоит. Это та же проблема, что и попытка убедить домашних пользователей запускать антивирус и брандмауэры - многие даже не заботятся, заражены ли они и запущены как часть ботнета, если они могут играть в свои игры и просматривать сеть.
Технически - это можно сделать с помощью facebook, но этого не будет. Это можно предотвратить, просто сопоставив шаблоны и удалив ключевые подписи. Это потребует слишком много усилий, и как только вы разобрали конкретную проблему, вокруг этого будет способ.
tl; dr - Просветите ВСЕ! Должна работать и не поддается, но стоит попробовать.
Ответ 4
Очень простое решение - заставить пользователей использовать окно браузера без адресной строки. Хотя это решение имеет свои проблемы.
Другое решение использует javascript и/или flash, что позволяет взаимодействовать с буфером обмена. Проверка может выполняться всякий раз, когда запускается событие ctrl + c (или таймер). Если сообщение начинается с javascript:
, тогда пустое сообщение или предупреждение копируются в буфер обмена.
Ответ 5
Если вы говорите о способах защиты пользователей вашего сайта от этой формы атаки (т.е. кражи файлов cookie), я предполагаю, что следующие основные шаги помогут, конечно, намного больше, что вы могли бы сделать, и этот небольшой список не является исчерпывающим:
- Не позволяйте пользователям публиковать Javascript!: -)
- Шифровать данные вашего куки файла с помощью закрытого ключа, чтобы только ваше веб-приложение могло использовать данные в
- Блокировать сеансы до IP, поэтому, если кто-то украл файл cookie/session cookie, его нельзя было повторно использовать
Ответ 6
К сожалению, на самом деле нет способа остановить выполнение пользователем javascript в контексте вашего веб-приложения. Вы можете опубликовать заметку, предупреждающую пользователей не вставлять скрипты, которые они не понимают в адресной строке, или вы можете попытаться запутать код клиента, но ничто из этого не поможет остановить проблему. В случае обфускации кода для мошенника требуется немного больше работы, чтобы написать полезный код.
Так как код выполняется в контексте вашего веб-приложения, у вас нет надежного способа рассказать о законных действиях пользователя из script -ограниченных действий после получения запроса на сервер. Лучшее, что вы можете сделать, это попытаться использовать эвристику для обнаружения подозрительных запросов и остановить их.