Подтвердить что ты не робот

Защитить от расширения браузера код Javascript

Браузеры позволяют расширениям вводить код, манипулировать DOM и т.д.

На протяжении многих лет я замечал множество и непонятные ошибки (используя window.onerror) на веб-сайте (приложении), который я просматриваю, созданный неизвестными расширениями браузера Firefox, Chrome и Internet Explorer (все версии).

Эти ошибки, похоже, не прерывали ничего. Теперь я хочу повысить безопасность этого веб-сайта, потому что он начнет обрабатывать кредитные карты. Я видел своими глазами вредоносное ПО/шпионское ПО, заражающее браузеры с измененными расширениями браузера (невинное расширение браузера, модифицированное, чтобы сообщать злоумышленникам / script kiddies), работающие в качестве кейлоггеров (с использованием тривиальных обработчиков событий onkey * или просто проверок ввода.значения).

Есть ли способ (метатег и т.д.), чтобы сообщить браузеру о запрете ввода кода или чтении DOM, стандартного или нестандартного? Веб-страница уже является SSL, но это не означает, t, похоже, имеет значение (как в подсказке браузеру активировать более строгую защиту для расширений).

.

Возможные обходные пути (вид растяжки против простого метатега), предложенный другими или с верхней части головы:

  • Виртуальная клавиатура для ввода чисел + не текстовые входы (aka img для цифр)
  • удаленный рабочий стол с использованием Flash (кто-то предложил HTML5, но это не решит расширение браузера при прослушивании на клавиатуре, только Flash, Java и т.д.).
  • Очень сложная защита на основе Javascript (удаляет небелые зарегистрированные события событий, входные значения в памяти вместе с входами, защищенными действительными символами звездочки и т.д.) (это невозможно, если оно уже не существует)
  • Расширение браузера с ролью антивируса или которое может каким-то образом защитить определенную веб-страницу (это невозможно, возможно, даже невозможно без создания огромного множества проблем)

Изменить. Google Chrome отключает расширения в режиме инкогнито, однако нет стандартного способа обнаружения или автоматического включения режима инкогнито, поэтому необходимо отображать постоянное предупреждение.

4b9b3361

Ответ 1

ОБНОВЛЕНИЕ (2019-10-16): Это не "реальное" решение - это означает, что вы не должны полагаться на это как на политику безопасности. Правда в том, что не существует "реального" решения, потому что злонамеренные аддоны могут перехватывать/подделывать JavaScript способом, который невозможно обнаружить. Приведенная ниже техника была для меня большим упражнением, чтобы выяснить, как предотвратить простую регистрацию ключей. Вы могли бы расширить эту технику, чтобы сделать ее более трудной для хакеров... но Влад Балмос сказал, что лучше всего в своем ответе ниже. платежи через интернет в первую очередь.


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

  • Использует подсказку (), чтобы запросить номер кредитной карты в фокусе.
  • Обеспечивает отказоустойчивость, когда пользователи проверяют "запретить дополнительные диалоги" или если пользователь каким-то образом может вводить в поле CC
  • Периодически проверяется, чтобы убедиться, что обработчики событий не были удалены или подделаны, и при необходимости повторно связывает/предупреждает пользователя.

http://jsfiddle.net/ryanwheale/wQTtf/

prompt('Please enter your credit card number');

Протестировано в IE7+, Chrome, FF 3. 6+, Android 2.3.5, iPad 2 (iOS 6.0)

Ответ 2

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

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

UPDATE Мы должны все обернуть. Что-то вроде:

<meta name="disable-extension-feature" content="read-dom" />

или

<script type="text/javascript">
    Browser.MakeExtension.MallwareLogger.to.not.read.that.user.types(true);
</script>

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

Ответ 3

