Виявлення URL-адреси WordPress, не виконуючи повний HTTP GET?

Я намагаюся написати програму oneboxing, яка надає запитам у блозі WordPress спеціальне лікування. Тож надано просту URL-адресу без вмісту, наприклад, як

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

Як я можу виявити, що це установка WordPress, в ідеалі без повного отримання HTTP GET на кожній URL-адресі, яку я бачу?

Є , звичайно , загальні угоди для WordPress URL - адрес , які ми могли б почати з, що виключає по крайней мере , деяким URL - адреса з розбрату. У цьому випадку це ...

http://example.com/year/month/slug-goes-тут

Але і це не є універсальною постійною.

Я спробував переглянути заголовки цієї URL-адреси за допомогою HTTP HEAD , і я бачу:

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

Я не думаю, що покладання на присутність WP-Super-Cacheбуло б особливо надійним, і це єдине, що я бачу в заголовках, що могло б допомогти, тому, можливо, в установці WordPress є нульові загальні заголовки HTTP?

З мого досвіду та швидкого пошуку коду, немає навмисних способів WP ідентифікувати себе в заголовках. Однак є деякі, які здаються досить чіткими і, ймовірно, не можуть бути налаштовані.

HEAD to /wp-login.phpбуде містити наступні для .org установки:

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

А для .com:

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

Ім'я файлу cookie налаштовується, визначаючи TEST_COOKIEконстанту, але WP Cookie checkрядок є чітко кодованою в ядрі, а також set_cookie()викликом цього в джерелі файлу.

Для розміщення wp-login.phpє кілька ярликів URL-адрес (реалізованих wp_redirect_admin_locations()з WP 3.4 (див. Квиток № 19607 ):

/loginКорінь сайту виконує 302переадресацію wp-login.php, куди б він не був.

Тож єдиний сценарій, який неможливо надійно визначити, якщо WP встановлений і обмежений у підкаталозі, не використовуючись для управління коренем сайту взагалі.

Надішліть HEADзапит /wp-feed.phpу той самий каталог, що й /xmlrpc.php(навіть у установках підкаталогів). У WordPress ви отримаєте Locationзаголовок як відповідь, що містить рядок feed.

У своєму прикладі blog.stackoverflow.comви отримаєте:

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

Само існування файлу xmlrpc.phpнедостатньо безпечно. Будь-хто може дати це ім’я файлу.

Caveat: X-PingbackЗаголовок можна відключити фільтруванням 'wp_headers'. Тому моя пропозиція не є кулезахисною.

Пов’язано: кроки, які потрібно зробити, щоб приховати факт, який веб-сайт використовує WordPress?

Додайте URL-адресу до ?page_id=-1і зробіть для цього запит HTTP HEAD .

У блогах WordPress, які самостійно встановлені, це спричинить відповідь 404.

У блогах wordpress.com це призведе до відповіді 301 (що закінчиться 200 відповіді, якщо слідувати переадресації).

На сайтах, що не належать до WordPress, ви повинні отримати відповідь 200 (припускаючи, що оригінальна URL-адреса без рядка запиту дала вам 200) - рядок запиту не повинен мати жодних значень.

Приклад із запитом HEAD для 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

Приклад із запитом HEAD для http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(вимкнено переадресації):

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

(Зверніть увагу на пасхальне яйце X-Hacker!)

Якщо ви дотримуєтесь переспрямування 301 для блогу wordpress.com, ви закінчите це:

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.

Зверніть увагу на заголовок "Посилання", що містить http://wp.me/URL-адресу, яка, як видається, є загальною для всіх блогів, на яких розміщено wordpress.com, і може бути використана для їх ідентифікації.

Я вважаю, що це працює, оскільки передача ?page_id=-1URL-адреси переосмислює маршрутизацію за замовчуванням із сегментів URL-адреси. Не буде сторінки з ідентифікатором -1, і натомість подається перенаправлення 404 /.

Ні wp-super-кеш не доступний для всіх установок Wordpress, а також немає фіксованого формату в URL-адресах. Незважаючи на те, що на сторінці налаштувань постійних посилань наводяться певні фіксовані настройки для URL-схем, які можна використовувати, кожен може просто використовувати будь-яку власну схему URL-адрес. Наприклад, якщо хтось просто вирішив використовувати лише ім’я сторінки / публікації в URL-адресі, то більш-менш неможливо з'ясувати, чи це веб-сайт Wordpress.

Наявність xmlrpc можна використовувати для виявлення, але знову ж таки це можна відключити.

І нарешті, навіть якщо ви повністю отримуєте URL-адресу, все одно не можна на 100% визначити, чи створена сторінка за допомогою wordpress. Все залежить від шаблону теми та способу його розвитку.

Один досить надійний спосіб - шукати наявність wp-login та wp-admin. Але навіть їх можна також перемістити. Я хотів би піти цим шляхом.

Дві альтернативи коментарям, встановіть власний заголовок WordPress. Залиште це у function.php теми.

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

header('Type: WordPress');
}

Сканер відбитків пальців WP (рубін), він проходить кілька кроків, щоб спробувати встановити, чи використовується WordPress, наприклад, пошук каталогу плагінів, назви теми, метатегів, readme тощо (я не маю уявлення, наскільки це насправді це насправді ). http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Як щодо надсилання головного запиту до одного з файлів, починаючи з префіксу wp-. Ідеально дивіться на wp-login.php. Якщо він існує, це означає, що на веб-сайті працює WordPress.