1. หลักการโจมตี
การปลอมแปลงคุกกี้ส่วนใหญ่ใช้วิธีปฏิบัติที่ไม่ปลอดภัยในการจัดเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้ในคุกกี้ในเครือข่ายปัจจุบัน
เรารู้ว่าระบบผู้ใช้ที่ใช้คุกกี้ทั่วไปจะจัดเก็บตัวแปรอย่างน้อยสองตัวในคุกกี้: ชื่อผู้ใช้และ UserLevel ซึ่งชื่อผู้ใช้คือชื่อผู้ใช้และ UserLevel คือระดับผู้ใช้ เมื่อเบราว์เซอร์ของเราเข้าถึงหน้า ASP มันจะปล่อยออกมา
รับ /.../file.asp http 1.0
-
คุกกี้: ชื่อผู้ใช้ = ผู้ใช้และ userlevel = 1
-
จากนั้นตราบใดที่เรารู้ชื่อผู้ใช้ของผู้ดูแลระบบและค่า userlevel (สมมติว่าผู้ดูแลระบบและ 5 ตามลำดับ) เราสามารถถ่ายโอนได้
รับ /.../file.asp http 1.0
-
คุกกี้: ชื่อผู้ใช้ = admin & userlevel = 5
-
เพื่อรับสิทธิ์ผู้ดูแลระบบ ง่ายมากใช่มั้ย อย่างไรก็ตามก่อนที่จะค้นพบช่องโหว่ระบบการจัดการผู้ใช้เกือบทั้งหมดอาศัยคุกกี้
2. จัดเก็บข้อมูลผู้ใช้อย่างปลอดภัย
เนื่องจากคุกกี้ไม่ปลอดภัยและเราต้องจัดเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้จึงควรเก็บไว้ที่ไหน
เราสังเกตเห็นว่าใน ASP นอกเหนือจากคุกกี้แล้วยังมีเซสชันที่สามารถจัดเก็บข้อมูลได้ เซสชันจะถูกเก็บไว้บนเซิร์ฟเวอร์และไม่สามารถเปลี่ยนแปลงได้โดยไคลเอ็นต์ตามต้องการดังนั้นจึงมีความปลอดภัยสูงมาก ด้วยวิธีนี้ทุกคนสามารถเปลี่ยนรหัสของคุกกี้ทั้งหมดเป็นเซสชัน
3. จัดเก็บข้อมูลผู้ใช้เป็นเวลานาน
เซสชันใช้เพื่อบันทึกข้อมูลการเข้าสู่ระบบของผู้ใช้ วิธีการที่อธิบายไว้ในส่วนนี้ถูกสร้างขึ้น
มีสองตัวแปรของวิธีนี้ ให้มันตามคุกกี้ รหัสในการใช้วิธีนี้มีดังนี้:
VBS:
-
ชื่อผู้ใช้สลัวรหัสผ่าน
username = เซสชัน (ชื่อผู้ใช้)
ถ้าชื่อผู้ใช้ = จากนั้น
'ไม่มีข้อมูลการเข้าสู่ระบบของผู้ใช้ในเซสชัน
username = request.cookies (ชื่อผู้ใช้)
รหัสผ่าน = request.cookies (รหัสผ่าน)
'ให้ความสนใจกับชื่อผู้ใช้และรหัสผ่านที่ได้รับในสองประโยคข้างต้นเพื่อป้องกันช่องโหว่การฉีด SQL (เช่นกรองคำพูดเดียว') ละเว้นที่นี่
หากชื่อผู้ใช้ = หรือรหัสผ่าน = จากนั้น
'ผู้ใช้ไม่ได้เข้าสู่ระบบ
-
อื่น
'ที่นี่สันนิษฐานว่าวัตถุ Conn และ Rs ได้ถูกสร้างขึ้น
Rs.Open เลือก Top 1 * จาก [ผู้ใช้] โดยที่ผู้ใช้ชื่อ = '& username &' และ password = '& password &', conn, 1, 3
ถ้า RS.EOF แล้ว
'ข้อมูลในคุกกี้นั้นผิดกฎหมาย
-
อื่น
'ข้อมูลในคุกกี้นั้นถูกกฎหมายและเข้าสู่ระบบโดยอัตโนมัติ
เซสชัน (ชื่อผู้ใช้) = ชื่อผู้ใช้
-
สิ้นสุดถ้า
สิ้นสุดถ้า
อื่น
'ข้อมูลผู้ใช้มีอยู่แล้วในเซสชันและอ่านโดยตรง
-
สิ้นสุดถ้า
-
JS:
-
ชื่อผู้ใช้รหัสรหัสผ่าน;
ชื่อผู้ใช้ = เซสชัน (ชื่อผู้ใช้) +;
ถ้า (ชื่อผู้ใช้ == || ชื่อผู้ใช้ == ไม่ได้กำหนด) {
// ไม่มีข้อมูลผู้ใช้ในเซสชัน
ชื่อผู้ใช้ = request.cookies (ชื่อผู้ใช้) +;
รหัสผ่าน = request.cookies (รหัสผ่าน) +;
// ให้ความสนใจกับชื่อผู้ใช้และรหัสผ่านที่ได้รับในสองประโยคข้างต้นเพื่อป้องกันช่องโหว่การฉีด SQL (เช่นกรองคำพูดเดียว ') ละเว้นที่นี่
ถ้า (ชื่อผู้ใช้ == || ชื่อผู้ใช้ == ไม่ได้กำหนด || รหัสผ่าน == || รหัสผ่าน == ไม่ได้กำหนด) {
// ผู้ใช้ไม่ได้เข้าสู่ระบบ
-
-
อื่น {
// ที่นี่สันนิษฐานว่ามีการสร้างวัตถุ Conn และ Rs
Rs.Open (เลือก Top 1 * จาก [ผู้ใช้] โดยที่ชื่อผู้ใช้ = ' + ชื่อผู้ใช้ +' และรหัสผ่าน = ' + รหัสผ่าน +', Conn, 1, 3);
if (rs.eof) {
// ข้อมูลในคุกกี้นั้นผิดกฎหมาย
-
-
อื่น {
// ข้อมูลในคุกกี้นั้นถูกกฎหมายและเข้าสู่ระบบโดยอัตโนมัติ
เซสชัน (ชื่อผู้ใช้) = ชื่อผู้ใช้ +;
-
-
-
-
อื่น {
// ข้อมูลผู้ใช้มีอยู่แล้วในเซสชันและอ่านโดยตรง
-
-
-
อย่างไรก็ตามวิธีนี้ไม่ปลอดภัยสำหรับผู้ใช้เนื่องจากเบราว์เซอร์จะส่งคุกกี้ทุกครั้งที่เข้าชมหน้าและบัญชีของผู้ใช้จะถูกขโมยไปเมื่อคุกกี้ที่มีรหัสผ่านได้รับโดยผู้อื่น สำหรับกรณีนี้วิธีที่สองจะปรากฏขึ้นนั่นคือเพิ่มรหัสการตรวจสอบฟิลด์ลงในฐานข้อมูลข้อมูลผู้ใช้ เพิ่มค่ารหัส เมื่อตรวจสอบข้อมูลผู้ใช้ในคุกกี้จะมีการตรวจสอบชื่อผู้ใช้และ VerifyCode เท่านั้น ข้อได้เปรียบของวิธีนี้คือแม้ว่าคุกกี้ของผู้ใช้จะได้รับจากแฮ็กเกอร์เขาสามารถใช้รหัสตรวจสอบชั่วคราวนี้เพื่อเข้าสู่ระบบและไม่สามารถรับรหัสผ่านของผู้ใช้ได้ ตราบใดที่ผู้ใช้รายนี้เข้าสู่ระบบด้วยชื่อผู้ใช้และรหัสผ่านอีกครั้งค่า VerificationCode จะเปลี่ยนไปและแฮ็กเกอร์จะไม่สามารถเข้าสู่ระบบผ่านการตรวจสอบแบบดั้งเดิมได้
การใช้วิธีนี้ต้องมีการเปลี่ยนแปลงเล็กน้อยกับรหัสของวิธีการหนึ่งที่กล่าวถึงข้างต้น ก่อนอื่นในโปรแกรมเข้าสู่ระบบของคุณคุณต้องเพิ่มย่อหน้าที่การตรวจสอบผ่านไปยังการจัดเก็บข้อมูลผู้ใช้:
VBS:
-
Response.cookies (VerifyCode) = int (RND * 2100000000)
-
JS:
-
Response.Cookies (VerifyCode) = Math.Floor (Math.Random () * 2100000000);
-
จากนั้นในรหัสการตรวจสอบที่ให้ไว้ข้างต้นให้เปลี่ยนการตรวจสอบคุกกี้ (รหัสผ่าน) เป็นการตรวจสอบคุกกี้ (VerifyCode)
4. บทสรุป
ผ่านการวิเคราะห์และการประมวลผลของเราคุกกี้การปลอมแปลงช่องโหว่ได้รับการแก้ไขอย่างสมบูรณ์และตั้งแต่นั้นมาโปรแกรม ASP ของเราก็มีความปลอดภัยมากขึ้น
2550-208-05 20:37 การเขียนเริ่มต้นขึ้น
2007-08-05 21:14 ฉบับพิมพ์ครั้งแรกเสร็จสมบูรณ์