HTTPS: titkosított kapcsolat a webhelyeden

A HTTPS a weboldalak titkosított kommunikációs módja. A böngésződ és a webszerver között privát csatorna jön létre, ezért a legtöbb nagy webhely ezt használja. Ha egy oldal HTTPS-en fut, a böngésző címsorában egy kis lakat ikont látsz.

Miért érdemes HTTPS-t használni?

• Gyorsabb. Elsőre furcsa, de a HTTP számos sebességnövelő fejlesztése csak HTTPS-en érhető el, ezért a legtöbb látogatónak a webhelyed valójában gyorsabban töltődik be.
• Bizalom. A látogatók könnyebben bíznak egy védett oldalban. A lakat ikon azt üzeni, hogy az oldal gondol az adatvédelemre. Aki érti a hátterét, azt is tudja, hogy a böngésző és a szerver közti köztes gépek nem látják és nem módosíthatják az áthaladó adatokat.
• Fizetési biztonság. Ha bármit árulsz a webhelyeden, a vásárlók tudni akarják, hogy a fizetési adataik biztonságban jutnak el a szerverig. A HTTPS és a lakat ezt jelzi.
• Keresőoptimalizálás. Sok keresőmotor hátrébb sorolja a HTTPS nélküli webhelyeket, ezért nehezebb a legjobb helyekre kerülni a találatok között.
• A jó híred. A böngészők a HTTPS nélküli oldalak mellé kiírják, hogy „nem biztonságos”. Ezzel azt üzenik, hogy az a webhelytulajdonos, aki nem foglalkozik a titkosítással (sok helyen ingyenes), nem érdemel bizalmat. Nem szeretnéd, hogy a böngésző téged is ilyennek mutasson.

A WordPress teljes mértékben kompatibilis a HTTPS-sel, ha a webszerveren telepítve van egy TLS/SSL tanúsítvány. A HTTPS használata határozottan ajánlott, mert védi a WordPress-bejelentkezéseket és a látogatókat is.

Az adminfelület HTTPS-en

A WordPress-adminfelület titkosításához és kikényszerítéséhez egy konstanst kell megadnod a webhely wp-config.php fájljában.

Figyelem

A konstansnak a wp-config.php fájlban kell szerepelnie, bővítményfájlban megadva nem elég. A beállítás előtt a szerveren már működnie kell az SSL-nek, és a biztonságos szerverhez tartoznia kell egy (virtuális) hosztnak. Ha ezek hiányoznak, a webhely nem működik rendesen a konstans bekapcsolása után. Ha nem vagy biztos benne, kérj segítséget a tárhelyszolgáltatódtól.

HTTPS-bejelentkezés és HTTPS-adminhozzáférés kikényszerítése

Ha a FORCE_SSL_ADMIN konstanst true értékre állítod, minden bejelentkezés és minden adminmunkamenet SSL-en fut.

define( 'FORCE_SSL_ADMIN', true );

A korábbi FORCE_SSL_LOGIN konstans elavult, helyette a FORCE_SSL_ADMIN használható.

Fordított proxy (reverse proxy) mögött

Előfordul, hogy a WordPress egy fordított proxy mögött fut. A proxy biztosítja az SSL-t, de maga a WordPress SSL nélkül áll. Ilyenkor a fenti beállítás végtelen átirányítási hurokba küldi a kéréseket. Ennek elkerülésére be kell állítanod, hogy a WordPress ismerje fel a HTTP_X_FORWARDED_PROTO fejlécet. Ez csak akkor működik, ha a proxy ezt a fejlécet megfelelően beállítja.

define( 'FORCE_SSL_ADMIN', true );
// Egyes beállításoknál a HTTP_X_FORWARDED_PROTO értéke vesszővel
// elválasztott lista lehet, pl. http,https, ezért a https meglétét keressük.
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Proxy-átirányításnál a kérést egy másik géphez továbbítod, de a hozzá tartozó fejlécek nem mennek vele automatikusan. A WordPressnek viszont szüksége van néhányra a helyes átirányításokhoz, ezért az átirányítási szabályba fel kell venned őket. Nginx esetén például így:

location / {
    proxy_pass http://a_te_hostod:port;
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect off;
}

A $ jelű változókat a fordított proxy maga tölti ki.

Különleges beállítások: régebbi vagy szokatlan szerver

Az alábbiak azoknak szólnak, akik régebbi WordPress-t futtatnak (amit nem érdemes), vagy az SSL-beállításuk szokatlan, például a tanúsítvány másik tartományra szól. Az alapötlet az, hogy a teljes wp-admin biztonságos kapcsolaton fusson:

1. Két virtuális hosztot állítasz be ugyanazzal a webhelycímmel: egy biztonságosat és egy nem biztonságosat.
2. A biztonságos hoszton átirányítási szabállyal a nem wp-admin forgalmat a nem biztonságos oldalra tereled.
3. A nem biztonságos hoszton átirányítási szabállyal a wp-admin felé irányuló forgalmat a biztonságos hosztra tereled.
4. Egy bővítménnyel szűrőt teszel az adminfelület hivatkozásaira, hogy a bekapcsolás után https-re íródjanak át, és a sütik csak titkosított kapcsolaton működjenek.

Ez Apache mod_rewrite szabályokkal valósítható meg (az httpd.conf-ban vagy .htaccess fájlban), de más tárhelykörnyezetre is átültethető.

