แยก JWT ระหว่างเพย์โหลดและลายเซ็น
บริบท:ฉันกำลังดูโซลูชันการจัดเก็บข้อมูลสำหรับโทเค็น JWT บนแอปพลิเคชันหน้าเดียว
- การจัดเก็บ JWT ในที่จัดเก็บในตัวเครื่องนั้นไม่ปลอดภัยและมีแนวโน้มที่จะถูกโจมตีด้วย XSS
- การจัดเก็บ JWT ในคุกกี้ที่ปลอดภัย / HTTP เท่านั้นปลอดภัยกว่า แต่มีแนวโน้มที่จะถูกโจมตีด้วย CSRF
ฉันกำลังศึกษาสถานการณ์ต่อไปนี้:
ในการตรวจสอบความถูกต้องโทเค็นการรีเฟรชจะถูกเก็บไว้ในคุกกี้ที่ปลอดภัยเฉพาะ http เท่านั้น สามารถใช้เพื่อรับโทเค็นการเข้าถึงเท่านั้น
เมื่อได้รับอนุญาตแบ็กเอนด์จะตอบสนองด้วยโทเค็นการเข้าถึง JWT ส่วนหัวและส่วนของน้ำหนักบรรทุกของ JWT อยู่ภายในเนื้อหาการตอบสนอง ลายเซ็นโทเค็นจะไม่ถูกส่งและตั้งค่าในคุกกี้ที่ปลอดภัยเฉพาะ http เท่านั้น (เว็บไซต์เดียวกันเข้มงวดถ้าเป็นไปได้ แต่สมมติว่าไม่ใช่กรณีนี้) ส่วนหัว + เพย์โหลดจะถูกเก็บไว้ในหน่วยความจำ
JWT มีการอ้างสิทธิ์ดังต่อไปนี้
- iat, nbf, exp (IMO ที่เดาได้)
- การอ้างสิทธิ์ที่สัมพันธ์กับข้อมูลประจำตัวของผู้ใช้และสิทธิ์ (เดาได้หากทราบข้อมูลประจำตัวของผู้ใช้)
- jti ที่มีหมายเลขสุ่มที่ปลอดภัยในการเข้ารหัส (ในกรณีของฉันสร้างด้วยความลับของ python )
เมื่อทำการร้องขอส่วนหัว + เพย์โหลดจะถูกส่งผ่าน XHR / ดึงข้อมูลโดย SPA ในส่วนหัวการอนุญาต ลายเซ็นจะถูกส่งไปพร้อมกับคุกกี้ แบ็กเอนด์เชื่อมต่อทั้งสองและตรวจสอบลายเซ็น
- กลไกนี้ปลอดภัยต่อการโจมตี CSRF หรือไม่? การอ้างสิทธิ์ jti ทำให้คุกกี้ลายเซ็น Authorization token + เป็นเทคนิคการลด CSRF ที่ถูกต้องหรือไม่
- กลไกนี้ปลอดภัยกว่าการโจมตี XSS มากกว่าการเก็บ JWT ไว้ในที่จัดเก็บในตัวเครื่องจริงหรือ? (การโจมตีโดยใช้ XSS สามารถขโมยลายเซ็นได้อย่างง่ายดายเช่นเดียวกับTRACE exploit )
หมายเหตุ: ฉันได้อ่านคำถามนี้ซึ่งคล้ายกัน แต่กว้างเกินไปฉันจึงโพสต์คำถามนี้เพื่อให้ได้คำตอบที่แม่นยำยิ่งขึ้น
คำตอบ
กลไกนี้ปลอดภัยต่อการโจมตี CSRF หรือไม่?
วิธีการแยก JWT และจัดเก็บลายเซ็นในคุกกี้และโทเค็นที่เหลือใน Browser Storage นี้ไม่ได้ให้การป้องกันเพิ่มเติมใด ๆ จากการโจมตี CSRF นอกเหนือจากกรณีที่ JWT ทั้งหมดถูกเก็บไว้ใน Local หรือ Session Storage ใช่มันจะลดการโจมตี CSRF แต่คุณไม่จำเป็นต้องเพิ่มค่าใช้จ่ายที่ไม่จำเป็นในการแยกและเชื่อมต่อ JWT บนเซิร์ฟเวอร์ การจัดเก็บ JWT ใน Local Storage และยอมรับเฉพาะในส่วนหัว Authorization ก็เพียงพอที่จะปกป้องแอปพลิเคชันของคุณจากการโจมตี CSRF
กลไกนี้ปลอดภัยกว่าการโจมตี XSS มากกว่าการเก็บ JWT ไว้ในที่จัดเก็บในตัวเครื่องจริงหรือ? (การโจมตีโดยใช้ XSS สามารถขโมยลายเซ็นได้อย่างง่ายดายเช่นเดียวกับ TRACE exploit)
หากคุณมุ่งเน้นไปที่ผู้โจมตีที่สามารถขโมย JWT ได้ แต่เพียงผู้เดียววิธีนี้จะปลอดภัยเว้นแต่คุณจะกล่าวถึงอย่างถูกต้อง TRACE จะเปิดใช้งานบนเซิร์ฟเวอร์
อย่างไรก็ตามสิ่งนี้ไม่ได้ทำให้แอปพลิเคชันของคุณปลอดภัยขึ้นจากการโจมตี XSS ตัวอย่างเช่นหากฉันสามารถเรียกใช้ Javascript ได้ตามอำเภอใจบนแอปพลิเคชันของคุณฉันสามารถดึงส่วนหัว JWT + เพย์โหลดจาก Local Storage และส่ง XHR ไปยังปลายทางที่ละเอียดอ่อนโดยใช้ Credentials ที่ตั้งค่าเป็น True จุดสิ้นสุดนี้อาจได้รับการออกแบบให้เปลี่ยนที่อยู่อีเมลของบัญชีเช่น ทันทีนั้นนำไปสู่การครอบครองบัญชี ไม่จำเป็นต้องขโมยคุกกี้หรือ JWT
สรุป:วิธีการนี้ให้การป้องกันโทเค็นเซสชันโดยการแยกลายเซ็นออกจากโทเค็นที่เหลือ อย่างไรก็ตามเมื่อพูดถึง XSS การขโมยโทเค็นเซสชันไม่ใช่ความเสี่ยงเดียวที่คุณควรพิจารณา