.htaccess-i audit: miks sait annab 500 ja millised reeglid ei tööta
Lohista fail siia — tööriist leiab BOM-i, surnud direktiivid, kõrge 500-vea riskiga reeglid ja kõrvalise sekkumise märgid. Fail loetakse sinu brauseris ja seda ei saadeta kuhugi.
Tekst on käsitsi kleebitud, seetõttu jäeti baiditasandi kontrollid vahele. BOM-i, CRLF-i ja nähtamatute märkide nägemiseks lohista fail ise siia.
Puhas .htaccess ei ravi häkkimist. Kui sait on kompromiteeritud, elab pahatahtlik kood PHP-s ja .htaccess on üksnes selle tagajärg: dropper kirjutab faili minutitega tagasi pärast seda, kui oled selle puhastanud. Järjekord on vastupidine — kõigepealt leia käivitatav kood, seejärel korrasta konfiguratsioon.
Siia ilmub lähtefail koos reanumbritega.
Leidudega read on tähistatud märgiga !: punased on vead, merevaigukollased hoiatused. Nähtamatud ja mitteprinditavad märgid on näidatud punktiga · — failis endas on nende kohal tühjus.
Puhastamine eemaldab BOM-i, teisendab reavahetused LF-iks, eemaldab mitteprinditavad märgid, asendab sisemised püsitühikud tavaliste tühikutega ja lisab lõppu reavahetuse. Direktiive ei muudeta. Fail salvestatakse nimega htaccess-clean.txt — nimeta see enne serverisse laadimist ümber failiks .htaccess.
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Just seda kirjutab WordPress ise. Pane oma reeglid rea # BEGIN WordPress kohale: kõik markerite vahel kirjutatakse üle iga kord, kui salvestad püsilinkide seaded.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
Alamdomeenidel põhineva multisite'i puhul on plokk sama, kuid kolmes viimases reeglis ilma eesliiteta ^([_0-9a-zA-Z-]+/)?: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] ja RewriteRule ^(.*\.php)$ $1 [L].
Ploki asendamine ei taasta püsilinke iseenesest: pärast muudatust mine Seaded → Püsilingid ja klõpsa «Salvesta» — WordPress kontrollib ploki üle ja kirjutab selle vajadusel ümber.
Fail loetakse sinu brauseris — selle sisu ei saadeta kuhugi ega salvestata.
Miks just fail, mitte kleebitud tekst
Kõige sagedasem 500-vea põhjus pärast .htaccess-faili muutmist ei paista tekstis üldse välja. See on BOM — kolm nähtamatut baiti faili alguses, mille lisab Windowsi Notepad UTF-8-na salvestamisel. Apache peab neid esimese direktiivi osaks ega suuda seda parsida. Seepärast võtabki tööriist vastu just faili: ainult nii saab lugeda baite ning näha BOM-i, Windowsi-stiilis reavahetusi ja ridade sees peituvaid nähtamatuid märke. Teine probleemide rühm on direktiivid, mis ei tee midagi, aga näevad töötavad välja. mod_gzip_on on Apache 1.3 süntaks; tänapäevastes serverites eiratakse seda vaikselt, samal ajal kui inimesed usuvad aastaid, et pakkimine on sees. Ka ExpiresByType-plokk, mis on mähitud mod_headers.c kontrolli mod_expires.c asemel, ei tööta — ja ilma vihjeta seda ei märka. Kolmandaks php_value ja php_flag. Need toimivad ainult siis, kui PHP on laaditud Apache moodulina. Tänapäevastes PHP-FPM-iga majutustes selline rida kas eiratakse või annab kohe 500. Ja eraldi turvalisusest: kui failist leitakse reeglid, mis suunavad külastajaid ümber sõltuvalt sellest, millisest otsimootorist nad tulid, või varjavad ümbersuunamist administraatori eest, on see tüüpiline häkkimise tunnus. Puhas .htaccess häkkimist siiski ei ravi: peaaegu alati elab failides kusagil PHP-skript, mis kirjutab selle tagasi.