จัดการคำขอ IIS อย่างเหมาะสมด้วยเปอร์เซ็นต์การลงชื่อเข้าใช้ URL (/%)

ฉันกำลังมองหาวิธีการแก้ปัญหาใด ๆ เพื่อรับคำขอ IIS อย่างถูกต้องเช่น/programming//%และhttp://bing.com/%เพื่อไม่แสดงหน้า 400 คำขอไม่ถูกต้อง แต่แสดงหน้าข้อผิดพลาดที่กำหนดเอง คล้ายกับวิธีที่http://google.com/%และhttp://facebook.com/%ทำ (แน่นอนว่าตัวอย่างเหล่านั้นไม่ได้อยู่ใน IIS)

ฉันเชื่อว่าฉันได้ลองตั้งค่าการตั้งค่ารีจิสทรี http.sys ทั้งหมด (AllowRestrictedChars, PercentUAllowed) ต่อhttp://support.microsoft.com/kb/820129แต่ไม่ได้ช่วย การตั้งค่า AllowRestrictedChars และหน้า 400 ที่กำหนดเองมี URL คงที่เช่น/programming//%12แต่ไม่ใช่ /%

สิ่งนี้ถูกบล็อกในระดับเคอร์เนล IIS จากการทดสอบฉันดึงทุกโมดูลใน IIS ออกมาเพื่อที่จะไม่ได้มีตัวจัดการหน้าเว็บแบบสแตติกและยังคงแสดงข้อความแสดงข้อผิดพลาด 400 ข้อ

ฉันไม่เชื่อว่าเป็นไปได้ที่ IIS จะหลีกเลี่ยงปัญหานั้น การตั้งค่ารีจิสทรีที่คุณกล่าวถึงมีไว้สำหรับอักขระที่ จำกัด ประเภทอื่น ฉันไม่เห็นคันโยกที่จะเปลี่ยนฟังก์ชั่นนั้น

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

Update2: นี่คือลิงค์ยอดเยี่ยมสามลิงก์ ทั้ง Nazim Lala และ Wade Hilmo จากทีม IIS ได้บล็อกเกี่ยวกับเรื่องนี้เนื่องจากการอภิปรายรอบคำถามของคุณ Scott Hanselman ก็มีโพสต์ที่ยอดเยี่ยมในส่วนของการสืบค้นภายใน. NET:

• การใช้อักขระพิเศษใน IIS - Nazim Lala
• IIS บล็อกอักขระใน URL อย่างไร - ลุย Hilmo
• การทดลองใน Wackiness - Scott Hanselman

อัปเดต: ฉันตรวจสอบกับสมาชิกของทีม IIS เพื่อรับคำตอบที่มีสิทธิ์ เขากล่าวว่า% ถือเป็นตัวละครที่ไม่ปลอดภัยตาม RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt )

นี่คือข้อความที่เกี่ยวข้อง:

ที่ไม่ปลอดภัย:

ตัวละครอาจไม่ปลอดภัยด้วยเหตุผลหลายประการ อักขระช่องว่างไม่ปลอดภัยเนื่องจากช่องว่างที่สำคัญอาจหายไปและอาจมีช่องว่างที่ไม่สำคัญเมื่อมีการคัดลอก URL หรือเรียงพิมพ์หรืออยู่ภายใต้การดูแลของโปรแกรมประมวลผลคำ อักขระ "<" และ ">" ไม่ปลอดภัยเนื่องจากถูกใช้เป็นตัวคั่นรอบ ๆ URL เป็นข้อความอิสระ เครื่องหมายอัญประกาศ ("" ") ใช้เพื่อคั่น URL ในบางระบบอักขระ" # "ไม่ปลอดภัยและควรเข้ารหัสเสมอเนื่องจากมีการใช้ใน World Wide Web และในระบบอื่น ๆ เพื่อคั่น URL จากแฟรกเมนต์ / จุดยึด ตัวระบุที่อาจตามมา ตัวละคร "%" ไม่ปลอดภัยเพราะใช้สำหรับการเข้ารหัสอักขระอื่น อักขระอื่น ๆ ไม่ปลอดภัยเนื่องจากบางครั้งเกตเวย์และเอเจนต์การขนส่งอื่น ๆ บางครั้งอาจแก้ไขอักขระดังกล่าว อักขระเหล่านี้คือ "{", "}", "|", "\", "^", "~", "[", "]" และ "` "

อักขระที่ไม่ปลอดภัยทั้งหมดจะต้องถูกเข้ารหัสภายใน URL เสมอ ตัวอย่างเช่นตัวอักษร "#" จะต้องเข้ารหัสภายใน URL แม้ในระบบที่ปกติจะไม่จัดการกับตัวระบุส่วนหรือจุดยึดดังนั้นหากคัดลอก URL ไปยังระบบอื่นที่ใช้พวกเขาจะไม่จำเป็นต้องเปลี่ยน การเข้ารหัส URL

ดังนั้น IIS จะป้องกันสิ่งนี้ในระดับแกนกลางซึ่งเป็นมาตรการรักษาความปลอดภัยเชิงรุกเพื่อลดพื้นที่การโจมตี

ฉันคิดได้ 3 วิธี

1. เปลี่ยน IIS ให้ชี้ไปที่หน้ากำหนดเองสำหรับข้อผิดพลาด 400 กว่าปกติ

2. หากนี่เป็นเว็บไซต์เฉพาะใน IIS คุณสามารถทำสิ่งนี้ได้ใน web.config:

   <customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
   <error statusCode = "400" redirect = "myCustom400Error.aspx" />
   </customErrors>

3. เขียน httpModule ที่ตรวจสอบ URL ที่เข้ามาและจัดการมัน

วิธีเดียวในการแก้ปัญหานี้คือการตรวจสอบ URL ก่อนที่เคอร์เนล IIS จะทำได้

คุณจะต้องส่งลิงค์ที่สร้างขึ้นแบบไดนามิกผ่านสคริปต์เพื่อตรวจสอบก่อนที่จะส่งต่อผู้ใช้ปลายทางไปยัง URL นั้น ...

นอกจากนี้คุณจะรู้ว่านี่เป็นสถานการณ์เดียวที่ IIS ไม่จัดการตามที่คุณต้องการ ถ้าคุณมีคำขอที่ไม่สามารถจัดการได้คุณจะรู้ว่าอะไรเป็นสาเหตุ

บางทีการตรวจสอบผู้อ้างอิงในหน้า 400 ที่กำหนดเองน่าจะช่วยลดแหล่งที่มาของการเข้าชมให้แคบลงได้ไหม

โพสต์นี้ในฟอรัม IIS ระบุว่า HTTP 400 (คำขอไม่ถูกต้อง) ถูกบล็อกโดย http.sys และไม่ส่งไปที่ IIS ซึ่งตรงกับลิงก์ที่ @Scott Forsyth - MVP รวมอยู่ในคำตอบดั้งเดิมของเขา

คุณสามารถดูบันทึกของคำขอเหล่านี้ได้ภายใต้ c: \ Windows \ System32 \ LogFiles \ HTTPERR \

ฉันไม่ทราบว่าคุณสามารถกำหนดค่าหน้าการตอบสนองที่ส่งกลับไปยังผู้ใช้สำหรับข้อผิดพลาดประเภทนี้ได้หรือไม่เนื่องจากแม้ Bing ประสบปัญหานี้ฉันสงสัยว่าอาจเป็นไปไม่ได้หรืออาจต้องการแฮ็คระบบที่น่ากลัว