Что разработчик PHP должен знать о https / соединения уровня защищенных сокетов?
Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:
- Вызов метода экземпляра объекта
null. - Доступ или изменение поля объекта
null. - Принимая длину
null, как если бы это был массив. - Доступ или изменение слотов
null, как если бы это был массив. - Бросок
nullкак будто это было значение Throwable.
Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null.
Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
7 ответов
HTTPS или сертификат Уровня защищенных сокетов (SSL) подается для сайта и обычно подписывается Центром сертификации (CA), который является эффективно доверяемой третьей стороной, которая проверяет некоторые основные детали о Вашем сайте и сертифицирует это для использования в браузерах. Если Ваш браузер доверяет CA, то он доверяет любым сертификатам, подписанным тем, что CA (это известно как доверительная цепочка).
Каждый HTTP (или HTTPS) запрос состоит из двух частей: запрос и ответ. Когда Вы запрашиваете что-то через HTTPS, существует на самом деле несколько вещей, происходящих в фоновом режиме:
- Клиент (браузер) делает "квитирование", где он запрашивает открытый ключ и идентификацию сервера.
- На данном этапе браузер может проверить на законность (название сайта соответствует? действительно ли диапазон дат является текущим? это подписывается CA, которому это доверяет?). Это может даже связаться с CA и удостовериться, что сертификат действителен.
- Клиент создает новый предосновной секрет, который шифруется с помощью открытого ключа серверов (поэтому, только сервер может дешифровать его), и отправленный на сервер
- Сервер и клиент оба использования этот предосновной секрет для генерации основного секрета, который затем используется для создания симметричного сеансового ключа для фактического обмена данными
- Обе стороны отправляют сообщение, говоря, что они сделаны квитирование
- Сервер затем обрабатывает запрос обычно и затем шифрует ответ с помощью сеансового ключа
Если соединение будет сохранено открытым, то тот же симметричный ключ будет использоваться для каждого.
Если новое соединение устанавливается, и обе стороны все еще имеют основные секретные, новые сеансовые ключи, может быть сгенерирован в 'сокращенном квитировании'. Обычно браузер сохранит основной секрет, пока он не будет закрыт, в то время как сервер сохранит его в течение нескольких минут или нескольких часов (в зависимости от конфигурации).
Для больше на продолжительности сессий видят, Сколько времени симметричный ключ HTTPS длится?
Сертификаты и имена хостов
Сертификатам присваивают Общее название (CN), которое для HTTPS является доменным именем. CN должен соответствовать точно, например, сертификат с CN "example.com" НЕ будет соответствовать домену "www.example.com", и пользователи получат предупреждение в своем браузере.
Перед SNI не было возможно разместить несколько доменных имен на одном IP. Поскольку сертификат выбирается, прежде чем клиент даже отправляет фактический Запрос HTTP, и Запрос HTTP содержит Хост: строка заголовка, которая говорит сервер, что URL использовать, нет никакого пути к серверу для знания что сертификату служить для данного запроса. SNI добавляет имя хоста к части квитирования TLS, и поэтому, пока она поддерживается и на клиенте и сервере (и в 2015, она широко поддерживается), затем, сервер может выбрать корректный сертификат.
Даже без SNI, один способ служить нескольким именам хостов с сертификатами, которые включают Подчиненные Альтернативные Имена (SAN), которые являются чрезвычайно дополнительными доменами, для которых сертификат действителен. Google использует единственный сертификат для обеспечения многих из, его - сайты, например.
Иначе должен использовать Wildcard-сертификаты. Возможно получить сертификат как ".example.com", в этом случае, "www.example.com" и "foo.example.com" оба будут действительны для того сертификата. Однако обратите внимание, что "example.com" не соответствует ".example.com", и ни один не делает "foo.bar.example.com". При использовании "www.example.com" для сертификата необходимо перенаправить любого по "example.com" к "www". сайт. Если они запрашивают https://example.com, если Вы не размещаете его на отдельном IP и имеете два сертификата, желание получают ошибку сертификата.
Конечно, можно смешать и подстановочный знак и SAN (как долго, поскольку CA позволяет Вам сделать это), и получите сертификат и для "example.com" и с SAN ".example.com", "example.net" и ".example.net", например.
Формы
Строго говоря при представлении формы не имеет значения, если сама страница формы не шифруется, пока отправлять URL переходит к https://URL. В действительности пользователи были обучены (по крайней мере, в теории) не отправить страницы, если они не видят небольшой "значок блокировки", поэтому даже сама форма должна быть подана через HTTPS для получения этого.
Трафик и загрузка сервера
Трафик HTTPS намного больше, чем его эквивалентный Трафик HTTP (из-за шифрования и сертификата наверху), и это также помещает большую деформацию на сервер (шифрование и дешифрование). Если у Вас есть загруженный в большой степени сервер, может быть желательно быть очень выборочным о том, какое содержание подается с помощью HTTPS.
Лучшие практики
Если Вы только используете HTTPS для всего сайта, он должен автоматически перенаправить к HTTPS как требуется. Каждый раз, когда пользователь зарегистрирован, они должны использовать HTTPS, и если Вы используете сеансовые куки, cookie должен иметь безопасный набор флага. Это предотвращает перехват сеансовых куки, которые особенно важны, учитывая популярность открытых (незашифрованных) сетей Wi-Fi.
Любые ресурсы на странице должны прибыть из той же схемы, используемой для страницы. При попытке выбрать изображения из http://, когда страница будет загружена HTTPS, пользователь получит предупреждения системы безопасности. Необходимо или использовать полностью определенные URL, или другой простой способ состоит в том, чтобы использовать абсолютные URL, которые не включают имя хоста (например, src = "/images/foo.png"), потому что они работают на обоих.
- Это включает внешние ресурсы (например, Google Analytics)
Не делайте СООБЩЕНИЙ (форма отправляет) при изменении от HTTPS до HTTP. Большинство браузеров отметит это как предупреждение системы безопасности.
Я сказал бы, что наиболее распространенные ошибки при работе с поддерживающим SSL сайтом
- Сайт ошибочно перенаправляет пользователей к http от страницы как https
- Сайт автоматически не переключается на https, когда это необходимо
- Изображения и другие активы на https странице являются загрузкой через http, который инициирует предупреждение системы безопасности от браузера. Удостоверьтесь, что все активы используют полностью определенные URIs, которые указывают https.
- Сертификат безопасности только работает на один субдомен (такой как www), но Ваш сайт на самом деле использует несколько субдоменов. Удостоверьтесь, что получили Wildcard-сертификат при необходимости в нем.
Убедитесь это, когда на странице HTTPS, все элементы на странице прибудут из адреса HTTPS. Это означает, что элементы должны иметь относительные пути (например, "/images/banner.jpg") так, чтобы протокол был наследован, или что необходимо сделать проверку на каждой странице для нахождения протокола и использования это для всех элементов.
NB: Это включает все внешние ресурсы (как Google Analytics файлы JavaScript)!
Единственная оборотная сторона, о которой я могу думать, - то, что это добавляет (почти незначительный) время обработки для браузера и Вашего сервера. Я предложил бы шифровать только передачи, которые должны быть.
Я не собираюсь идти подробно на SSL в целом, gregmac сделали отличную работу на этом, видят ниже ;-).
Однако некоторые наиболее распространенные (и очень важный) сделанные ошибки (не конкретно PHP) относительно использования SSL/TLS:
- Разрешение HTTP, когда необходимо осуществлять HTTPS
- Получая некоторые ресурсы по HTTP от страницы HTTPS (например, изображения, IFRAMEs, и т.д.)
Направление к странице HTTP от страницы HTTPS неумышленно - отмечает, что это включает "поддельные" страницы, такие как "about:blank" (я видел используемый в качестве заполнителей IFRAME), это напрасно и неприятно откроет предупреждение.
Веб-сервер, настроенный для поддержки старых, небезопасных версий SSL (например, SSL v2 распространено, все же ужасно поврежденный) (хорошо, это не точно проблема программиста, но иногда никто еще, обработает ее...),
Веб-сервер настроил для поддержки небезопасных наборов шифров (я видел ПУСТЫЕ шифры, только используемые, который в основном не обеспечивает абсолютно никакого шифрования) (так же)
Самоподписанные сертификаты - препятствуют тому, чтобы пользователи проверили идентификационные данные сайта.
Запрос учетных данных пользователя от страницы HTTP, даже если, отправляя странице HTTPS. Снова, это препятствует тому, чтобы пользователь проверил идентификационные данные сервера ПРЕЖДЕ, ЧЕМ дать ему его пароль... Даже если пароль передается зашифрованный, у пользователя нет способа знать, находится ли он на поддельном сайте - или даже если он будет зашифрован.
Незащищенный cookie - связанные с безопасностью cookie (такие как sessionId, аутентификационный маркер, маркер доступа, и т.д.) ДОЛЖНЫ быть установлены с "безопасным" набором атрибута. Это важно! Если это не установлено защитить, cookie безопасности, например, SessionId, может быть передан по HTTP (!) - и взломщики могут удостовериться, что это произойдет - и таким образом позволяющий перехват сеанса и т.д. В то время как Вы в нем (tho, это непосредственно не связано), установите атрибут HttpOnly на своих cookie, также (помогает смягчить некоторый XSS).
В чрезмерно разрешающих сертификатах - говорится, что у Вас есть несколько субдоменов, но не все они на том же доверительном уровне. Например, у Вас есть www.yourdomain.com, dowload.yourdomain.com и publicaccess.yourdomain.com. Таким образом, Вы могли бы думать о движении с Wildcard-сертификатом.... НО у Вас также есть secure.yourdomain.com или finance.yourdomain.com - даже на другом сервере. publicaccess.yourdomain.com затем сможет явиться олицетворением secure.yourdomain.com.... В то время как могут быть экземпляры, где это хорошо, обычно Вы хотели бы некоторое разделение полномочий...
Это - все, что я могу помнить прямо сейчас, мог бы переиздать его позже...
До, когда это ПЛОХАЯ идея использовать SSL/TLS - если у Вас есть общедоступная информация, которая НЕ предназначается для определенной аудитории (или отдельный пользователь или зарегистрированные члены), И Вы не следите за ними получающий ее конкретно из надлежащего источника (например, значения тикера запаса ДОЛЖНЫ прибыть из аутентифицируемого источника...) - затем нет никакой настоящей причины для несения издержек (и не просто производительность... dev/test/cert/etc).
Однако, если у Вас есть совместно используемые ресурсы (например, тот же сервер) между Вашим сайтом и другим БОЛЕЕ ЧУВСТВИТЕЛЬНЫМ сайтом, затем более чувствительный сайт должен устанавливать правила здесь.
Кроме того, пароли (и другие учетные данные), информация о кредитной карте, и т.д. должны ВСЕГДА быть по SSL/TLS.
Я предложил бы любое время, любые пользовательские данные хранятся в базе данных и передаются, используйте https. Рассмотрите это требование, даже если пользовательские данные являются приземленными, потому что даже многие из этих приземленных деталей используются тем пользователем для идентификации на других веб-сайтах. Полагайте, что вся случайная безопасность опрашивает Ваш банк, спрашиваете Вы (как то, на какой улице Вы живете?). Это может быть взято от полей адреса действительно легко. В этом случае данные не то, что Вы рассматриваете паролем, но это могло бы также быть. Кроме того, Вы никогда не можете ожидать, какие пользовательские данные будут использоваться для вопроса о безопасности в другом месте. Можно также ожидать, что с интеллектом среднего интернет-пользователя (думают бабушка), что тот лакомый кусочек информации мог бы составить часть пароля того пользователя где-то в другом месте.
Один указатель, если Вы используете https
сделайте его так, чтобы, если пользователь вводит http://www.website-that-needs-https.com/etc/yadda.php, они были автоматически перенаправлены к https://www.website-that-needs-https.com/etc/yadda.php (персональный главный объект неприязни)
Однако, если Вы просто делаете простую веб-страницу HTML, которая будет по существу односторонней передачей информации от сервера до пользователя, не волнуйтесь об этом.
Я нашел ту попытку к <link> к несуществующей таблице стилей также вызвал предупреждения системы безопасности. Когда я использовал корректный путь, значок блокировки появился.
Весь очень хороший совет здесь..., но я просто хочу добавить что-то..
Я видел некоторые сайты, который дает Вам http страницу входа в систему, и только перенаправьте Вас к https после регистрации имени пользователя/передачи.. Это означает, что имя пользователя передается в ясном, прежде чем подключение HTTPS будет установлено..
Короче говоря сделайте страницу, где Вы входите в систему от ssl, вместо того, чтобы отправить на ssl страницу.