Wykrywanie adresu URL WordPress bez wykonywania pełnego HTTP GET?

Próbuję napisać procedurę oneboxing, która zapewnia specjalne traktowanie wpisów na blogu WordPress. Biorąc pod uwagę prosty, pozbawiony ozdób adres URL w treści, taki jak

http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/

Jak wykryć, że jest to instalacja WordPress, najlepiej bez wykonywania pełnego HTTP GET przy każdym wyświetlanym adresie URL?

Z pewnością istnieją wspólne konwencje dotyczące adresów URL WordPress, od których moglibyśmy zacząć, co eliminuje przynajmniej niektóre adresy URL z rywalizacji. W tym przypadku jest to ...

http://example.com/rok/month/slug-goes-here

Ale to też nie jest uniwersalna stała.

Próbowałem spojrzeć na nagłówki tego adresu URL za pomocą HTTP HEAD i widzę:

Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:18340
Content-Type:text/html; charset=UTF-8
Date:Thu, 07 Jun 2012 07:07:38 GMT
Keep-Alive:timeout=15, max=100
Server:Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Vary:Cookie,Accept-Encoding
WP-Super-Cache:Served legacy cache file
X-Pingback:http://blog.stackoverflow.com/xmlrpc.php
X-Powered-By:PHP/5.2.6-2ubuntu4.2

Nie sądzę, że poleganie na obecności WP-Super-Cachebyłoby szczególnie niezawodne, a to jedyna rzecz, którą widzę w nagłówkach, która by pomogła, więc może nie ma zerowych wspólnych nagłówków HTTP w instalacji WordPress?

Z mojego doświadczenia i szybkiego wyszukiwania kodu nie wynika, że WP identyfikuje się w nagłówkach. Są jednak takie, które wydają się wystarczająco wyraźne i raczej nie będą dostosowane.

HEAD to /wp-login.phpbędzie zawierać następujące informacje dotyczące instalacji .org:

 Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

I dla .com:

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/; domain=.wordpress.com

Nazwę pliku cookie można dostosować, definiując TEST_COOKIEstałą, ale WP Cookie checkciąg jest zapisany na stałe w rdzeniu, a także set_cookie()wymaga tego w źródle pliku.

