เมื่อพูดถึงการเข้ารหัส URL คุณอาจนึกถึงช่องโหว่ในการเข้ารหัส URL เมื่อหลายปีก่อน น่าเสียดายที่ฉันเกิดผิดเวลา พอมาเจอกับอินเตอร์เน็ต ช่องโหว่ก็หายไปนานแล้ว
ใกล้บ้านมากขึ้น การเข้ารหัส URL คืออะไร ดูคำจำกัดความที่ฉันคัดลอกมาจากอินเทอร์เน็ต:
ข้อความอ้างอิง: การเข้ารหัส URL เป็นรูปแบบที่เบราว์เซอร์ใช้ในการป้อนข้อมูลแบบฟอร์มแพ็คเกจ เบราว์เซอร์รับชื่อและค่าทั้งหมดจากแบบฟอร์มและส่งไปยังเซิร์ฟเวอร์โดยเป็นส่วนหนึ่งของ URL หรือแยกกันโดยใช้การเข้ารหัสพารามิเตอร์ชื่อ/ค่า (การลบอักขระที่ไม่สามารถส่งผ่านได้ การเรียงลำดับข้อมูล ฯลฯ ) ไม่ว่าในกรณีใด รูปแบบการป้อนแบบฟอร์มบนฝั่งเซิร์ฟเวอร์จะมีลักษณะดังนี้:
theName=Ichabod+Crane&gender=male&status=missing&headless=yes
การเข้ารหัส URL เป็นไปตามกฎต่อไปนี้: แต่ละคู่ชื่อ/ค่าจะถูกคั่นด้วยเครื่องหมายแอมเปอร์แซนด์ แต่ละคู่ของชื่อ/ค่า มาจากรูปแบบคั่นด้วยอักขระ = หากผู้ใช้ไม่ป้อนค่าสำหรับชื่อ ชื่อจะยังคงปรากฏ แต่ไม่มีค่า อักขระพิเศษใดๆ (นั่นคือ อักขระที่ไม่ใช่ ASCII เจ็ดบิตธรรมดา เช่น อักขระจีน) จะถูกเข้ารหัสเป็นเลขฐานสิบหกพร้อมเครื่องหมายเปอร์เซ็นต์ % รวมถึงอักขระพิเศษ เช่น =, & และ % ด้วย
ฮ่าฮ่า คุณคงเข้าใจแล้วว่า ที่จริงแล้วการเข้ารหัส URL เป็นรหัส ASCII เลขฐานสิบหกของอักขระ อย่างไรก็ตาม มีการเปลี่ยนแปลงเล็กน้อย คุณต้องเพิ่ม "%" ข้างหน้า ตัวอย่างเช่น "" รหัส ASCII ของมันคือ 92 และค่าเลขฐานสิบหกของ 92 คือ 5c ดังนั้นการเข้ารหัส URL ของ "" จึงเป็น แล้วการเข้ารหัส URL ของตัวอักษรจีนล่ะ? ง่ายมาก ดูตัวอย่าง: รหัส ASCII ของ "Hu" คือ -17670 เลขฐานสิบหกคือ BAFA และการเข้ารหัส URL คือ "%BA%FA" ฮ่าๆ รู้วิธีแปลงแล้วสินะ
โดยปกติเราจะไม่ใช้การเข้ารหัส URL เนื่องจาก IE จะแปลงตัวอักษรที่ไม่ใช่ตัวเลขที่คุณป้อนลงในแถบที่อยู่เป็นการเข้ารหัส URL โดยอัตโนมัติ ดังนั้นสำหรับเบราว์เซอร์ http://blog.csdn.net/l%61ke2 เทียบเท่ากับ http://blog.csdn.net/lake2 (โปรดทราบว่าฉันแทนที่ a ด้วย %61 ใน URL แรก) ฮ่าๆ บางทีคุณอาจจำได้ว่ามีคนแนะนำให้เพิ่ม "#" ในชื่อฐานข้อมูลเพื่อป้องกันไม่ให้ดาวน์โหลด เพราะ IE จะเพิกเฉยต่อตัวอักษรต่อไปนี้เมื่อเจอกับ # วิธีการแคร็กนั้นง่ายมาก - แทนที่ # ด้วยการเข้ารหัส url # เดิมทีฉันพยายามใช้การเข้ารหัส URL เพื่อหลีกเลี่ยงการตรวจสอบการฉีด แต่ล้มเหลวเนื่องจากเซิร์ฟเวอร์จะแปลงการเข้ารหัส URL เป็นอักขระ
เดี๋ยว ดูเหมือนฉันจะนอกประเด็น 555 ขออภัย :)
SQL injector ได้รับความนิยมอย่างมากในขณะนี้ ดังนั้นบางคนจึงได้เขียนสคริปต์ป้องกันการแทรกไว้ แน่นอนว่าแนวคิดต่างกันและผลลัพธ์ก็ต่างกันมาก เรียนผู้อ่าน โปรดดูส่วนหนึ่งของโค้ดของ ××SQL universal anti-injection asp เวอร์ชันด้านล่าง
Fy_Url=Request.ServerVariables("QUERY_STRING")
Fy_a=แยก(Fy_Url,"&")
ทำซ้ำ Fy_Cs(ubound(Fy_a))
เมื่อเกิดข้อผิดพลาด ดำเนินการต่อต่อไป
สำหรับ Fy_x=0 ถึง ubound(Fy_a)
Fy_Cs(Fy_x) = ซ้าย(Fy_a(Fy_x),instr(Fy_a(Fy_x),"=")-1)
ต่อไป
สำหรับ Fy_x=0 ถึง ubound(Fy_Cs)
ถ้า Fy_Cs(Fy_x)<>"" จากนั้น
ถ้า Instr(LCase(Request(Fy_Cs(Fy_x))),"and")<>0 แล้ว
ตอบกลับเขียนว่า "เกิดข้อผิดพลาด!"
การตอบสนองสิ้นสุด
สิ้นสุดถ้า
สิ้นสุดถ้า
ต่อไป
แนวคิดคือการรับข้อมูลที่ส่งมาก่อน ใช้ "&" เป็นเครื่องหมายแบ่งเขตเพื่อรับและประมวลผลกลุ่มชื่อ/ค่า จากนั้นพิจารณาว่าค่านั้นมีคีย์เวิร์ดที่กำหนดไว้หรือไม่ (เพื่อความง่ายในที่นี้ ฉันเหลือเพียง "และ") เท่านั้น ถ้าเป็นเช่นนั้นก็เป็นการฉีด
เมื่อดูแวบแรก จะมีการตรวจสอบค่าแล้วและดูเหมือนว่าจะไม่มีปัญหาใดๆ ฮ่าๆ ใช่ครับ ไม่มีปัญหาเรื่องค่า แต่ชื่อล่ะ?
ค่ากลุ่มชื่อ/ค่ามาจาก Request.ServerVariables("QUERY_STRING") ฮ่าๆ ขออภัย มีข้อผิดพลาดเกิดขึ้นที่นี่ Request.ServerVariables("QUERY_STRING") คือการรับสตริงที่ลูกค้าส่งมา การเข้ารหัส URL จะไม่ถูกแปลงโดยอัตโนมัติที่นี่ ฮ่าๆ ถ้าเราเข้ารหัส URL แล้วส่ง ฮ่าๆ เช็คก็ข้ามไปได้ ตัวอย่างเช่น หากพารามิเตอร์คือ ph4nt0m=lake2 และ lis0 โปรแกรมสามารถตรวจจับได้ในขณะนี้ หากคุณส่ง %50h4nt0m=lake2 และ lis0 (การเข้ารหัส URL p) โปรแกรมจะตัดสินค่าของ %50h4nt0m และ %50h4nt0m จะถูกแปลงเป็น ph4nt0m ดังนั้นค่า %50h4nt0m จึงว่างเปล่า จึงข้ามการตรวจจับ
เดี๋ยวก่อน เหตุใดจึงสามารถข้ามการตรวจสอบได้ ในเมื่อชื่อไม่ได้ถอดรหัส แต่ค่าไม่สามารถข้ามได้ เนื่องจากค่าของค่าถูกนำมาจาก Request(Fy_Cs(Fy_x)) เซิร์ฟเวอร์จะถอดรหัส
จะปรับปรุงโปรแกรมได้อย่างไร? ตราบใดที่คุณสามารถรับข้อมูลที่ถอดรหัสที่ส่งโดยไคลเอนต์ เพียงแค่เปลี่ยนคำสั่งเพื่อให้ได้ชื่อเป็น For Each SubsName In Request.QueryString
ฮ่าๆ ขอบคุณที่อดทนอ่านบทความของผมนะครับ^_^
lake2