จะทำการตรวจสอบสิทธิ์แบบไม่ระบุสถานะ (ไม่มีเซสชัน) และไม่ใช้คุกกี้ได้อย่างไร

Bob ใช้เว็บแอปพลิเคชันเพื่อบรรลุบางสิ่งบางอย่าง และ:

• เบราว์เซอร์ของเขาคือในอาหารจึงไม่สนับสนุนคุกกี้
• เว็บแอปพลิเคชันเป็นที่นิยมซึ่งเกี่ยวข้องกับผู้ใช้จำนวนมากในช่วงเวลาหนึ่ง - ต้องปรับขนาดให้ดี ตราบใดที่การเก็บรักษาเซสชันจะจำกัด จำนวนการเชื่อมต่อพร้อมกันและแน่นอนว่าจะนำมาซึ่งการลงโทษด้านประสิทธิภาพที่ไม่สำคัญเราอาจต้องการให้มีระบบที่ไม่ใช้เซสชัน :)

หมายเหตุสำคัญบางประการ:

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

ตอนนี้เราจะตรวจสอบความถูกต้องของ Bob (ในแต่ละคำขอ) ได้อย่างไร? วิธีใดเป็นวิธีที่เหมาะสมในการนำสิ่งดังกล่าวไปปฏิบัติ

• การเล่นเทนนิสด้วยข้อมูลประจำตัวผ่านช่องที่ซ่อนอยู่ในรูปแบบ HTML ... ลูกบอลมีข้อมูลประจำตัว ( ชื่อผู้ใช้และรหัสผ่าน ) และไม้ทั้งสองคือเบราว์เซอร์และเว็บแอปพลิเคชันตามลำดับ กล่าวอีกนัยหนึ่งเราอาจขนส่งข้อมูลไปมาผ่านช่องแบบฟอร์มแทนที่จะใช้คุกกี้ ตามคำขอของเว็บแต่ละครั้งเบราว์เซอร์จะโพสต์ข้อมูลรับรอง แม้ว่าในกรณีของแอปพลิเคชันหน้าเดียวอาจดูเหมือนการเล่นสควอชกับกำแพงยางแทนที่จะเล่นเทนนิสเนื่องจากเว็บฟอร์มที่มีข้อมูลรับรองอาจคงอยู่ตลอดอายุการใช้งานของหน้าเว็บ (และเซิร์ฟเวอร์จะได้รับการกำหนดค่าไม่ให้เสนอข้อมูลรับรองกลับ)
• การจัดเก็บชื่อผู้ใช้และรหัสผ่านในบริบทของหน้า - ตัวแปร JavaScript เป็นต้นต้องมีหน้าเดียวที่นี่ IMHO
• การตรวจสอบความถูกต้องโดยใช้โทเค็นเข้ารหัส ในกรณีนี้การดำเนินการเข้าสู่ระบบจะส่งผลให้มีการสร้างโทเค็นความปลอดภัยที่เข้ารหัส (ชื่อผู้ใช้ + รหัสผ่าน + อย่างอื่น) โทเค็นนี้จะถูกส่งกลับไปยังไคลเอนต์และคำขอที่จะเกิดขึ้นจะมาพร้อมกับโทเค็น สิ่งนี้สมเหตุสมผลไหม เรามี HTTPS แล้ว ...
• อื่น ๆ ...
• ทางเลือกสุดท้าย: อย่าทำเช่นนี้เก็บข้อมูลรับรองในเซสชั่น! เซสชั่นเป็นสิ่งที่ดี มีหรือไม่มีคุกกี้

คุณมีความกังวลเกี่ยวกับเว็บ / ความปลอดภัยเกี่ยวกับแนวคิดใด ๆ ที่อธิบายไว้ก่อนหน้านี้หรือไม่? ตัวอย่างเช่น,

