Принудительное HTTPS для определенного URL-адреса
Это должно быть быстрым … вот мой текущий файл .htaccess:
# BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress
Что мне нужно сделать, так это убедиться, что если http://www.mydomain.com/cart/
будет достигнуто, ему нужно заставить HTTPS … так /cart/
и что-нибудь внутри /cart/
- Использование сертификатов клиент / сервер для двухсторонней аутентификации SSL-сокета на Android
- Запретить Google Chrome «Ваше подключение не является частным» для конкретного адреса?
- Как исправить ошибку «java.security.cert.CertificateException: нет альтернативных имен объектов»?
- SSL / TLS vs SSL / TLS-VPN
- javax.net.ssl.SSLHandshakeException: удаленное подключение к удаленному хосту во время рукопожатия во время веб-службы Communicaiton
- Что происходит на проводе при настройке соединения TLS / LDAP или TLS / HTTP?
- Как загрузить файл PKCS # 12 в OpenSSL программно?
- SSL, Tomcat и Grails
- Поддержка Android SSL - SNI
- прием HTTPS-соединений с самозаверяющими сертификатами
- Как установить ключ CA (самоподписанный SSL) на ubuntu?
- Как включить поддержку TLS 1.2 в Android-приложении (работает на Android 4.1 JB)
- Последствия безопасности отключения CURLOPT_SSL_VERIFYHOST (libcurl / openssl)
После того как запрос был отправлен на http://www.mydomain.com/cart/
, если в запросе есть какие-либо конфиденциальные данные, слишком поздно. Заставьте его сломаться! По крайней мере, это даст вам указание, что с вашими ссылками что-то не так. Подробнее в предыдущих ответах:
[…] к моменту поступления запроса на сервер, слишком поздно. Если есть MITM, он совершил свою атаку (или ее часть), прежде чем вы получите запрос.
Лучшее, что вы можете сделать к тому времени, – ответить без какого-либо полезного контента. В этом случае может потребоваться redirect (с использованием 301 или 302 и заголовка местоположения). Тем не менее, это может скрыть проблемы, если пользователь (или даже вы как разработчик) игнорирует предупреждения (в этом случае браузер будет следовать перенаправлению и будет пробовать запрос почти прозрачно).
Поэтому я бы просто предложил вернуть статус 404:
http://yoursite/
иhttps://yoursite/
фактически два разных сайта. Нет причин ожидать отображения 1: 1 всех ресурсов из пространств URI от одного к другому (точно так же, как вы могли бы иметь совершенно другую иерархию дляftp://yoursite/
).- Что еще более важно, это проблема, которую следует рассматривать вверх по течению: ссылка, которая привела пользователя к этому ресурсу с использованием
http://
должна считаться нарушенной. Не заставляйте его работать автоматически. Наличие статуса 404 для ресурса, который не должен быть там, прекрасен. Кроме того, возврат сообщения об ошибке при наличии ошибки является хорошим: он заставит вас (или, по крайней мере, напомнить вам), как разработчика, что вам нужно исправить страницу / форму / ссылку, которые привели к этой проблеме.
EDIT: (Пример)
Допустим, у вас есть http://example.com/
, незащищенный раздел вашего сайта, который позволяет пользователю просматривать элементы. На этом этапе они не вошли в систему, так что это нормально, если вы просто используете HTTP.
Теперь, это время тележки / оплаты. Вы хотите HTTPS. Вы отправляете пользователя на https://example.com/cart/
. Если одна из ссылок, которая отправляет пользователя в корзину, использует простой HTTP (т. http://example.com/cart/
), это ошибка разработки. Его просто не должно быть. Прерывание процесса, когда вы считаете, что вас отправят на https://example.com/cart/
позволяет разработчику его видеть (и, как только исправлено, у пользователя никогда не будет проблемы).
Если речь идет только о разделе HTTPS вашего сайта (как правило, HTTP GET через ссылку где-то), это не обязательно такой большой риск.
Когда автоматические переадресации становятся еще более опасными, это когда они скрывают большие проблемы.
Например, вы находитесь на https://example.com/cart/creditcarddetails
и вы заполнили некоторую информацию, которая должна действительно просто оставаться за SSL. Однако разработчик допустил ошибку, и в форме используется простая ссылка http://
. Кроме того, разработчик (в конце концов, пользователь / человек) нажал «не показывать мне это сообщение снова» в Firefox, когда он говорит «Предупреждение: вы переходите с защищенной страницы на незащищенную страницу» ( Кстати, к сожалению, Firefox предупреждает апостериор: он уже сделал небезопасный запрос к тому времени, когда он покажет пользователю это сообщение). Теперь этот запрос GET / POST с конфиденциальными данными сначала отправляется на эту неправильную http://
ссылку http://
и автоматическая перезапись говорит браузеру повторить запрос по https://
. Это выглядит хорошо, потому что, насколько это касается пользователя, все это произошло за долю секунды. Однако это не так: конфиденциальные данные были отправлены ясно.
Создание простой HTTP-секции того, что должно быть только над HTTPS, не делает ничего полезного, помогает вам лучше понять, что не так. Поскольку пользователи никогда не должны заканчиваться там, если ссылки правильно реализованы, для них это не проблема.
Попробуйте добавить это перед другими правилами (но после RewriteBase):
RewriteCond %{HTTPS} off RewriteRule ^cart/(.*)$ https://www.mydomain.com/cart/$1 [R,L]