คุกกี้กับเซสชันเทียบกับ jwt


12

ฉันกำลังอ่านการพิสูจน์ตัวตน / การอนุญาตในเว็บแอปพลิเคชัน ใครช่วยยืนยัน / แก้ไขความรู้ปัจจุบันของฉันได้ไหม

  • คุกกี้: ในเวอร์ชันเริ่มต้นของพวกเขาไฟล์ข้อความที่มีลูกค้าที่ไม่ซ้ำกัน Id ข้อมูลอื่น ๆ ที่จำเป็นเกี่ยวกับลูกค้า (เช่นบทบาท)

  • เซสชัน: เฉพาะรหัสลูกค้าที่ไม่ซ้ำกันเท่านั้นที่ถูกส่งในไฟล์ (เรียกอีกอย่างว่าคุกกี้) ทุกอย่างจะถูกเก็บไว้บนเซิร์ฟเวอร์

  • JWT: ทุกอย่างถูกเก็บไว้ในโทเค็น (ซึ่งอาจถูกเก็บไว้ในไฟล์ข้อความซึ่งเรียกอีกอย่างว่าคุกกี้)

ขอบคุณสำหรับความคิดเห็นใด ๆ !

คำตอบ:


12

คุกกี้: ในเวอร์ชันเริ่มต้นของพวกเขาไฟล์ข้อความที่มีลูกค้าที่ไม่ซ้ำกัน Id ข้อมูลอื่น ๆ ที่จำเป็นเกี่ยวกับลูกค้า (เช่นบทบาท)

key-valueแต่เดิมนั้นมีการจัดการกับtuples เพื่อรักษาข้อมูลที่เกี่ยวข้องกับกิจกรรมของลูกค้า นี้การเก็บรักษาเป็นสิ่งที่เรารู้ว่าเป็นเซสชั่นหรือสถานะโปรแกรม โดยพื้นฐานแล้วพวกเขาถูกสร้างขึ้นเพื่อรักษาสถานะของเว็บแอปพลิเคชัน โดยเฉพาะอย่างยิ่งสถานะบนฝั่งไคลเอ็นต์ (1)

โดยทั่วไปแล้วคุกกี้จะถูกตั้งค่าโดยเซิร์ฟเวอร์ผ่านส่วนหัวตอบกลับ ( Set-Cookie key=value) อย่างไรก็ตามลูกค้าสามารถตั้งค่าได้เช่นกัน ตัวอย่างเช่นโดย DOM ( document.cookie)

สิ่งสำคัญประการหนึ่งที่ควรทราบเกี่ยวกับคุกกี้คือพวกเขาไม่ได้ระบุผู้ใช้ พวกเขาค่อนข้างเชื่อมโยง TERNA ข้อมูล - ไคลเอนต์ - เซิร์ฟเวอร์ (3)

เรามักจะเชื่อมโยงคุกกี้กับไฟล์เพราะในช่วงแรก ๆ ของเว็บเบราว์เซอร์พวกเขาจะต้องคงอยู่คุกกี้อย่างใดเป็นไฟล์ที่ได้รับการสนับสนุนที่เป็นไปได้มากที่สุด เบราว์เซอร์ของวันนี้จัดเก็บคุกกี้ (เหนือสิ่งอื่นใด) ในการจัดเก็บในท้องถิ่น (ฐานข้อมูลแบบฝัง)

เซสชัน: เฉพาะรหัสลูกค้าที่ไม่ซ้ำกันเท่านั้นที่ส่งในไฟล์ (เรียกอีกอย่างว่าคุกกี้) ทุกอย่างจะถูกเก็บไว้บนเซิร์ฟเวอร์

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

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

ในการกระจายแอพพลิเคชั่นเซสชั่นควรจะต่อเนื่องได้ด้วยเหตุผลที่ชัดเจน หากถูกเก็บไว้ในหน่วยความจำการจัดเก็บในหน่วยความจำ (ส่วนประกอบ) ควรเป็นแบบอนุกรม วิธีแก้ไขปัญหาทั่วไปคือการจัดเก็บเซสชันในไฟล์ หรือใน NoSQL DB เช่น Redis