• การหมดเวลา - เราอาจเก็บการประทับเวลาพร้อมกับข้อมูลรับรอง (ประทับเวลา = เวลาที่บ๊อบป้อนข้อมูลรับรองของเขา) เช่นเมื่อNOW - timestamp> thresholdเราอาจปฏิเสธคำขอ
• การป้องกันสคริปต์ข้ามไซต์ - ไม่ควรแตกต่างกัน แต่อย่างใดใช่ไหม

ขอบคุณมากที่สละเวลาอ่าน :)

ฉันชอบคำถามเหล่านี้ - การรักษาเซสชันโดยไม่มีเซสชั่น

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

กลไกที่ได้รับความนิยมอย่างหนึ่งแม้ว่าจะไม่ใช่กลไกที่ไร้สถานะโดยสิ้นเชิง (สมมติว่าคุณมีการเรียกใช้ JavaScript) คือการฝังคุกกี้เซสชันใน JavaScript เจ้าหน้าที่รักษาความปลอดภัยในตัวฉันกำลังกรีดร้องที่สิ่งนี้ แต่มันสามารถใช้งานได้จริง - ทุกคำขอมีกX-Authentication-Tokenส่วนหัวหรืออะไรทำนองนั้นและคุณแม็พนั้นกับฐานข้อมูลที่เก็บไฟล์ในหน่วยความจำ ฯลฯ บนแบ็กเอนด์เพื่อตรวจสอบความถูกต้องของผู้ใช้ โทเค็นนี้สามารถมีการหมดเวลาตามที่คุณระบุไว้และหากหมดเวลาผู้ใช้จะต้องเข้าสู่ระบบอีกครั้ง มันค่อนข้างปรับขนาดได้ - หากคุณจัดเก็บไว้ในฐานข้อมูลคำสั่ง SQL คำสั่งเดียวจะดำเนินการและด้วยดัชนีที่ถูกต้องควรใช้เวลาน้อยมากในการดำเนินการแม้จะมีผู้ใช้พร้อมกันหลายคน โหลดการทดสอบที่นี่จะช่วยได้แน่นอน หากฉันอ่านคำถามอย่างถูกต้องนี่จะเป็นกลไกโทเค็นที่เข้ารหัสของคุณ - แม้ว่าฉันจะแนะนำอย่างยิ่งให้คุณใช้โทเค็นแบบสุ่มที่เข้ารหัสโดยใช้อักขระ 32 ตัวเมื่อเทียบกับการใช้ชื่อผู้ใช้ + รหัสผ่าน + อะไรก็ตาม - วิธีนี้จะยังคงอยู่ คาดเดาไม่ได้ แต่คุณยังสามารถเชื่อมโยงกับ ID ผู้ใช้หรือบางอย่างได้

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

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

มีข้อกังวลด้านความปลอดภัยอื่น ๆ ที่ฉันคิดได้ แต่มันกว้างเกินไปที่จะกล่าวถึงในขั้นตอนนี้ - หากคุณคำนึงถึงกรณีการใช้งาน (และการละเมิด) ทั้งหมดคุณน่าจะสามารถดำเนินการได้ดีพอสมควร ระบบนี้

เกี่ยวกับตัวเลือกการเข้าสู่ระบบ - ฉันคิดว่าโดยปกติแล้วคุณต้องการสนับสนุนเซสชันสำหรับแขกด้วย

ดังนั้นหากคุณต้องการบังคับใช้การเข้าสู่ระบบตัวเลือกโทเค็นที่เข้ารหัสอาจจะดี มันอาจจะดีสำหรับเซสชั่นแขกด้วย ในอีกทางหนึ่งฉันจะรวมระหว่างการต่อท้ายโทเค็นกับ URL และตัวเลือกเทนนิส

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

อีกประการหนึ่งแม้ว่าคุณจะสามารถใช้คุกกี้ได้ฉันขอแนะนำให้คุณเพิ่มโทเค็นแบบสุ่มหรือเวอร์ชันสุ่มเพื่อป้องกันตัวคุณเองจากการโจมตีแบบ Cross Site Request Forgery (CSRF)