Что нужно знать разработчику PHP о соединениях на уровне https / безопасных сокетов?
Я почти ничего не знаю, когда дело доходит до того, как и почему https-соединения. Очевидно, что когда я передаю защищенные данные, такие как пароли или особенно информацию о кредитной карте, https является важным инструментом. Но что мне нужно об этом знать? Какие наиболее частые ошибки вы видите, когда разработчики внедряют это в свои проекты? Бывают ли случаи, когда https - плохая идея? Спасибо!
Ответы 6
Убедитесь, что на странице HTTPS все элементы на странице поступают с адреса HTTPS. Это означает, что элементы должны иметь относительные пути (например, «/images/banner.jpg»), чтобы протокол унаследовался, или что вам нужно выполнить проверку на каждой странице, чтобы найти протокол, и использовать это для всех элементов.
NB: это включает в себя все внешние ресурсы (например, файлы JavaScript Google Analytics)!
Единственный недостаток, о котором я могу думать, это то, что он увеличивает (почти незначительно) время обработки для браузера и вашего сервера. Я бы посоветовал шифровать только те переводы, которые должны быть.
Код Google Analytics самостоятельно определяет HTTPS и обслуживает его с защищенного сервера. У них это уже больше года, и пользователи, использующие старый код, могут обновиться, когда захотят.
Эй, спасибо за это. Я не знал. Думаю, мне стоит почаще читать их блог ;-)
Разве это не противоречит цели защиты страниц, если вы собираетесь пропускать контент из сторонних источников. Особенно в случае файлов Javascript (например, Google Analytics), которые потенциально могут действовать как кейлоггеры и отправлять защищенную информацию третьей стороне?
Я бы посоветовал в любое время, когда пользовательские данные любой хранятся в базе данных и передаются, использовать https. Учитывайте это требование, даже если пользовательские данные являются обыденными, потому что даже многие из этих обыденных деталей используются этим пользователем для идентификации себя на других веб-сайтах. Обдумайте все случайные вопросы безопасности, которые задает вам банк (например, на какой улице вы живете?). Его очень легко взять из полей адреса. В этом случае данные - это не то, что вы считаете паролем, но это вполне может быть. Кроме того, вы никогда не сможете предугадать, какие данные пользователя будут использоваться для контрольного вопроса где-либо еще. Вы также можете ожидать, что с учетом интеллекта среднего пользователя сети (подумайте о своей бабушке), этот лакомый кусок информации может составить часть пароля этого пользователя где-то еще.
Один указатель, если вы используете https
сделайте так, чтобы если пользователь вводил http://www.website-that-needs-https.com/etc/yadda.php они будут автоматически перенаправлены на https://www.website-that-needs-https.com/etc/yadda.php (личное раздражение)
Однако, если вы просто делаете простую веб-страницу в формате html, это будет по сути односторонней передачей информации с сервера пользователю, не беспокойтесь об этом.
Я бы сказал, что самые распространенные ошибки при работе с сайтом с поддержкой SSL:
- Сайт ошибочно перенаправляет пользователей на http со страницы как https
- Сайт не переключается на https автоматически, когда это необходимо
- Изображения и другие ресурсы на странице https загружаются через http, что вызовет предупреждение системы безопасности в браузере. Убедитесь, что все ресурсы используют полностью определенные URI, которые указывают https.
- Сертификат безопасности работает только для одного поддомена (например, www), но на самом деле ваш сайт использует несколько поддоменов. Не забудьте получить групповой сертификат, если он вам понадобится.
Здесь все очень хорошие советы ... но я просто хочу кое-что добавить ...
Я видел некоторые сайты, которые предоставляют вам страницу входа http и перенаправляют вас на https только после того, как вы публикуете свое имя пользователя / пароль. Это означает, что имя пользователя передается в открытом виде до того, как будет установлено https-соединение.
Короче говоря, создайте страницу, на которой вы входите в систему с ssl, вместо публикации на странице ssl.
Я не собираюсь вдаваться в подробности SSL в целом, gregmac отлично справился с этим, см. Ниже ;-).
Однако некоторые из наиболее распространенных (и критических) ошибок (не в особенности PHP) при использовании SSL / TLS:
- Разрешение HTTP, когда вы должны принудительно использовать HTTPS
- Получение некоторых ресурсов через HTTP со страницы HTTPS (например, изображений, IFRAME и т. д.)
Непреднамеренное перенаправление на страницу HTTP со страницы HTTPS - обратите внимание, что это включает в себя «поддельные» страницы, такие как «about: blank» (я видел, что это используется как заполнители IFRAME), при этом будет ненужным и неприятным всплывающим предупреждением.
Веб-сервер, настроенный для поддержки старых небезопасных версий SSL (например, SSL v2 широко распространен, но ужасно сломан) (ладно, это не совсем проблема программиста, но иногда никто другой не справится с этим ...)
Веб-сервер, настроенный для поддержки небезопасных наборов шифров (я видел только используемые NULL-шифры, которые в основном не обеспечивают абсолютно НИКАКОГО шифрования) (то же самое)
Самозаверяющие сертификаты - не позволяют пользователям проверять личность сайта.
Запрос учетных данных пользователя со страницы HTTP, даже при отправке на страницу HTTPS. Опять же, это не позволяет пользователю проверить идентичность сервера ДО того, как сообщить ему свой пароль ... Даже если пароль передается в зашифрованном виде, пользователь не имеет возможности узнать, находится ли он на поддельном сайте - или даже БУДЕТ ли он зашифрован.
Небезопасный cookie - файлы cookie, связанные с безопасностью (такие как sessionId, токен аутентификации, токен доступа и т. д.). ДОЛЖЕН должен быть установлен с установленным атрибутом «secure». Это важно! Если он не настроен на безопасность, файл cookie безопасности, например SessionId может быть передан по HTTP (!) - и злоумышленники могут гарантировать, что это произойдет - и, таким образом, разрешить захват сеанса и т. д. Пока вы на нем (хотя это напрямую не связано), установите атрибут HttpOnly для ваших файлов cookie. (помогает смягчить некоторые XSS-атаки).
Чрезмерно разрешающие сертификаты - скажем, у вас есть несколько поддоменов, но не все из них находятся на одном уровне доверия. Например, у вас есть www.yourdomain.com, dowload.yourdomain.com и publicaccess.yourdomain.com. Так что вы можете подумать о том, чтобы использовать групповой сертификат .... НО у вас также есть secure.yourdomain.com или financial.yourdomain.com - даже на другом сервере. publicaccess.yourdomain.com сможет выдавать себя за secure.yourdomain.com .... Хотя могут быть случаи, когда это нормально, обычно вам нужно какое-то разделение привилегий ...
Это все, что я сейчас припомню, возможно, потом отредактирую ...
Что касается того, когда использование SSL / TLS является ПЛОХОЙ идеей - если у вас есть общедоступная информация, которая НЕ предназначена для конкретной аудитории (либо для одного пользователя, либо для зарегистрированных участников), И вы не особо заинтересованы в том, чтобы они получали ее специально из правильный источник (например, значения биржевых тикеров ДОЛЖНЫ поступать из аутентифицированного источника ...) - тогда нет реальной причины нести накладные расходы (и не только производительность ... dev / test / cert / etc).
Однако, если у вас есть общие ресурсы (например, один и тот же сервер) между вашим сайтом и другим БОЛЕЕ ЧУВСТВИТЕЛЬНЫМ сайтом, тогда более чувствительный сайт должен устанавливать здесь правила.
Кроме того, пароли (и другие учетные данные), информация о кредитной карте и т. д. ВСЕГДА должны передаваться через SSL / TLS.
Я обнаружил, что попытка применить <link> к несуществующей таблице стилей также вызвала предупреждения системы безопасности. Когда я использовал правильный путь, появился значок замка.
В дополнение к приведенному ниже, вы должны использовать Wireshark, чтобы просмотреть простой запрос / ответ HTTPS, просто чтобы увидеть его «в действии». И из приведенных ниже ответов подразумевается, что вы понимаете криптографию с открытым ключом (на высоком уровне).