Как я могу предотвратить доступ к файлам PHP, если вызывающий абонент не использует HTTPS?

Я написал несколько веб-сервисов PHP, где передаю аргументы по URL-адресу. Чтобы предотвратить несанкционированный доступ, я передаю уникальный ключ в качестве одного из аргументов. Я вызываю файл PHP через HTTPS, и мне интересно, есть ли способ предотвратить запуск скрипта, если HTTPS не используется.

Немного от темы, но если вы используете PHP с Apache Httpd и mod_ssl , вы можете принудительно установить SSL-доступ к файлам (и скриптам PHP), разместив директиву SSLRequireSSL в .htaccess или в конфигурации Directory.

 if(empty($_SERVER['HTTPS'])) { // .... exit; } 

Чтобы уточнить: вы хотите, чтобы клиент не вызывал URL-адрес, содержащий секретный токен, по незашифрованному соединению, верно? Если это так, то проблема в основном не с вами, а с браузером клиента. Вы можете перенаправить клиента на безопасное соединение, если он еще не использует его, но даже если вы это сделаете, клиент уже сделал небезопасный, перехваченный запрос на ваш сервер, прежде чем он будет перенаправлен!

Mozilla прилагает усилия для решения этой проблемы. Начиная с Firefox 4 сервер может отправить заголовок Strict-Transport-Security который впоследствии будет препятствовать незашифрованному доступу (хотя, очевидно, перед отправкой заголовка все равно может произойти незашифрованный доступ).

Дальнейшее чтение на hacks.mozilla.org

Если вы используете Apache, вы можете использовать mod_rewrite для перенаправления HTTP-запросов на HTTPS.

Например, это то, что мы используем:

 RewriteCond %{HTTPS} !=on RewriteRule ^account(.*) https://%{SERVER_NAME}/account$1 [R=301,L] 

Это перенаправляет http: // domain / account на https: // domain / account

Вы можете запретить серверу отвечать на незашифрованный запрос, но вы не можете помешать его отправке, что также плохо для безопасности паролей. И это не самая большая проблема с помещением секретного токена в URL-адрес: он остается в истории браузера, его можно увидеть в реферере, когда пользователь покидает ваш сайт, а любой веб-сайт, который пользователь посещает, силовой или словарной атаки через псевдослучайный CSS-сайт. В целом, это довольно ужасная идея – вам лучше использовать только файлы cookie, защищенные только SSL.