Обнаружение 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-here

Но это тоже не универсальная константа.

Я попытался просмотреть заголовки этого 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недостаточно безопасно. Любой может дать это имя файлу.

Предостережение: 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-cache не доступен во всех установках WordPress, ни фиксированный формат в URL-адресах. Хотя на странице настроек постоянных ссылок есть некоторые фиксированные настройки для схем URL, которые можно использовать, любой может просто использовать любую схему URL. Например, если кто-то просто решит использовать в URL-адресе только имя страницы / публикации, выяснить, является ли это веб-сайтом Wordpress, более или менее невозможно.

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

И, наконец, даже если вы ввели полный URL-адрес, все еще невозможно на 100% определить, была ли страница построена с использованием WordPress. Все зависит от шаблона темы и от того, как он разрабатывается.

Одним из достаточно надежных способов является поиск присутствия wp-login и wp-admin. Но даже они также могут быть перемещены. Я бы пошел по этому пути, хотя.

Две альтернативы комментариям, установите свой собственный заголовок WordPress. Оставьте это в functions.php вашей темы.

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

header('Type: WordPress');
}

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

Как насчет отправки заголовка запроса в один из файлов, начинающийся с префикса wp-. В идеале посмотрите wp-login.php. Если он существует, это означает, что веб-сайт работает под управлением WordPress.