Virtuális hosztok

A nem biztonságos webhely mellé kell egy biztonságos szerverre beállított (virtuális) host is. A példában ugyanaz a DocumentRoot tartozik mindkettőhöz. Használhatsz más nevű hosztot is (például wpadmin.sajatoldal.hu), amelynek a gyökerét a wpadmin könyvtárra linkeled. A biztonságos virtuális hosztot kérd a szolgáltatódtól, vagy ha van rendszergazdai hozzáférésed, állítsd be magad. Fontos, hogy a névalapú virtuális hosztolással nem lehet megkülönböztetni több SSL-szervert.

Átirányítás a nem biztonságos hoszton

A nem biztonságos hoszt .htaccess fájljába vagy virtuálishoszt-blokkjába tedd be ezt a szabályt, hogy a /wp-admin/ és a wp-login.php felkeresésekor a böngésző automatikusan a biztonságos hosztra menjen. A WordPress fő átirányítási blokkja elé kell kerülnie:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^/?(wp-admin/|wp-login\.php) https://example.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

Ha használsz szép permalinkeket, ennek a sornak a RewriteRule ^.*$ - [S=40] sor elé kell kerülnie. A THE_REQUEST használata biztosítja, hogy csak valódi HTTP-kérések íródjanak át, a helyi közvetlen fájlkérések (például include vagy fopen) nem.

Szabályok a biztonságos hoszton (nem kötelező)

Ezek a szabályok letiltják a nyilvános oldal elérését biztonságos kapcsolaton. Ha a fent említett bővítménnyel a webhely nyilvános részén is bejelentkezve szeretnél maradni, ne add hozzá őket, mert a bővítmény a sütit titkosítatlan kapcsolaton letiltja.

RewriteRule !^/wp-admin/(.*) - [C]
RewriteRule ^/(.*) https://www.example.com/$1 [QSA,L]

Az első szabály a wp-admin könyvtárat kiveszi a másodikból, a második pedig a biztonságos oldal forgalmát átküldi a nem biztonságosra, hogy a közönség ne vegyen észre semmit.

A WordPress webcíme

Egyes bővítmények működéséhez, vagy más okból beállíthatod a WordPress webcímét https-re (például https://example.com). A blog címe (a nyilvános webcím) ne változzon.

Példa konfigurációk

A biztonságos hoszt:

<VirtualHost nnn.nnn.nnn.nnn:443>
    ServerName www.example.com

    SSLEngine On
    SSLCertificateFile /etc/apache2/ssl/thissite.crt
    SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

    DocumentRoot /var/www/mysite

    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteRule !^/wp-(admin|includes)/(.*) - [C]
        RewriteRule ^/(.*) https://www.example.com/$1 [QSA,L]
    </IfModule>

</VirtualHost>

A nem biztonságos hoszt:

<VirtualHost *>
    ServerName www.mysite.com

    DocumentRoot /var/www/ii/mysite

    <Directory /var/www/ii/mysite >
        <IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteBase /
            RewriteCond %{REQUEST_FILENAME} -f [OR]
            RewriteCond %{REQUEST_FILENAME} -d
            RewriteRule ^wp-admin/(.*) https://www.example.com/wp-admin/$1 [C]
            RewriteRule ^.*$ - [S=40]
            RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]

        </IfModule>
    </Directory>

</VirtualHost>

Megjegyzés

Ez a konfiguráció nem teljesen kompatibilis a WordPress 2.8 és újabb változataival, mert azok a wp-includes mappából is használnak fájlokat. Az első szabálykészlet átirányítása egyes felhasználóknál biztonsági figyelmeztetést okozhat.

Átirányítás bejelentkezéshez és regisztrációhoz

Érdemes az SSL-t a bejelentkezéshez és a regisztrációhoz is használni. Ehhez helyettesítő szabályok:

Nem biztonságos hoszton:

RewriteRule ^/wp-(admin|login|register)(.*) https://www.example.com/wp-$1$2 [C]

Biztonságos hoszton:

RewriteRule !^/wp-(admin|login|register)(.*) - [C]

443-as vagy 80-as porton futó webhely

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# 443-as (vagy más, HTTP over SSL) porton futó webhelyhez
RewriteCond %{SERVER_PORT} !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [L]

# 80-as porton (http) futó webhelyhez
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]

RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

Összefoglalás és korlátok

Ez a módszer nem szünteti meg a WordPress minden eredendő biztonsági kockázatát, és nem véd az úgynevezett köztes támadások (man-in-the-middle) ellen sem. Viszont jóval nehezebbé teszi, hogy egy rosszindulatú személy ellopja a sütijeidet vagy a hitelesítési fejléceidet, és a nevedben belépjen az adminfelületre. Azt is megakadályozza, hogy lehallgassák a tartalmaidat, ami például jogi blogoknál fontos lehet, ahol szigorúan védendő dokumentumvázlatok vannak.

Egy fontos korlát: ha a böngésződben el vannak mentve a sütik vagy jelszavak, és a biztonságos címet (https://…/wp-admin/) elérve a csomagok titkosítatlanul mennek el, a sütik vagy hitelesítési fejlécek elfoghatók. A maximális biztonsághoz ezért mindig kifejezetten a https címet használd, vagy minden új munkamenet elején jelentkezz be újra.