Do lokalizacji wp-login.phpsą skróty URL (zaimplementowane wp_redirect_admin_locations()od wersji WP 3.4 (patrz bilet nr 19607 ):

/loginkatalog główny witryny 302przekierowuje wp-login.php, gdziekolwiek się znajduje.

Tak więc jedyny scenariusz, którego nie można niezawodnie wykryć, jeśli WP jest zainstalowany i ograniczony do podkatalogu, bez użycia go do zarządzania katalogiem głównym witryny.

Wyślij HEADzapytanie do /wp-feed.phptego samego katalogu co /xmlrpc.php(nawet w instalacjach podkatalogowych). W WordPress otrzymasz Locationnagłówek jako odpowiedź zawierającą ciąg feed.

W twoim przykładzie blog.stackoverflow.comotrzymasz:

HTTP/1.1 301 Moved Permanently\r\n
Date: Thu, 07 Jun 2012 07:30:10 GMT\r\n
Server: Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g\r\n
X-Powered-By: PHP/5.2.6-2ubuntu4.2\r\n
Location: http://blog.stackoverflow.com/feed/\r\n
Vary: Accept-Encoding\r\n
Content-Type: text/html; charset=UTF-8\r\n
\r\n

Samo istnienie pliku xmlrpc.phpnie jest wystarczająco bezpieczne. Każdy może nadać tej nazwie plik.

Uwaga: X-PingbackNagłówek można wyłączyć, filtrując 'wp_headers'. Więc moja sugestia nie jest kuloodporna.

Powiązane: Kroki, które należy podjąć, aby ukryć fakt, że witryna korzysta z WordPress?

Dołącz adres URL ?page_id=-1i wykonaj w tym celu żądanie HTTP HEAD .

Na automatycznie instalowanych blogach WordPress spowoduje to odpowiedź 404.

Na blogach wordpress.com spowoduje to odpowiedź 301 (która zakończy się odpowiedzią 200, jeśli przekierujesz).

Na stronach innych niż WordPress powinieneś otrzymać odpowiedź 200 (zakładając, że oryginalny adres URL bez ciągu zapytania dał ci 200) - ciąg zapytania nie powinien mieć znaczenia.

Przykład z żądaniem HEAD dla http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/?page_id=-1:

HTTP/1.1 404 Not Found
Server: Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Content-Encoding: gzip
Vary: Cookie,Accept-Encoding
Cache-Control: no-cache, must-revalidate, max-age=0
Last-Modified: Thu, 07 Jun 2012 08:53:01 GMT
Date: Thu, 07 Jun 2012 08:53:01 GMT
Keep-Alive: timeout=15, max=100
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Pragma: no-cache
Connection: Keep-Alive
X-Powered-By: PHP/5.2.6-2ubuntu4.2
X-Pingback: http://blog.stackoverflow.com/xmlrpc.php
Content-Type: text/html; charset=UTF-8

Przykład z żądaniem HEAD dla http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(wyłącz przekierowania):

HTTP/1.1 301 Moved Permanently
X-Pingback: http://dailycrave.wordpress.com/xmlrpc.php
Server: nginx
Expires: Wed, 11 Jan 1984 05:00:00 GMT
X-Hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
Location: http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/
Pragma: no-cache
Cache-Control: no-cache, must-revalidate, max-age=60
Connection: close
Last-Modified: Thu, 07 Jun 2012 09:01:09 GMT
Content-Type: text/html; charset=UTF-8
Date: Thu, 07 Jun 2012 09:01:09 GMT

(Uwaga jajko wielkanocne X-Hacker!)

Jeśli skorzystasz z przekierowania 301 dla bloga wordpress.com, skończysz z tym:

HTTP/1.1 200 OK
Server: nginx
Vary: Accept-Encoding, Cookie
Last-Modified: Thu, 07 Jun 2012 09:48:26 GMT
Cache-Control: max-age=172, must-revalidate
Connection: close
Date: Thu, 07 Jun 2012 09:50:34 GMT
Transfer-Encoding: Identity
Content-Encoding: gzip
Link: <http://wp.me/pXGqK-27g>; rel=shortlink
X-Pingback: http://dailycrave.wordpress.com/xmlrpc.php
Content-Type: text/html; charset=UTF-8
X-Nananana: Batcache
X-Hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.

Zwróć uwagę na nagłówek „Link” zawierający http://wp.me/adres URL, który wydaje się być wspólny dla wszystkich blogów hostowanych przez wordpress.com i może być użyty do ich identyfikacji.

Uważam, że to działa, ponieważ przekazanie ?page_id=-1adresu URL zastępuje domyślny routing z segmentów adresu URL. Nie będzie strony o identyfikatorze -1, więc zamiast tego obsługiwane jest przekierowanie 404 /.

Nie jest też dostępna wp-super-cache we wszystkich instalacjach wordpress, ani nie ma ustalonego formatu w adresach URL. Podczas gdy strona ustawień permalinks zawiera pewne stałe ustawienia schematów URL, których można użyć, każdy może po prostu użyć dowolnego niestandardowego schematu URL. Na przykład, jeśli ktoś po prostu zdecyduje się użyć tylko nazwy strony / postu w adresie URL, jest mniej więcej niemożliwe, aby dowiedzieć się, czy jest to witryna Wordpress.

Obecność xmlrpc może zostać wykorzystana do wykrycia, ale ponownie można to wyłączyć.

I wreszcie, nawet jeśli wykonasz pełny odczyt adresu URL, nadal nie jest w 100% możliwe wykrycie, czy strona jest zbudowana przy użyciu wordpress. Wszystko zależy od szablonu motywu i sposobu jego opracowania.

Jednym dość niezawodnym sposobem jest poszukiwanie obecności wp-login i wp-admin. Ale nawet te można również przenieść. Jednak wybrałbym tę drogę.

Dwie alternatywy dla komentarzy, ustaw własny nagłówek WordPress. Upuść to w pliku functions.php motywu.

add_action('template_redirect', 'add_wp_header');
function add_wp_header(){

header('Type: WordPress');
}

Skaner linii papilarnych WP (ruby), przechodzi przez kilka kroków, aby dowiedzieć się, czy WordPress jest używany, na przykład szuka katalogu wtyczki, nazwy motywu, metatagów, pliku readme itp. (Nie mam pojęcia, jak dokładna jest to prawda ). http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Co powiesz na wysłanie żądania głównego do jednego z plików rozpoczynającego się od prefiksu wp-. Najlepiej spójrz na wp-login.php. Jeśli istnieje, oznacza to, że w witrynie działa WordPress.