2011-12-17 4 views
4

Насколько безопасна эта настройка?XMLHttpRequest через SSL с незащищенной страницы

небезопасная страница 'http://www.site.com' делает XMLHttpRequest с POST в URL 'https://www.site.com/dosomething.asp'

страницы dosomething.asp имеет заголовок 'Access-Control-Allow-Origin: http://www.site.com' устанавливает и возвращает некоторые данные, относящиеся к пользователю, которые должны быть безопасными.

Ошибок нет, все идет хорошо.

Насколько безопасен фактический запрос POST? Насколько защищен ответ от этого запроса?

+3

Как только вы вводите в приложение не-SSL-компонент, вы потеряли все преимущества SSL. Вы настолько же безопасны, как и самая слабая часть. Вот почему браузеры сообщают о смешанном содержимом SSL/non-SSL в качестве предупреждения безопасности для пользователя. – Cheekysoft

ответ

4

Самая существенная проблема, которую я вижу, заключается в том, что ваша незащищенная страница небезопасна (хорошо, очевидно). Если кто-то попытался атаковать «человек в середине» на этой незащищенной странице, они могли бы отредактировать функциональность страницы (с помощью инъекции JavaScript и т. Д.), Чтобы перехватить контент, отправляемый и полученный с защищенного URL. Лучше всего использовать обе страницы в безопасном режиме (SSL/TLS).

+0

Хорошо, вот моя идея. Возможно, я мертв. Предположим, что небезопасная страница имеет два имени пользователя и пароль формы. Подключение к dosomething.asp производится только через SSL и если responseText является безопасным ... чем это было бы недостаточно безопасно для удовлетворения основных требований конфиденциальности? – user980261

+0

Не в приложении, за разработку которого я буду отвечать. Ваш подход защитит данные от «любопытных глаз» по сети, но, как я ускользнул выше, не обеспечив исходную страницу, вы оставите открытые пути для кого-то, чтобы более легко использовать, чтобы перехватить как запрос, так и ответ. Если у вас нет по-настоящему уважительной причины, я бы настоятельно рекомендовал только безопасность обеих страниц. Это также обеспечит дополнительную уверенность в ваших пользователях, поскольку веб-браузер будет отображаться как в «защищенном режиме», когда пользователь действительно вводит свои данные. – ziesemer

+0

Хорошо, и что можно сделать ...для обеспечения наиболее неотложных проблем с этой настройкой ... если эта настройка не может быть изменена по какой-либо причине? и «безопасный режим» браузера не имеет никакого значения, чтобы показывать пользователям ... в этом случае. – user980261

2

Как только вы вводите в приложение компонент, отличный от SSL, вы потеряли все преимущества SSL. Вы настолько же безопасны, как и самая слабая часть. Вот почему браузеры сообщают о смешанном содержимом SSL/non-SSL в качестве предупреждения безопасности для пользователя.

-2

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

фильтр, чтобы увидеть трафик с сайта источника будет:

(ip.src == [IP-адрес источника]) & & (ip.dst == [IP-адрес цели])

Смените ip.src и ip.dst, чтобы узнать, что вернется. Фактически вы могли бы объединить оба в одном выражении фильтра.

Это будет работать при условии, что вы находитесь в сети, через которую распространяются пакеты.

Один последний пункт: Вот описание ПКИ (HTTPS/SSL/TLS): http://www.mitre.org/news/the_edge/february_01/steve.html

Я Wiresharked своего рода подобной ситуации, и проверить, я отправки и получения TLS трафика (HTTPS). Но это была не такая ситуация, поэтому я не хочу спекулировать.

+0

Не знаете, что вы пытаетесь сказать здесь. Тот факт, что такой XHR будет отправлен через HTTPS, не означает, что вся настройка безопасна (см. Ответ @ ziesemer). Проблема довольно схожа с этим: http://stackoverflow.com/a/8893704/372643 – Bruno

+0

Wireshark позволит пользователю фактически увидеть, были ли данные зашифрованы с помощью TLS или нет. Wireshark немного привыкает, но это очень мощный инструмент для проверки сетевого трафика. У меня есть целевая страница https, с которой я отправляю учетные данные для входа. Все идет по https. Если посмотреть на сетевой трафик, то ясно, что данные шифруются TLS. Следовательно, это безопасно. – kermit

+0

Кроме того, я привык пытаться сделать все возможное из субоптимальных ситуаций. Возможно, плакат мог бы изучить шифрование AES: http://msdn.microsoft.com/en-us/magazine/cc164055.aspx - Я видел, что это хорошо использовалось в приложении, требующем безопасности передачи. – kermit

Смежные вопросы