Ваш вопрос интересный и продуманный (+ 1'd), однако, к сожалению, предлагаемая безопасность не обеспечивает реальной безопасности, поэтому ни один браузер не сможет ее реализовать.

Одним из основных принципов безопасности браузера/сети/сети является противодействие желанию реализовать фальшивую функцию безопасности. Веб будет менее защищен с помощью функции, чем без!

Услышьте меня:

Все, выполняемые на стороне клиента, можно манипулировать. Браузеры - это еще один HTTP-клиент, который говорит с сервером; сервер никогда не должен доверять результату вычисления или проверкам в интерфейсе Javascript. Если кто-то может просто обойти ваш код проверки безопасности, выполненный в браузере с расширением, он может, конечно, запустить HTTP-запрос непосредственно на ваш сервер с помощью curl. По крайней мере, в браузере опытные пользователи могут обратиться к Firebug или Web Inspector и обойти ваш script, точно так же, как и при отладке вашего сайта.

Тег <meta>, останавливающий расширения от инъекции, делает сайт более надежным, но не более безопасным. Есть тысячи способов писать надежный JavaScript, чем молиться о том, чтобы не иметь злого расширения. Скрывайте свои глобальные функции/объекты, являющиеся одним из них, и выполняйте проверку работоспособности среды как другое. Например, GMail проверяет Firebug. Многие сайты обнаруживают рекламный блок.

Тег <meta> имеет смысл с точки зрения конфиденциальности (опять же, а не безопасности). Должен быть способ сообщить браузеру, что информация, находящаяся в настоящее время в DOM, чувствительна (например, мой банковский баланс) и не должна подвергаться третьим лицам. Тем не менее, если пользователь использует ОС от поставщика A, браузера от поставщика B, расширения от vender C, не читая его исходным кодом, чтобы точно знать, что они делают, пользователь уже заявил о своем доверии к этим продавцам. Здесь ваш сайт не будет виноват. Пользователи, которые действительно заботятся о конфиденциальности, обратятся к своей доверенной ОС и браузеру и используют другой профиль или частный режим браузера, чтобы проверить их конфиденциальную информацию.

Вывод: Если вы выполняете все проверки ввода на стороне сервера (снова), ваш сайт достаточно безопасен, чтобы тег <meta> не мог сделать его более безопасным. Молодцы!

Ответ 4

Я видел, что нечто подобное выполнялось много раз, хотя защита была направлена ​​по-другому: довольно много сайтов, когда они предлагают конфиденциальную информацию в форме текста, будут использовать виджет Flash для отображения текста (например, адреса электронной почты, которые в противном случае были бы обнаружены ботами и спам).

Flash-апплет может быть настроен на отклонение любого кода, который поступает с HTML-страницы, фактически, если вы специально не ожидаете, что это будет возможно, оно не будет работать из коробки. Flash также не перенаправляет события в браузер, поэтому, если кейлоггер работает на уровне браузера, он не сможет зарегистрировать нажатые клавиши. Конечно, Flash имеет свои недостатки, но, учитывая все другие варианты, это кажется наиболее выполнимым. Таким образом, вам не нужен удаленный рабочий стол через Flash, простой встроенный апплет будет таким же хорошим. Кроме того, Flash не может использоваться для создания полнофункционального клиента удаленного рабочего стола, вы бы искали в NaCl или JavaFX, что сделало бы это использование только для корпоративных пользователей и только в конечном итоге частными пользователями.

Другие вещи, которые следует учитывать: напишите собственное расширение. Создание Firefox-расширения очень просто + вы можете повторно использовать много своего кода JavaScript, так как он также может использовать JavaScript. Я никогда не писал расширение Google Chrome или MSIE, но я бы подумал, что это не намного сложнее. Но вам не нужно превращать его в антивирусное расширение. Благодаря имеющимся инструментам вы можете сделать так, чтобы ни одно другое расширение не могло подслушивать то, что происходит внутри вашего собственного расширения. Я не уверен, насколько приветствуется ваша аудитория, но если вы ориентируетесь на корпоративный сектор, то эта аудитория в некотором роде очень хороша, так как они не могут выбирать свои инструменты... так что вы могут просто обязать их использовать расширение.

Больше идей? - хорошо, этот очень прямой и эффективный: попросите пользователей открыть всплывающее окно/отдельную вкладку и отключить JavaScript в ней:) Я имею в виду, что вы можете отказаться принимать информацию о кредитной карте если JavaScript включен в браузере - очевидно, его очень легко проверить. Для этого потребуется некоторое умственное усилие от пользователей, чтобы найти настройку, где они могут ее отключить + они будут бушевать во всплывающем окне... но почти наверняка это отключит всю инъекцию кода:)

Ответ 5

Это не работает, но я попробую что-то вокруг document.createElement = function() {}; Это должно повлиять на скрипты на стороне клиента (greasemonkey)

Вы также можете попытаться отправить текущий DOM с помощью скрытого ввода myform.onsubmit=function(){myform.hiddeninput.value=document.body.innerHTML;} и проверьте серверную сторону на наличие нежелательных элементов DOM. Я предполагаю, что использование идентификатора/токена на стороне сервера на каждом элементе может помочь здесь (поскольку введенный DOM node обязательно пропустит его)

= > страница должна выглядеть как

<html uniqueid="121234"> <body uniqueid="121234"><form  uniqueid="121234"> ...

Поэтому поиск незаметных элементов в действии POST должен быть простым (например, с помощью xpath)

<?php
simplexml_load_string($_POST['currentdom'])->xpath("*:not(@uniqueid)") //style

Что-то вокруг этого для проблемы с вводом DOM.

Что касается части keylogging, я не думаю, что вы можете сделать что-либо, чтобы предотвратить кейлоггер с точки зрения клиентской стороны (за исключением использования виртуальной клавиатуры и т.д.), так как нет никакого способа распознать их из внутренних элементов браузера. Если вы параноик, вы должны попробовать 100% созданный холст дизайн (имитирующий HTML-элемент и взаимодействие), поскольку это может защитить вас (ни один элемент DOM не привязан), но это будет означать создание браузера в браузере.

Ответ 6

И только мы все знаем, что мы не можем явно блокировать расширения из нашего кода, Другим способом может быть поиск списка прослушивателей событий, прикрепленных к ключевым полям, таким как пароль, ssn, а также события на теле, такие как keypress, keyup, keydown и проверка того, принадлежит ли слушатель к вашему коду, если не просто выбросить флеш-сообщение для отключения аддоны.

И вы можете прикрепить события мутации к своей странице и посмотреть, есть ли какие-то новые узлы, которые создаются/генерируются третьей стороной, кроме вашего кода.

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

любые участники?