เกี่ยวกับความปลอดภัย เซสชันฝั่งเซิร์ฟเวอร์ปลอดภัยกว่าฝั่งไคลเอ็นต์ ลูกค้ามีความเสี่ยงที่จะถูกคุกคามมากขึ้นเนื่องจากผู้ใช้มักจะไม่ตระหนักถึงภัยคุกคามที่พวกเขาสัมผัส อย่างน้อยไม่ใช่ผู้ใช้ทั่วไป

ในทางกลับกันการโจมตีโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์นั้นไม่ใช่เรื่องยาก

JWT: ทุกอย่างถูกเก็บไว้ในโทเค็น (ซึ่งอาจถูกเก็บไว้ในไฟล์ข้อความซึ่งเรียกอีกอย่างว่าคุกกี้)

ไม่ได้จริงๆ JWT จัดเก็บข้อมูลส่วนใหญ่เกี่ยวข้องกับการอนุญาตและผู้ออกโทเค็น

แม้ว่าพวกเขาจะใช้เพื่อบรรจุ ID ผู้ใช้ (ย่อย) แต่เราพบ JWT ที่ไม่ได้ระบุผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์แล้ว ตัวอย่างเช่นโทเค็นสำหรับเซสชันแขก เนื้อหาหลักของ JWTs มีการเรียกร้อง ; รายการที่จะตรวจสอบโดยกระบวนการอนุมัติ

เป็นสิ่งสำคัญที่จะเก็บไว้ในใจว่าJWTs ไม่ได้เก็บรักษาโลก เซสชั่นหรือสถานะโปรแกรมยังจะต้องมีการเก็บไว้ที่อื่นและจัดการอย่างเป็นอิสระ

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


1: เวิลด์ไวด์เว็บหมายถึงไร้สัญชาติ ถ้าเราต้องการสร้างแอพพลิเคชั่นฝั่งเซิร์ฟเวอร์ที่ไร้รัฐควรจัดเก็บเซสชั่นไว้ที่อื่นในฝั่งไคลเอ็นต์

2: เปิดโปรแกรมประยุกต์ด้านเซิร์ฟเวอร์เป็นstatefulแอพลิเคชัน

3: ไคลเอ็นต์เป็นแอปพลิเคชันไม่ใช่ในฐานะผู้ใช้


โปรดทราบว่าบางอย่างเช่นค่าเริ่มต้น Ruby on Rails จะจัดเก็บวัตถุ "เซสชัน" ทั้งหมดในคุกกี้ (โดยปกติเข้ารหัสเหล่านี้) ซึ่งอาจมีสิ่งที่user_idผู้ใช้ที่ลงชื่อเข้าใช้
Lancer ไฟ

7

คุกกี้: ในเวอร์ชันเริ่มต้นของพวกเขาไฟล์ข้อความที่มีลูกค้าที่ไม่ซ้ำกัน Id ข้อมูลอื่น ๆ ที่จำเป็นเกี่ยวกับลูกค้า (เช่นบทบาท)

คำจำกัดความของคุ้กกี้ไม่ได้อธิบายถึงสิ่งที่พวกเขาทำ คุกกี้คือคู่ของคีย์ - ค่าที่ตั้งค่าผ่านส่วนหัวการตอบกลับ HTTP ( Set-Cookie) โดยเซิร์ฟเวอร์และเก็บไว้โดยไคลเอนต์ที่สนับสนุนพวกเขา คุกกี้จะถูกส่งกลับมาพร้อมกับคำขอที่ตามมาแต่ละครั้ง (ในCookieส่วนหัว) สำหรับรูปแบบการร้องขอการจับคู่โฮสต์เส้นทาง https ในขณะที่คุกกี้ยังไม่หมดอายุ คุณสามารถจัดเก็บสิ่งที่คุณต้องการในคุกกี้และช่วยให้คุณสนับสนุนสถานะในโปรโตคอลไร้สัญชาติของ HTTP

