Phát hiện URL WordPress mà không thực hiện HTTP GET đầy đủ?

Tôi đang cố gắng viết một thói quen oneboxing để cung cấp cho các mục blog WordPress điều trị đặc biệt. Vì vậy, được cung cấp một URL đơn giản, không được cung cấp trong nội dung, chẳng hạn như

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

Làm cách nào tôi có thể phát hiện ra rằng đây là bản cài đặt WordPress, lý tưởng nhất là không thực hiện HTTP GET đầy đủ trên mỗi URL tôi thấy?

Chắc chắn có các quy ước chung cho các URL WordPress mà chúng ta có thể bắt đầu, loại bỏ ít nhất một số URL khỏi sự tranh chấp. Trong trường hợp này là ...

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

Nhưng đó cũng không phải là một hằng số phổ quát.

Tôi đã thử nhìn vào các tiêu đề của URL đó bằng HTTP Head và tôi thấy:

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

Tôi không nghĩ việc dựa vào sự hiện diện của WP-Super-Cachenó sẽ đặc biệt đáng tin cậy và đó là điều duy nhất tôi thấy trong các tiêu đề có thể giúp ích, vì vậy có lẽ không có tiêu đề HTTP phổ biến nào trong cài đặt WordPress?

Từ kinh nghiệm của tôi và tìm kiếm mã nhanh, không có cách nào có chủ ý mà WP tự nhận diện trong các tiêu đề. Tuy nhiên, có một số dường như đủ khác biệt và không có khả năng được tùy chỉnh.

Đầu /wp-login.phpsẽ chứa sau đây để cài đặt .org:

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

Và cho .com:

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

Tên cookie có thể tùy chỉnh bằng cách xác định TEST_COOKIEhằng số, nhưng WP Cookie checkchuỗi được mã hóa cứng trong lõi, cũng như set_cookie()gọi mã này trong nguồn của tệp.

Để định vị, wp-login.phpcó một số phím tắt URL (được triển khai wp_redirect_admin_locations()từ WP 3.4 (xem vé # 19607 ):

/logintrên trang web gốc không 302chuyển hướng đến wp-login.php, bất cứ nơi nào nó có.

Vì vậy, kịch bản duy nhất không thể được phát hiện một cách đáng tin cậy nếu WP được cài đặt và giới hạn trong thư mục con, mà không được sử dụng để quản lý root của trang web.

Gửi HEADyêu cầu đến /wp-feed.phptrong cùng thư mục với /xmlrpc.php(ngay cả trong cài đặt thư mục con). Trong WordPress, bạn sẽ nhận được một Locationtiêu đề là phản hồi có chứa chuỗi feed.

Trong ví dụ của blog.stackoverflow.combạn, bạn sẽ nhận được:

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

Sự tồn tại của một tập tin xmlrpc.phpmột mình là không đủ an toàn. Bất cứ ai cũng có thể cung cấp tên này cho một tập tin.

Hãy cẩn thận: X-PingbackTiêu đề có thể được vô hiệu hóa bằng cách lọc 'wp_headers'. Vì vậy, đề nghị của tôi không phải là chống đạn.

Liên quan: Các bước cần thực hiện để che giấu sự thật một trang web đang sử dụng WordPress?

Nối URL với ?page_id=-1và thực hiện yêu cầu HTTP Head cho điều đó.

Trên các blog WordPress tự cài đặt, điều này sẽ dẫn đến phản hồi 404.

Trên blog wordpress.com, điều này sẽ dẫn đến phản hồi 301 (kết thúc là 200 phản hồi nếu bạn thực hiện theo chuyển hướng).

Trên các trang web không phải WordPress, bạn sẽ nhận được 200 phản hồi (giả sử URL gốc không có chuỗi truy vấn cung cấp cho bạn 200) - chuỗi truy vấn sẽ không có sự khác biệt.

Ví dụ với yêu cầu CHÍNH cho 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

Ví dụ với yêu cầu CHÍNH cho http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(tắt chuyển hướng theo dõi):

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

(Lưu ý trứng Phục sinh X-Hacker!)

Nếu bạn theo dõi chuyển hướng 301 cho blog wordpress.com, bạn sẽ kết thúc với điều này:

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.

Lưu ý tiêu đề "Liên kết" có chứa http://wp.me/URL, dường như phổ biến đối với tất cả các blog được lưu trữ trên wordpress.com và có thể được sử dụng để xác định chúng.

Tôi tin rằng điều này hoạt động vì chuyển qua ?page_id=-1URL ghi đè định tuyến mặc định từ các phân đoạn URL. Sẽ không có trang nào có ID là -1 và thay vào đó, 404 / redirect được cung cấp.

Cả wp-super-cache đều không có sẵn trên tất cả các cài đặt wordpress, cũng không có bất kỳ định dạng cố định nào trong các URL. Mặc dù trang cài đặt permalinks cung cấp một số cài đặt cố định cho các lược đồ URL có thể được sử dụng, bất kỳ ai cũng có thể sử dụng bất kỳ lược đồ URL tùy chỉnh nào. Ví dụ: nếu bất kỳ ai chỉ quyết định chỉ sử dụng tên trang / bài đăng trong URL, thì ít nhiều không thể biết được đó có phải là trang web Wordpress hay không.

Sự hiện diện của xmlrpc có thể được sử dụng để phát hiện, nhưng một lần nữa, điều này có thể bị vô hiệu hóa.

Và cuối cùng, ngay cả khi bạn thực hiện đầy đủ trên URL, vẫn không thể phát hiện 100% nếu trang được xây dựng bằng wordpress. Tất cả phụ thuộc vào mẫu chủ đề và cách nó được phát triển.

Một cách khá đáng tin cậy là tìm kiếm sự hiện diện của wp-login và wp-admin. Nhưng ngay cả những điều này cũng có thể được di chuyển. Tôi sẽ đi theo cách này mặc dù.

Hai lựa chọn thay thế cho các bình luận, đặt tiêu đề WordPress của riêng bạn. Thả cái này trong các chức năng của chủ đề của bạn.php.

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

header('Type: WordPress');
}

Công cụ quét ngón tay quét WP (ruby), nó trải qua nhiều bước để thử và xem liệu WordPress có đang được sử dụng như tìm thư mục plugin, tên chủ đề, thẻ meta, readme, v.v. (Tôi không biết điều này thực sự chính xác đến mức nào ). http://code.google.com.vn/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Làm thế nào về việc gửi yêu cầu đầu đến một trong các tệp bắt đầu bằng tiền tố wp-. Lý tưởng nhất là nhìn vào wp-login.php. Nếu nó tồn tại có nghĩa là trang web đang chạy WordPress.