Mendeteksi URL WordPress tanpa melakukan GET HTTP lengkap?

Saya mencoba menulis rutin oneboxing yang memberikan entri blog WordPress perlakuan khusus. Jadi diberi URL sederhana dan tanpa hiasan dalam konten, seperti

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

Bagaimana saya mendeteksi bahwa ini adalah instalasi WordPress, idealnya tanpa melakukan HTTP GET penuh pada setiap URL yang saya lihat?

Tentu saja ada konvensi umum untuk URL WordPress yang dapat kita mulai, yang menghilangkan setidaknya beberapa URL dari pertikaian. Dalam hal ini ...

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

Tapi itu juga bukan konstanta universal.

Saya mencoba melihat header dari URL itu menggunakan HTTP HEAD , dan saya melihat:

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

Saya tidak berpikir mengandalkan kehadiran WP-Super-Cacheakan sangat dapat diandalkan, dan itulah satu-satunya hal yang saya lihat di header yang akan membantu, jadi mungkin ada nol header HTTP umum dalam instalasi WordPress?

Dari pengalaman saya dan pencarian kode cepat tidak ada yang disengaja cara yang WP mengidentifikasi dirinya dalam header. Namun ada beberapa yang tampaknya cukup berbeda dan tidak mungkin untuk dikustomisasi.

KEPALA untuk /wp-login.phpakan berisi berikut untuk menginstal .org:

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

Dan untuk .com:

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

Nama cookie dapat disesuaikan dengan mendefinisikan TEST_COOKIEkonstanta, tetapi WP Cookie checkstring juga di-hardcode pada intinyaset_cookie() panggilan untuk ini dalam sumber file.

Untuk menemukan wp-login.phpada beberapa pintasan URL (diterapkan wp_redirect_admin_locations()sejak WP 3.4 (lihat tiket # 19607 ):

/logindi root situs tidak 302mengarahkan ke wp-login.php, di mana pun itu.

Jadi satu-satunya skenario yang tidak dapat dideteksi dengan andal jika WP dipasang dan terbatas pada subdirektori, tanpa digunakan untuk mengelola root situs sama sekali.

Kirim HEADpermintaan ke /wp-feed.phpdalam direktori yang sama dengan /xmlrpc.php(bahkan dalam instalasi subdirektori). Di WordPress Anda akan mendapatkan Locationtajuk sebagai respons yang berisi string feed.

Dalam contoh blog.stackoverflow.comAnda, Anda akan mendapatkan:

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

Keberadaan file xmlrpc.phpsaja tidak cukup aman. Siapa saja dapat memberikan nama ini ke file.

Peringatan: X-PingbackHeader dapat dinonaktifkan dengan memfilter 'wp_headers'. Jadi saran saya bukan anti peluru.

Terkait: Langkah-langkah untuk Menyembunyikan Fakta sebuah Situs Menggunakan WordPress?

Tambahkan URL dengan ?page_id=-1dan lakukan HTTP HEAD permintaan untuk itu.

Di blog WordPress yang dipasang sendiri, ini akan menghasilkan respons 404.

Di blog wordpress.com, ini akan menghasilkan respons 301 (yang berakhir pada 200 tanggapan jika Anda mengikuti arahan ulang).

Di situs non-WordPress, Anda harus mendapatkan 200 respons (dengan asumsi URL asli tanpa string kueri memberi Anda 200) - string kueri seharusnya tidak membuat perbedaan.

Contoh dengan permintaan HEAD untuk 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

Contoh dengan permintaan HEAD untuk http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(ikuti arahan dimatikan):

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

(Perhatikan telur paskah X-Hacker!)

Jika Anda mengikuti pengalihan 301 untuk blog wordpress.com, Anda berakhir dengan ini:

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.

Perhatikan taut "Link" yang berisi http://wp.me/URL, yang tampaknya umum untuk semua blog yang di-hosting oleh wordpress.com dan dapat digunakan untuk mengidentifikasi mereka.

Saya percaya ini berfungsi karena mengirimkan ?page_id=-1URL menimpa perutean default dari segmen URL. Tidak akan ada halaman dengan ID -1, sehingga 404 / redirect dilayani sebagai gantinya.

Baik wp-super-cache tidak tersedia di semua instalasi wordpress, juga tidak ada format tetap di URL. Sementara halaman pengaturan permalinks memang memberikan beberapa pengaturan tetap untuk skema URL yang dapat digunakan, siapa pun bisa menggunakan skema URL khusus apa pun. Sebagai contoh, jika seseorang hanya memutuskan untuk menggunakan hanya nama halaman / posting di URL, itu lebih atau kurang mustahil untuk mengetahui apakah itu adalah situs web Wordpress.

Kehadiran xmlrpc dapat digunakan untuk mendeteksi, tetapi sekali lagi, ini dapat dinonaktifkan.

Dan akhirnya, bahkan jika Anda mendapatkan URL sepenuhnya, masih tidak mungkin 100% untuk mendeteksi jika halaman dibuat menggunakan wordpress. Itu semua tergantung pada templat tema dan bagaimana itu dikembangkan.

Salah satu cara yang cukup dapat diandalkan adalah mencari keberadaan wp-login dan wp-admin. Tetapi bahkan ini juga bisa dipindahkan. Aku akan pergi dengan cara ini.

Dua alternatif untuk komentar, atur tajuk WordPress Anda sendiri. Letakkan ini di functions.php tema Anda.

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

header('Type: WordPress');
}

WP scan fingerprinter (ruby), ia melewati beberapa langkah untuk mencoba dan mencari tahu apakah WordPress sedang digunakan seperti mencari direktori plugin, nama tema, meta tag, readme, dll. (Saya tidak tahu seberapa akurat ini sebenarnya ). http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Bagaimana dengan mengirim permintaan kepala ke salah satu file yang dimulai dengan awalan wp-. Idealnya lihat wp-login.php. Jika ada itu berarti situs web tersebut menjalankan WordPress.