ตัวอย่างการแลกเปลี่ยนคุกกี้มีลักษณะดังนี้:

ป้อนคำอธิบายรูปภาพที่นี่

เซสชัน: เฉพาะรหัสลูกค้าที่ไม่ซ้ำกันเท่านั้นที่ถูกส่งในไฟล์ (เรียกอีกอย่างว่าคุกกี้) ทุกอย่างจะถูกเก็บไว้บนเซิร์ฟเวอร์

ถูกต้องแล้ว เซสชันคือข้อมูลที่เก็บไว้ในฝั่งเซิร์ฟเวอร์เกี่ยวกับเซสชันปัจจุบันของผู้ใช้ ในการทำให้งานนี้เป็นโปรโตคอลไร้สัญชาติเช่น HTTP ผู้ใช้จะต้องส่ง ID เซสชันของตนพร้อมกับคำขอแต่ละครั้งเพื่อให้เซิร์ฟเวอร์สามารถดึงข้อมูลเซสชันที่ถูกต้องสำหรับผู้ใช้ โดยทั่วไปจะมีการจัดเก็บรหัสเซสชันไว้ในคุกกี้ (ดูด้านบน) นี่ไม่ใช่คุกกี้ที่แตกต่างจากคุกกี้อื่น ๆ ข้อมูลเป็นเพียง ID ของเซิร์ฟเวอร์สำหรับเซสชันผู้ใช้

JWT: ทุกอย่างถูกเก็บไว้ในโทเค็น (ซึ่งอาจถูกเก็บไว้ในไฟล์ข้อความซึ่งเรียกอีกอย่างว่าคุกกี้)

นั่นเป็นเรื่องจริงมาก ทุกอย่างถูกเก็บไว้ในโทเค็น โทเค็นอาจถูกเก็บไว้ในคุกกี้ (ดูด้านบน) นี่เป็นอีกทางเลือกหนึ่งในเซสชันของเซิร์ฟเวอร์และทำงานได้เนื่องจากโทเค็นได้รับการลงชื่อและตรวจสอบโดยเซิร์ฟเวอร์ดังนั้นจึงไม่สามารถเปลี่ยนแปลงหรือปลอมแปลงได้และปลอดภัยในการจัดเก็บในฝั่งไคลเอ็นต์


ปกติแล้ว JWT จะไม่ถูกจัดเก็บไว้ในคุกกี้ในประสบการณ์ของฉัน พวกเขาอาจเป็นได้ แต่บ่อยครั้งที่ฉันเห็นพวกเขาในส่วนหัวของตนเอง (หรือบ่อยครั้งที่ส่วนหัวการอนุญาต) ระหว่างทางไปยังเซิร์ฟเวอร์และเก็บไว้ในหน่วยความจำหรือในที่จัดเก็บในตัวเครื่องหรือในเซสชัน
Paul

1
@Paul เกี่ยวกับที่เก็บข้อมูลในเครื่อง มันขึ้นอยู่กับลูกค้า ไม่ใช่ไคลเอนต์ทั้งหมดและไม่ใช่ไคลเอ็นต์ที่ใช้มากที่สุดทุกรุ่นรองรับที่เก็บข้อมูลบนเว็บ ลองดูที่นี่ ถ้าพวกเขาจะเป็นที่นิยมที่จะทำให้ราชสกุลตามฤดูกาล แต่ถ้าลูกค้าของเราไม่รองรับที่เก็บข้อมูลในเครื่อง Httponly cookies + SSL + client fingerPrint ให้การใช้งานที่ปลอดภัย
Laiv

@Laiv ฉันไม่เห็นด้วยกับคุณ; ซามูเอลพูดว่า "โทเค็นนั้นถูกเก็บไว้ในคุกกี้" และฉันแค่พยายามสังเกตว่านี่ไม่ใช่กรณีเสมอไป
Paul

@ พอลฉันเปลี่ยนเป็นการอ่าน "... อาจถูกเก็บไว้ในคุกกี้"
Samuel
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.