"Local Storage หรือ Cookie สำหรับ Session Token เช่น JWT"
ทีนี้เรามาดูกันต่อ ว่าเราควรเก็บไว้ที่ไหนดี
(ส่วนใหญ่เน้นไปที่การโจมตีแบบ XSS การโจมตีแบบอื่นลองดู Ref เพิ่มเติมได้)
.
มีการถกเถียงกันอย่างกว้างขวางว่า ควรเก็บ Token ใน Local Storage หรือ Cookie แบบ HttpOnly ดี แต่จากศึกษาพบว่าการเลือกเก็บ Token ในแต่ละแบบมีข้อดีและข้อเสียของมันอยู่ และไม่ได้แปลว่าการเก็บใน Local Storage จะแย่เสมอไป (Ref #1)
.
Token คืออะไร.
เราต้องเก็บข้อมูลบางอย่างเพื่อให้ User ไม่ต้องกรอกข้อมูล Username/Password ตลอดเวลาทุกครั้งที่มี Request ไปหา Server, และถ้าคุณมี Token คุณก็สามารถเข้าถึงข้อมูลได้ เปรียบเหมือนเราถือเช็คเงินสดที่ออกโดยธนาคาร ใครก็ตามที่มีเช็คก็สามารถเบิกเงินได้ ธนาคารไม่ต้องคอยมาตรวจสอบว่าคุณคือเจ้าของเช็คเงินสดอีกมั้ย (แต่ในบริบทของ Token จะแตกต่างกันไปบ้าง) (Ref #1 จากคุณ Pedro M. M.)
.
เก็บ Token ที่ Local Storage.
- สามารถเข้าถึงได้จาก JavaScript, Local Storage สามารถเข้าถึงได้ผ่าน JavaScript โดยตรงเลย
- ความง่ายในการใช้งาน: Local Storage สามารถเข้าถึงได้ง่ายผ่าน JavaScript ทำให้การจัดการกับ Token ในฝั่ง Client เป็นไปอย่างสะดวกและรวดเร็ว
- ความยืดหยุ่น: ในกรณีของ Single Page Applications (SPAs) Local Storage มอบความยืดหยุ่นในการจัดการกับ Session Token และช่วยให้ประสบการณ์การใช้งานเป็นไปอย่างราบรื่น
.
เก็บ Token ที่ HttpOnly Cookies (Secure และ SameSite Cookie).
- ป้องกันการเข้าถึงจาก JavaScript: HttpOnly Cookies ไม่สามารถเข้าถึงได้จาก JavaScript แต่ทุกครั้งที่มีการส่ง Request ไป Server เจ้าตัวของ Cookies นั้นก็จะถูกแนบไปด้วยทุกครั้ง ดังนั้น Hacker ที่มีประสบการณ์และมีเวลามากพอ จะสามารถข้าม HttpOnly ไปได้ โดยเทคนิคอื่นๆ (Ref 1: พี่คริสอธิบาย, Ref 3: "Why HttpOnly Won't Protect You" โดย PDP, Ref 4: Securing cookies with httponly and secure flags)
- การใช้งานกับ Server-Side Rendering (SSR): การเก็บ Token ใน HttpOnly Cookies ทำให้สามารถเข้าถึง Token ได้ในฝั่ง Server ซึ่งมีประโยชน์ในการทำ SSR
.
ความแตกต่างของการใช้งาน Token.
- หาก Token อยู่ใน LocalStorage ผู้โจมตีสามารถขโมยToken เพื่อใช้งานในภายหลังได้ และถ้าเป็น Cookie ผู้โจมตีต้องยิง Request บน Browser ของเหยื่อ ซึ่งอาจจะทำได้ลำบากกว่า
.
การโจมตีแบบ XSS (Cross-Site Scripting).
การโจมตีแบบ XSS (Ref 2) เป็นการโจมตีทางเว็บที่แฮกเกอร์แทรกโค้ดที่เป็นอันตรายลงในหน้าเว็บหรือแอปพลิเคชันเว็บ ซึ่งจะทำงานเมื่อผู้ใช้เปิดหน้าเว็บหรือแอปพลิเคชันนั้นๆ โค้ดที่เป็นอันตรายมักจะเป็นสคริปต์ JavaScript ที่สามารถขโมยข้อมูลสำคัญจากผู้ใช้หรือทำให้เกิดพฤติกรรมที่ไม่พึงประสงค์ได้
.
เช่น การโจมตีแบบ Stored XSS (Persistent XSS)
ผู้โจมตีแทรกโค้ดที่เป็นอันตรายลงในเว็บไซต์ เช่น ในฟอร์มการกรอกข้อมูลหรือในช่องแสดงความคิดเห็น
เมื่อผู้ใช้คนอื่นเข้าชมหน้าเว็บที่มีข้อมูลที่ถูกแทรก โค้ดที่เป็นอันตรายจะถูกเรียกใช้งาน โค้ดที่เป็นอันตรายนี้สามารถเข้าถึง localStorage และขโมยข้อมูลที่เก็บไว้ได้
.
การป้องกันการโจมตีแบบ XSS.
- การตรวจสอบและทำความสะอาดข้อมูล: ตรวจสอบและทำความสะอาดข้อมูลที่ได้รับจากผู้ใช้ก่อนที่จะนำไปแสดงผล
- การใช้ Content Security Policy (CSP): กำหนดนโยบายความปลอดภัยในการโหลดสคริปต์และเนื้อหาอื่นๆ บนหน้าเว็บ
- การเข้ารหัสข้อมูลที่ส่งไปยังเซิร์ฟเวอร์: ใช้การเข้ารหัสข้อมูลในฟอร์มและการร้องขอ HTTP เพื่อป้องกันการแทรกสคริปต์ที่เป็นอันตราย
- การหลีกเลี่ยงการแสดงผลข้อมูลที่ไม่ได้รับการตรวจสอบ: หลีกเลี่ยงการแสดงผลข้อมูลจากผู้ใช้โดยตรงโดยไม่ผ่านการตรวจสอบและทำความสะอาด
.
ถึงแม้ไม่ได้ถูกโจมตีแบบ XSS ก็ขโมยข้อมูลจาก Local Storage, Cookie ได้เช่น Malware, Browser Extension พวกนี้ส่วนใหญ่จะมาจากฝั่ง User ไม่ใช่คนออกแบบระบบ .
ความปลอดภัยในทางปฏิบัติ.
- ทั้ง Local Storage และ HttpOnly Cookies มีความเสี่ยงในกรณีที่เกิดการโจมตีแบบ XSS หากผู้โจมตีสามารถ inject script ลงในเว็บไซต์ได้ เขาก็สามารถทำการโจมตีและเรียกใช้ API ในนามของผู้ใช้ได้เหมือนกัน ไม่ว่าจะเก็บ Token ไว้ที่ไหน
- ออกแบบ Access Token ให้มีอายุสั้น เพื่อลดผลกระทบหาก Token ถูกขโมย ใช้คู่กับ Refresh Token
- การป้องกัน XSS จึงเป็นสิ่งสำคัญที่สุด ไม่ว่าจะเลือกใช้วิธีการเก็บ Token แบบใด การทำความสะอาดข้อมูล (Data Sanitization) อย่าให้ script ใดๆ เข้าไปในระบบ และแสดงผลออกมาทำงานได้ และการตรวจสอบ Input อย่างเข้มงวดสามารถลดความเสี่ยงจากการโจมตีได้
.
สรุป.
การเก็บ Session Token ใน Local Storage ไม่ได้แย่เสมอไป ขึ้นอยู่กับการออกแบบระบบและการป้องกันความปลอดภัยที่มีอยู่ การใช้ HttpOnly Cookies อาจเพิ่มความยากลำบากในการโจมตีจาก XSS แต่ไม่ใช่วิธีการที่ปลอดภัยอย่างสมบูรณ์
.
การออกแบบระบบให้ปลอดภัยนั้นไม่สามารถพึ่งพาวิธีการเก็บ Token เพียงอย่างเดียวได้ ต้องพิจารณาปัจจัยหลายอย่างรวมถึงการป้องกัน XSS การใช้ Secure Cookies และการใช้ Token ที่มีอายุการใช้งานสั้น การออกแบบระบบความปลอดภัยต้องคำนึงถึงทุกจุดที่อาจเป็นช่องโหว่ เพื่อให้แน่ใจว่าระบบมีความปลอดภัยที่สุดเท่าที่จะเป็นไปได้
.
ในท้ายที่สุด การป้องกัน XSS และการรักษาความปลอดภัยในทุกๆ ด้านของระบบเป็นสิ่งที่สำคัญที่สุดในการปกป้องข้อมูลของผู้ใช้
.
ผมเตรียมเอกสารไว้อ่านเพิ่มเติมสำหรับคนที่อยากเข้าใจริงๆ และช่วยประกอบการตัดสินใจ (อยู่ใน Comment)
- Ref 1: การพูดคุยถกเถียงใน Community
- Ref 2: การโจมตีแบบ Cross Site Scripting (XSS)
- Ref 3: การใช้ HttpOnly Cookie ใน Session Token (JWT)
- Ref 4: พฤติกรรมของ HttpOnly Cookie ช่วยป้องกันอะไร
- Ref 5: ความปลอดภัยใน Cookie ทำงานอย่างไร
- Ref 6: ความปลอดภัยใน Local Storage
- Ref 7: ตัวอย่างการทำ SPA ให้ปลอดภัย
- Ref 8: เทคนิคการโจมตีแบบอื่นๆ
.
ก่อนจะจากกัน ในการออกแบบ Security ที่ดีเราควรเข้าใจถึงสิ่งที่เราต้องการทำ
รวมถึงความเสี่ยงที่เรารับได้แค่ไหน และอย่าลืมว่ายิ่งสะดวกสบาย ความปลอดภัยอาจจะลดลงได้
.
เพื่อให้มันเกิดประโยชน์ต่อเพื่อนๆ
ถ้ารู้สึกว่าตรงไหนไม่ถูกต้อง หรืออยากเสริมตรงไหน สามารถคอมเม้นต์ได้่เลยนะ
อย่างบอกไปโพสที่แล้ว สิ่งที่ผมพอทำได้คือเป็นจุดเริ่มการพูดคุย
อยากสร้าง Communtiy แบบนี้ครับ 
