เมื่อพิจารณาว่าการพัฒนา ASP สามารถใช้สองภาษาได้: vbs และ js รหัสโปรแกรมทั้งสองภาษามีให้ที่นี่ (เวอร์ชันสองภาษา กลาง YY...) ประโยคคำสุดท้ายหนึ่งเครื่องที่ผมใช้พิมพ์บทความนี้ไม่มี สภาพแวดล้อม ASP ดังนั้นจึงไม่ได้ทดสอบโค้ดที่ให้มา และฉันขออภัยสำหรับสิ่งนั้น หากคุณพบปัญหาใด ๆ ในโค้ด โปรดแสดงความคิดเห็นได้~ฉันมีผิวที่หนา~
1. หลักการโจมตี
การปลอมแปลงคุกกี้ใช้ประโยชน์จากแนวปฏิบัติที่ไม่ปลอดภัยในการจัดเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้ในคุกกี้โดยระบบการจัดการผู้ใช้บางระบบในเครือข่ายปัจจุบัน วิธีการโจมตีนั้นค่อนข้างยากเมื่อเทียบกับช่องโหว่เช่นช่องโหว่การฉีด SQL แต่ก็ยังโง่มาก
เรารู้ว่าระบบผู้ใช้ทั่วไปที่ใช้คุกกี้จะจัดเก็บตัวแปรอย่างน้อยสองตัวในคุกกี้ ได้แก่ ชื่อผู้ใช้และระดับผู้ใช้ โดยที่ชื่อผู้ใช้คือชื่อผู้ใช้ และระดับผู้ใช้คือระดับของผู้ใช้ เมื่อเบราว์เซอร์ของเราเข้าถึงหน้า ASP มันจะส่งออกสิ่งที่ต้องการ
รับ /.../file.asp HTTP 1.0
-
คุกกี้: ชื่อผู้ใช้=user&userlevel=1
-
แพ็คเก็ต ตราบใดที่เราทราบชื่อผู้ใช้และค่าระดับผู้ใช้ของผู้ดูแลระบบ (สมมติว่าเป็นผู้ดูแลระบบและ 5 ตามลำดับ) เราก็สามารถส่งได้
รับ /.../file.asp HTTP 1.0
-
คุกกี้: ชื่อผู้ใช้=admin&userlevel=5
-
เพื่อรับสิทธิ์ผู้ดูแลระบบ ง่ายมากใช่มั้ย? อย่างไรก็ตาม ก่อนที่จะค้นพบช่องโหว่นี้ ระบบการจัดการผู้ใช้เกือบทั้งหมดอาศัยคุกกี้
2. จัดเก็บข้อมูลผู้ใช้อย่างปลอดภัย
เนื่องจากคุกกี้ไม่ปลอดภัย และเราต้องจัดเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้ ควรเก็บไว้ที่ใด
เราสังเกตเห็นว่าใน ASP นอกจาก Cookies แล้ว ยังมี Session ที่สามารถเก็บข้อมูลได้อีกด้วย เซสชันถูกจัดเก็บไว้บนเซิร์ฟเวอร์และไคลเอ็นต์ไม่สามารถเปลี่ยนแปลงแบบไม่ได้ตั้งใจได้ จึงมีความปลอดภัยสูงมาก ด้วยวิธีนี้ คุณสามารถแทนที่รหัสคุกกี้ทั้งหมดด้วยเซสชันได้
3. เก็บข้อมูลผู้ใช้ไว้เป็นเวลานาน
การใช้เซสชันเพื่อบันทึกข้อมูลการเข้าสู่ระบบของผู้ใช้ แม้ว่าจะกำจัดปัญหาการหลอกลวงคุกกี้ แต่เซสชันไม่สามารถจัดเก็บได้เป็นเวลานาน (เซสชันเริ่มต้นของ IIS จะหมดอายุ 20 นาทีหลังจากที่ผู้ใช้หยุดตอบสนอง) ดังนั้นวิธีการจัดเก็บข้อมูลแบบไฮบริดของคุกกี้ + เซสชันจึงอธิบายไว้ ในส่วนนี้มีการผลิต.
วิธีการนี้มีสองรูปแบบ วิธีแรกคือการจัดเก็บชื่อผู้ใช้และรหัสผ่านในคุกกี้ ถูกอ่านและข้อมูลที่ให้ไว้ในคุกกี้จะถูกใช้เข้าสู่ระบบอย่างทึบด้วยชื่อผู้ใช้และรหัสผ่านของคุณเพื่อตรวจสอบว่าเนื้อหาในคุกกี้นั้นถูกกฎหมายหรือไม่ เนื้อหานั้นจะถูกจัดเก็บไว้ในเซสชัน รหัสที่จะใช้วิธีนี้มีดังนี้:
คำกริยา:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
ชื่อผู้ใช้ รหัสผ่าน สลัว
ชื่อผู้ใช้ = เซสชัน (ชื่อผู้ใช้)
ถ้าชื่อผู้ใช้ = แล้ว
' ไม่มีข้อมูลการเข้าสู่ระบบของผู้ใช้ในเซสชัน
ชื่อผู้ใช้ = คำขอคุกกี้ (ชื่อผู้ใช้)
รหัสผ่าน = คำขอคุกกี้ (รหัสผ่าน)
' โปรดทราบว่าชื่อผู้ใช้และรหัสผ่านที่ได้รับในสองประโยคข้างต้นจะต้องได้รับการป้องกันจากช่องโหว่ของการแทรก SQL (นั่นคือ เครื่องหมายคำพูดเดี่ยวจะถูกกรองออก') ซึ่งละไว้ที่นี่
ถ้าชื่อผู้ใช้ = หรือรหัสผ่าน = แล้ว
'ผู้ใช้ไม่ได้เข้าสู่ระบบ'
-
อื่น
' นี่ถือว่ามีการสร้างอ็อบเจ็กต์ conn และ rs
rs.Open เลือก TOP 1 * จาก [ผู้ใช้] WHERE ชื่อผู้ใช้=' & ชื่อผู้ใช้ & ' และรหัสผ่าน=' & รหัสผ่าน & ', conn, 1, 3
ถ้า rs.eof แล้ว
'ข้อมูลในคุกกี้เป็นสิ่งผิดกฎหมาย
-
อื่น
'ข้อมูลในคุกกี้ถูกกฎหมาย เข้าสู่ระบบโดยอัตโนมัติ
เซสชั่น(ชื่อผู้ใช้) = ชื่อผู้ใช้
-
สิ้นสุดถ้า
สิ้นสุดถ้า
อื่น
'ข้อมูลผู้ใช้มีอยู่แล้วในเซสชัน โปรดอ่านโดยตรง'
-
สิ้นสุดถ้า
-
js:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
ชื่อผู้ใช้, รหัสผ่าน;
ชื่อผู้ใช้ = เซสชัน (ชื่อผู้ใช้) + ;
ถ้า (ชื่อผู้ใช้ == || ชื่อผู้ใช้ == ไม่ได้กำหนด) {
// ไม่มีข้อมูลผู้ใช้ในเซสชัน
ชื่อผู้ใช้ = คำขอคุกกี้ (ชื่อผู้ใช้) + ;
รหัสผ่าน = คำขอคุกกี้ (รหัสผ่าน) + ;
// โปรดทราบว่าชื่อผู้ใช้และรหัสผ่านที่ได้รับในสองประโยคข้างต้นจำเป็นต้องป้องกันช่องโหว่ในการแทรก SQL (นั่นคือ กรองเครื่องหมายคำพูดเดี่ยว ') ซึ่งไม่ได้ระบุไว้ที่นี่
ถ้า (ชื่อผู้ใช้ == || ชื่อผู้ใช้ == ไม่ได้กำหนด || รหัสผ่าน == || รหัสผ่าน == ไม่ได้กำหนด) {
//ผู้ใช้ไม่ได้เข้าสู่ระบบ
-
-
อื่น {
// นี่ถือว่ามีการสร้างวัตถุ conn และ rs
rs.Open(เลือก TOP 1 * จาก [ผู้ใช้] โดยที่ชื่อผู้ใช้=' + ชื่อผู้ใช้ + 'และรหัสผ่าน=' + รหัสผ่าน + ', conn, 1, 3);
ถ้า (rs.eof) {
//ข้อมูลในคุกกี้เป็นสิ่งผิดกฎหมาย
-
-
อื่น {
//ข้อมูลใน Cookies ถูกกฎหมาย เข้าสู่ระบบโดยอัตโนมัติ
เซสชัน (ชื่อผู้ใช้) = ชื่อผู้ใช้ + ;
-
-
-
-
อื่น {
// ข้อมูลผู้ใช้มีอยู่แล้วในเซสชัน โปรดอ่านโดยตรง
-
-
-
อย่างไรก็ตาม วิธีการนี้ไม่ปลอดภัยสำหรับผู้ใช้มากนัก เนื่องจากเบราว์เซอร์จะส่งคุกกี้ทุกครั้งที่เข้าชมเพจ และเมื่อผู้อื่นได้รับคุกกี้ที่มีรหัสผ่านแล้ว บัญชีผู้ใช้จะถูกขโมย สำหรับสถานการณ์นี้ มีวิธีที่สองคือการเพิ่มรหัสยืนยันฟิลด์ในฐานข้อมูลข้อมูลผู้ใช้ เมื่อผู้ใช้เข้าสู่ระบบ ค่าการตรวจสอบจำนวนเต็มยาวจะถูกสร้างขึ้นแบบสุ่มและจัดเก็บไว้ในฟิลด์รหัสยืนยัน และชื่อผู้ใช้และรหัสยืนยันนี้ เพิ่มมูลค่าแล้ว เก็บคุกกี้แทนรหัสผ่าน เมื่อตรวจสอบข้อมูลผู้ใช้ในคุกกี้ จะมีการตรวจสอบเฉพาะชื่อผู้ใช้และรหัสยืนยันเท่านั้น ข้อดีของวิธีนี้คือแม้ว่าแฮกเกอร์จะได้รับคุกกี้ของผู้ใช้ เขาสามารถใช้เพียงรหัสยืนยันที่สร้างขึ้นชั่วคราวเพื่อเข้าสู่ระบบเท่านั้น แต่ไม่สามารถรับรหัสผ่านของผู้ใช้ได้ ตราบใดที่ผู้ใช้รายนี้เข้าสู่ระบบโดยใช้ชื่อผู้ใช้และรหัสผ่านอีกครั้ง ค่ารหัสยืนยันจะเปลี่ยนไป และแฮกเกอร์จะไม่สามารถเข้าสู่ระบบผ่านรหัสยืนยันเดิมได้
การใช้วิธีนี้ต้องการการเปลี่ยนแปลงโค้ดของวิธีที่ 1 ข้างต้นเพียงเล็กน้อยเท่านั้น ขั้นแรก ในโปรแกรมเข้าสู่ระบบของคุณ คุณจะต้องเพิ่มย่อหน้าที่จัดเก็บข้อมูลผู้ใช้หลังจากการตรวจสอบ:
คำกริยา:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
Response.Cookies (รหัสยืนยัน) = int (rnd * 2100000000)
-
js:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
Response.Cookies(รหัสยืนยัน) = Math.floor(Math.random() * 2100000000);
-
จากนั้นเปลี่ยนการตรวจสอบคุกกี้ (รหัสผ่าน) เป็นการตรวจสอบคุกกี้ (รหัสยืนยัน) ในรหัสยืนยันที่ให้ไว้ข้างต้น
4. บทสรุป
ด้วยการวิเคราะห์และการประมวลผลของเรา ช่องโหว่ของการปลอมแปลงคุกกี้ได้รับการแก้ไขอย่างสมบูรณ์ตั้งแต่นั้นมา โปรแกรม ASP ของเราก็มีความปลอดภัยมากขึ้น