предотвращение проблема безопасности IFrame

Question

Как описано здесь http://blogs.gartner.com/avivah-litan/2010/04/22/watch-out-transaction-signing-is-being-socially-engineered/

Способ подписания транзакции, которая была нарушена работы является то, что когда запрос на платеж был инициирован интернет-банкинга пользователя, банк запрашивает у пользователя подписать его/ее транзакцию на специальном считывателе внеполосного EMV CAP с вставленной карточкой пользователя EMV Chip. Пользователю предлагается ввести определенные коды и значения на считывателе , подтверждающие сумму валюты, подлежащую передаче, и учетную запись - .

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

Что-то думать о том, когда дело доходит до подписей о транзакциях - , демонстрируя необходимость сохранения всего процесса с ПК (в этом случае ) и на другом канале целиком.

Можете ли вы объяснить, как можно «разместить iframe поверх браузера пользователя» и как технически предотвратить такое мошенничество?

Answer 1

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

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

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

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

После того, как все решения происходят на защищенном устройстве, включая сумму для передачи и пользователя проверяемого назначения, проблему ненадежного посредника (ваш ПК как человек в середине) решаются и сделка безопасна ,

Хотя эта информация не включает в себя цель сделки, поэтому вы все равно можете представить себе атаку, когда реселлер изменил фактические предметы, которые вы покупали в определенном магазине, без изменения стоимости!

Answer 2

Это образец атаки XSS (межсайтовый скрипт).

Скажите, например, Friendster, у которого было много отверстий XSS до, особенно на странице профиля. Я могу вставить скрипт на страницу моего профиля и сделать мою страницу похожей на страницу входа.

Как только другой пользователь просматривает мой профиль, он выглядит как страница входа Friendster! Затем пользователь вводит свое имя пользователя и пароль , не зная, что это была страница мошенничества. Введенные значения будут перенаправлены на мой сервер для хранения, а пользователь перенаправляется на фактическую страницу.

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

---

Чтобы предотвратить это, вы не должны разрешать произвольный HTML-код, а также скрипты, чтобы пройти через ваш сайт. Есть много точек входа для атаки, обычно это поля ввода, которые не имеют тщательной проверки. Места SSL, связанные с SSL, небезопасны, если на странице существует сценарий с инъекциями.