Probabil ați auzit că ascunderea versiunii WP este o parte foarte importantă a WordPress Security. La începutul lunii februarie a existat o problemă serioasă de vulnerabilitate cu WP REST API în care versiunea arată dacă site-ul tău este vulnerabil sau nu. Atâția utilizatori au căutat modalități de a ascunde informații despre versiunea lor WP.
În opinia mea, aceasta nu este o parte importantă a procesului de protecție. Producătorii WordPress nu o văd ca pe o problemă și nu încearcă să o ascundă. Voi prezenta argumentele mele mai târziu în acest articol, dar mai întâi să ne uităm la metodele folosite pentru a determina versiunea WP și cum să le prevenim (dacă doriți).
readme.html
- Cel mai simplu mod de a determina versiunea este să vizitați adresa URL /readme.html și să citiți titlul mare.
- Din 4.7 această metodă este mai puțin utilizabilă, deoarece WP a încetat să mai afișeze versiunea minoră (4.7.2.) și arată doar cea majoră (4.7).
metagenerator
- Dacă deschideți codul sursă al site-ului dvs., puteți găsi generatorul de metaetichete cu versiunea WP în el:
- Trebuie să găsiți linia potrivită, dar este încă destul de ușor.
Flux RSS
- O altă locație pentru a verifica versiunea este /feed/, unde puteți găsi generatorul de elemente XML:
- https://wordpress.org/?v= 4.7.2
Aceste 3 metode sunt cele mai comune modalități de a determina versiunea WordPress.
Există modalități de a preveni aceste metode. Puteți bloca accesul la readme.html, de exemplu, în fișierul .htaccess:
1 2 | order allow,deny deny from all |
Va fi returnat mesajul „403 – acces refuzat”. Dar îi arată atacatorului că fișierul există. Deci, a pretinde că fișierul nu există poate fi o modalitate mai bună. Puteți returna mesajul „404 – nu a fost găsit” cu următoarea regulă:
1 | RewriteRule ^readme.html - [L,R=404] |
Dacă doriți să eliminați versiunea din metaetichetele și din feed, trebuie să o faceți în WP. Numărul versiunii își are originea în fișierul wp-includes/version.php. Este stocat în variabila globală numită wp_version . O abordare este de a elimina șirul cu versiunea, astfel încât site-ul să „pre-rendă” (ob_start,..) și să găsească și să înlocuiască toate aparițiile numărului de versiune. Consider că acest lucru este inutil și pierde performanța, pentru că nu funcționează pentru /feed/. Desigur, puteți edita feedul, dar există mai multe locații pe care trebuie să le editați. Știați despre fișierul /wp-links-opml.php? Dezvăluie, de asemenea, numărul versiunii. Este multă muncă pentru a valida toate aceste fișiere.
O abordare mai bună este să folosiți cârligul WP the_generator :
1 | add_filter('the_generator', '__return_empty_string'); |
Îndepărtează versiunea din metaetichetele și formează fluxurile XML.
De obicei, există o altă locație cu șirul de versiune – în căile către fișierele css și js. Mulți creatori de pluginuri/teme adaugă parametrul „ ver ” la cale pentru a preveni memorarea în cache pe partea clientului după actualizare.
/wp-includes/js/wp-embed.min.js?ver=4.7.2
Din nou, există un cârlig pentru a-l scoate:
1 2 3 4 5 6 7 8 | function lynt_remove_ver( $src ) { $src = remove_query_arg('ver', $src); return $src; } add_filter( 'script_loader_src', 'lynt_remove_ver' ); add_filter( 'style_loader_src', 'lynt_remove_ver' ); |
Acest fragment elimină parametrul ver din toate fișierele js și css. Îl puteți îmbunătăți pentru a elimina numai ver dacă conține valoarea $wp_version .
Aceste câteva linii de cod sunt ceea ce fac de fapt multe plugin-uri care promit ascunderea versiunii WP, nimic mai mult.
S-ar putea să aveți o idee să schimbați numărul versiunii direct în fișierul version.php. Aceasta nu este o idee foarte bună, deoarece veți ajunge să preveniți actualizările viitoare și să încălcați consistența fișierului instalării dvs. WP. Instrumentele care efectuează verificări ale consistenței fișierelor nu le-ar plăcea.
Pe lângă aceste metode simple, există multe alte modalități de a determina versiunea WP. Unul se numește Advanced Fingerprinting , care verifică hash-urile unor fișiere statice din nucleul WP.
Puteți utiliza această metodă pentru multe alte fișiere. Există unele excepții când aceste fișiere nu sunt modificate în timpul versiunilor minore.
Puteți găsi lista de fișiere statice unice și hashurile lor pe esenta mea . Pentru a obține rezultate mai bune, puteți compara mai mult de un fișier unic.
Cum să detectăm WP în sine?
Pentru a testa dacă site-ul folosește WP și nu vă pasă de versiune, puteți utiliza mai multe alte metode
- Căutați un șir de caractere wp-content – dezavantaje: există false pozitive la conectarea imaginilor de pe site-uri externe, există posibilitatea de a redenumi wp-content. Pe de altă parte, puteți utiliza accesul „indirect” prin diferite motoare de căutare sau cache-uri – de exemplu archive.org
- Încercați adresa /wp-trackback.php sau /wp-links-opml.php – returnează XML în cazul WP. Accesul direct la fișierele PHP poate fi blocat în cazuri excepționale și este posibil ca această metodă să nu funcționeze.
- Puteți încerca și /wp-admin/admin-ajax.php (din WP 2.1), acesta returnează un număr după un apel direct. Dosarul wp-admin este uneori complet refuzat, dar acest fișier ar trebui să fie o excepție. Dacă blocați accesul la admin-ajax.php, multe funcții de front-end care folosesc AJAX ar putea să nu mai funcționeze.
- Metodele care utilizează fișiere statice oferă performanțe ridicate – de exemplu, menționat /readme.html, dar acest fișier este uneori blocat. Rezultate mai bune oferă /wp-includes/js/colorpicker.js – acest fișier există din WP 2.0. Această metodă nu funcționează când folderul wp-includes este redenumit.
- Dacă cineva a făcut un efort mare pentru a ascunde WP, puteți încerca dacă a blocat și reweites alternative de administrare, cum ar fi /dashboard sau /login (din 3.4.1 – funcția wp_redirect_admin_locations în /wp-includes/canonical.php).
Personal cred că încercarea de a ascunde versiunea WP este ca și cum ați înclina la morile de vânt. Nu ar trebui să petreceți mai mult de 10 minute din timpul dumneavoastră cu această activitate . Blocăm accesul la unele fișiere din partea serverului – readme.html și fișierele readme din pluginuri, dar motivul principal este prevenirea scanării în masă. Scopul nostru nu este să sporim securitatea prin aceasta.
Ok, deci cum rămâne cu problema actuală, când rezultatul atacului depinde de versiunea exactă? Ascunderea ar putea ajuta? Bine Aceste atacuri în masă – presupun că 99,9% din toate atacurile sunt de acest tip – nici măcar nu încearcă să exploreze site-ul tău web, pur și simplu încearcă să exploateze orice URL vulnerabil direct. Ei nici măcar nu verifică dacă site-ul este alimentat de WordPress. Scopul lor este să atace cât mai multe ținte posibil în cel mai scurt timp înainte ca plasturele să fie aplicat. Orice altă comunicare cu ținta are ca rezultat întârziere inutilă.
Ascunderea versiunii WordPress este una dintre tehnicile numite „security by obscurity”. În cele mai multe cazuri, ascunderea versiunii nu va avea un efect negativ, dar nu vă puteți aștepta să aducă o protecție serioasă. Există câteva plugin-uri premium care încearcă să ascundă informații despre WP, dar în principiu nu pot funcționa 100% din timp și recomand să le eviți. Dacă actualizați WP-ul în mod regulat , nu aveți niciun motiv să ascundeți numărul versiunii. Aceasta este cea mai bună apărare împotriva atacului.