iFrame - это риск для безопасности, имеющий детали в URL?

Question

iFrame - это риск для безопасности, имеющий детали в URL?

0

компания, я не буду упоминать о желании заполнить iFrame URL-адресом, который будет содержать информацию о пользователе. Эта информация будет использоваться для предварительного заполнения формы в iFrame. Является ли это угрозой безопасности, поскольку детали могут быть просмотрены в источнике. Подробности - фамилия, адрес и т.д. Сайт использует SSL по всему... если это помогает

Здесь URL:

https://moomooooo/dd.ehtml?user_id=5876745
&fname=vghfhfh
&lname=fhfghf
&title=MR
&gender=M
&dateOfBirth=03
&monthOfBirth=10
&yearOfBirth=1946
&housenum=233
&street=fghfhfghfg
&town=fhfghfgh
&postcode=S5g%207r4
&yearsAtAddress=07
&[email protected]
&phone=447545555577540555721

Funky 29 нояб. 2013, в 15:03

Источник

0

Можете ли вы использовать POST вместо GET? Facebook использует POST для отправки информации о пользователях в iFrames. У них есть HTML-форма на внешней странице с target = "iframename", которая отправляется с помощью JavaScript при загрузке страницы.
Reeno 29 нояб. 2013, в 14:34

Теги:

html

security

iframe

2 ответа

Ещё вопросы

Можете ли вы использовать POST вместо GET? Facebook использует POST для отправки информации о пользователях в iFrames. У них есть HTML-форма на внешней странице с target = "iframename", которая отправляется с помощью JavaScript при загрузке страницы.

Flavien Volken · Answer 1 · 2013-11-29T11-18-00.000Z

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

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

Igarr · Answer 2 · 2013-11-29T13-38-00.000Z

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

Атаки, которые я попробовал бы, - это Cross Site scripting (выполнение JS-кода на машине-жертве), доступ к другой пользовательской информации, SQL Injection, SSL-шифрование и обнюхание трафика жертв, получающего эту информацию, просто чтобы назвать несколько.

Моя рекомендация заключается в том, что вы либо передаете ее в своей СЕССИИ каким-то образом, заполняете эти поля в базе данных, чтобы вы обращались к ним через хэш или, по крайней мере, передавали ее через POST.

Передача через POST не обеспечивает магической защиты от внедрения XSS и SQL.
Конечно, он не защищает от XSS и SQL-инъекций, я этого не говорил. Вот почему я сказал "по крайней мере"