กำลังตรวจจับ 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 ที่ฉันเห็น

มีการประชุมร่วมกันทั่วไปสำหรับ 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จะน่าเชื่อถือเป็นพิเศษและเป็นสิ่งเดียวที่ฉันเห็นในส่วนหัวที่จะช่วยได้ดังนั้นอาจมีส่วนหัว HTTP ทั่วไปที่เป็นศูนย์ในการติดตั้ง WordPress ใช่ไหม

จากประสบการณ์และการค้นหารหัสอย่างรวดเร็วของฉันไม่มีเจตนาระบุวิธี 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

ชื่อคุกกี้สามารถปรับแต่งได้โดยการกำหนด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 คุณจะได้รับส่วนหัวของการตอบสนองที่มีสตริงLocationfeed

ในตัวอย่างของ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 redirect สำหรับบล็อก 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 จะไม่มีหน้าเว็บที่มี ID เท่ากับ -1 ดังนั้นจึงมีการให้บริการ 404 / การเปลี่ยนเส้นทางแทน

ไม่มี wp-super-cache พร้อมใช้งานในการติดตั้ง wordpress ทั้งหมดและไม่มีรูปแบบคงที่ใน URL ในขณะที่หน้าการตั้งค่าลิงก์ถาวรจะให้การตั้งค่าคงที่บางส่วนสำหรับชุด URL ซึ่งสามารถใช้ได้ทุกคนสามารถใช้ชุดรูปแบบ URL ที่กำหนดเองได้ ตัวอย่างเช่นหากใครก็ตามตัดสินใจที่จะใช้เฉพาะชื่อหน้า / โพสต์ใน URL มันเป็นไปไม่ได้ที่จะคิดว่ามันเป็นเว็บไซต์ Wordpress มากหรือน้อย

การปรากฏตัวของ xmlrpc สามารถใช้ในการตรวจจับ แต่อีกครั้งนี้สามารถปิดการใช้งาน

และในที่สุดแม้ว่าคุณจะใช้ URL อย่างสมบูรณ์ แต่ก็ยังไม่สามารถตรวจพบได้ 100% หากหน้านั้นสร้างขึ้นโดยใช้เวิร์ดเพรส ทุกอย่างขึ้นอยู่กับเทมเพลตธีมและวิธีการพัฒนา

วิธีหนึ่งที่น่าเชื่อถือพอสมควรคือการค้นหาการมีอยู่ของ wp-login และ wp-admin แต่สิ่งเหล่านี้ก็สามารถเคลื่อนไหวได้เช่นกัน ฉันจะไปด้วยวิธีนี้แม้ว่า

สองทางเลือกในการแสดงความคิดเห็นตั้งค่าส่วนหัว WordPress ของคุณเอง วางสิ่งนี้ลงในฟังก์ชั่นของธีมของคุณ

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

header('Type: WordPress');
}

WP scan fingerprinter (ruby) มันผ่านหลายขั้นตอนในการลองและคิดออกว่ากำลังใช้งาน WordPress หรือไม่เช่นการค้นหาไดเรกทอรีปลั๊กอินชื่อธีมแท็กเมตาแท็ก readme และอื่น ๆ (ฉันไม่รู้ว่านี่เป็นเรื่องจริง ) http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

วิธีการเกี่ยวกับการส่งการร้องขอหัวไปยังหนึ่งในไฟล์ที่เริ่มต้นด้วยคำนำหน้า wp- ดูที่ wp-login.php หากมีอยู่นั่นหมายความว่าเว็บไซต์กำลังใช้งาน WordPress