Предотвращение червя Osama Facebook

Существует червь javascript worm, распространяющийся на facebook. Червь вводит в действие javascript копирование и вставка полезной нагрузки в адресную строку. Это не xss, это социальная инженерия. Если вы прочтете исходный код червя, вы увидите, что он едет на сессии и подделывает запросы, такие как червь Sammy. Каким образом веб-приложение может предотвратить такой тип атаки?

Ответ 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 -ограниченных действий после получения запроса на сервер. Лучшее, что вы можете сделать, это попытаться использовать эвристику для обнаружения подозрительных запросов и остановить их.