SSL: как сбалансировать производительность API с безопасностью? - PullRequest
1 голос
/ 18 ноября 2010

API с ужасной безопасностью - обычное дело. Показательный пример - эта история на TechCrunch.

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

Ответы [ 3 ]

2 голосов
/ 18 ноября 2010

Если вы разрешите смешанный контент, то человек-посредник может переписать смешанный контент, чтобы внедрить JS для кражи конфиденциальной информации, уже находящейся на странице.С кафе и т.п., предоставляющими бесплатный беспроводной доступ, атаки «человек посередине» не так уж и сложны.

https://www.eff.org/pages/how-deploy-https-correctly дает хорошее объяснение:

При размещении приложения через HTTPS не может быть смешанного контента;то есть весь контент на странице должен быть выбран через HTTPS.Часто встречается частичная поддержка HTTPS на сайтах, на которых главные страницы выбираются через HTTPS, но некоторые или все медиа-элементы, таблицы стилей и JavaScript на странице выбираются через HTTP.

Это небезопаснопотому что, хотя загрузка главной страницы защищена от активной и пассивной сетевой атаки, ни один из других ресурсов не защищен.Если страница загружает какой-либо код JavaScript или CSS через HTTP, злоумышленник может предоставить ложный файл вредоносного кода и получить DOM страницы после загрузки.Тогда пользователь вернется в ситуацию отсутствия безопасности.Вот почему все основные браузеры предупреждают пользователей о страницах, которые загружают смешанный контент.Также небезопасно ссылаться на изображения по HTTP: что если злоумышленник поменял местами значки «Сохранить сообщение» и «Удалить сообщение» в приложении веб-почты?

Вы должны обслуживать весь домен приложения через HTTPS.Перенаправьте HTTP-запросы с HTTP 301 или 302 ответами на эквивалентный ресурс HTTPS.

1 голос
/ 18 ноября 2010

Проблема в том, что без понимания производительности вашего приложения просто неправильно пытаться оптимизировать приложение без метрик.Это то, что приводит к тому, что разработчики решили оставить API незашифрованным, просто думая, что он потратит еще 10 мс производительности.Проще говоря, лучший способ сбалансировать проблемы безопасности и производительности - это в первую очередь беспокоиться о безопасности, получить некоторую нагрузку от реальных клиентов (а не от того, что фигуры на доске просто одержимы каким-то архитектором), и получить реальные показатели из своего кода, когда вы подозреваете, что производительность может бытьвопрос.У меня странное чувство, что это не будет связано с безопасностью.

0 голосов
/ 21 ноября 2010

Вам нужно собрать некоторые свидетельства о предполагаемых проблемах производительности SSL до того, как вы прыгнете.Вы можете получить довольно сюрприз.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...