100% SSL или выборочный SSL, JSONP и без ошибок?

Я хотел бы предложить ваше взвешенное мнение, чтобы помочь мне выбрать между следующими двумя политиками происхождения для моего приложения Ajax:

  1. Загрузить все мои активы с HTTPS: //www.mydomain.com
    2. Plus: Ajax is easy. No problems with Same Origin Policy.
    Plus: PUT method offers large payloads.
    Plus: Network error messages can be fed back to the user.
    Minus: Server needs to sweat more to encrypt all that dross that makes up a web site. Browser needs to sweat more decrypting it all. Overall slower user experience.
  2. Загрузите большую часть мусора через HTTP: //www.mydomain.com и используйте HTTPS: //www.mydomain.com только для обмена конфиденциальными данными.
    3. Plus: Faster user experience as browser and, more importantly, my server do less cryptography. Plus: Ajax still easy via JSONP work-around to SOP (*).
    Minus: GET method on JSONP limits payload to 2K - may become an issue.
    BIG Minus: Cannot find any way to grab status response from header following network errors (of whatever kind). User information cannot extend beyond "My bad".

Есть предположения?

(*) Кстати, я был бы очень признателен, если бы кто-нибудь мог дать мне пример уязвимости системы безопасности, вызванной переключением протокола в том же домене. Я так понимаю, что это разные сервера, ну и что? Они в моем домене. Я их контролирую. Я не понимаю беспокойства.


ssl ajax jsonp
person Ollie2893    schedule 31.08.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

Отсутствие необходимости использовать JSONP, возможность использовать HTTP PUT и все другие преимущества, которые вы описали, стоят больше, чем несколько циклов процессора в моей книге.

person easel    schedule 31.08.2010
comment
Спасибо, что восстановили для меня эти ссылки. Был один интересный комментарий по поводу кеширования сеансов SSL и того, что сервер SSL с большим количеством клиентов требует огромного количества памяти. Но я полагаю, что выборочный SSL совсем не помогает. Поскольку мне иногда нужен SSL, у меня все равно будет этот кеш. И я заплачу самую высокую цену за первое рукопожатие. - person Ollie2893; 31.08.2010

arrow_upward
1
arrow_downward

Что касается уязвимости, я привел примеры в другой ответ:

Кажется нежелательным поддерживать сеанс между HTTP и HTTPS с использованием одного и того же файла cookie или токена URL.

Представьте себе случай, когда вы вошли в систему с заданным файлом cookie (или токеном URL), передаваемым туда и обратно для каждого запроса / ответа на веб-сайте электронной коммерции. Если кто-то посередине может прочитать этот файл cookie, он может затем войти с ним в HTTP- или HTTPS-вариант сайта. Даже если все, что делает законный пользователь, происходит через HTTPS, злоумышленник все равно сможет получить доступ к этому сеансу (потому что у него тоже будет законный файл cookie). Он мог видеть такие страницы, как тележка, способ оплаты, возможно, изменить адрес доставки.

Имеет смысл передавать некоторую форму токена между сеансом HTTP и сеансом HTTPS (если вы используете сеансы), но рассмотрение их как одного и того же может вызвать некоторую уязвимость. Решением может быть создание одноразового токена в параметре запроса только для перехода. Однако вы должны рассматривать их как два отдельных аутентифицированных сеанса.

Эта уязвимость может иногда возникать с веб-сайтами, которые используют смешанный контент HTTP и HTTPS (некоторые браузеры, такие как Firefox, выдают предупреждение, когда это происходит, хотя большинство людей склонны отключать его при первом появлении). У вас может быть файл cookie сеанса HTTPS для главной страницы, но эта страница содержит изображения для логотипа компании через простой HTTP. К сожалению, браузер отправит cookie для обоих (так что тогда злоумышленник сможет использовать cookie). Я видел, как это происходило, даже если изображения, о котором идет речь, даже не было (браузер отправит запрос с файлом cookie на сервер, даже если он вернет 404 not found).

Что касается накладных расходов на использование SSL / TLS, эта статья от инженеров Google должен представлять интерес, в частности:

SSL / TLS больше не требует больших вычислительных затрат.

person Bruno    schedule 31.08.2010
comment
Спасибо, Бруно, но я не согласен: я создаю свой HTTPS PHPSESSID с secure = true и, таким образом, полностью избегаю проблемы (случайной передачи этого идентификатора в виде обычного текста) (браузер отправляет cookie только через HTTPS). Так что нет, я все еще не вижу уязвимости. Я использую HTTP только для несессионных дроссов. Украшения и др. - person Ollie2893; 31.08.2010
comment
Просто прочтите материалы Google. Это отличная работа. Сделал закладку. Большое спасибо. - person Ollie2893; 31.08.2010
comment
Действительно, проблема заключается в небезопасных файлах cookie. В принципе, ничего страшного, если вам не требуется авторизация для HTTP-трафика. Тогда pb со смешанным содержимым заключается в том, что пользователю трудно узнать, какие элементы передаются безопасно. Вы не можете ожидать, что пользователи будут просматривать исходный код и проверять, что находится над HTTPS или нет, и что должно быть. Если сайт спроектирован правильно, как вы предлагаете, все должно быть в порядке, но браузеру трудно обнаружить это и выдать соответствующее предупреждение пользователю. К сожалению, на многих веб-сайтах предупреждение о смешанном содержании отражает реальную проблему. - person Bruno; 31.08.2010
comment
Сейчас я переключил все свои данные на HTTPS, и сначала я был сбит с толку, когда FF опубликовал смешанное предупреждение. Затем я понял, что делаю мэшап Google, полученный из HTTP. В этот момент у меня в среднем 100 миллионов Джо: черт возьми, все равно загружай - и больше не спрашивай. В любом случае, для меня это ирония: несомненно, загрузка какого-либо файла .js от неизвестной третьей стороны (одобрено FF) более опасна, чем выполнение запроса Ajax от HTTP: // mydomain на HTTPS: // mydomain (для чего угодно - FF не устраивает). Я считаю, что СОП слишком строгий по отношению к изменениям протокола ... - person Ollie2893; 31.08.2010