guest@websec: ~/websec/01-introduction/th — zsh — 100×40 เขียนโดย SaKKo ENTH โค้ด:

guest@websec ~ % man 01-introduction

01 · บทนำ

Rails ให้ค่าเริ่มต้นที่ปลอดภัยมา แต่ไม่มีเฟรมเวิร์กไหนทำให้แอปปลอดภัยได้เองทั้งหมด

เฟรมเวิร์กกันความผิดพลาดที่มันคาดเดาได้ ที่เหลือเป็นหน้าที่ของเรา ตราบใดที่แอปยังออนไลน์

ทำไม "เฟรมเวิร์กที่ปลอดภัย" ยังไม่พอ

เฟรมเวิร์กสมัยใหม่ escape HTML ใส่ CSRF token และ parameterize query ให้ ซึ่งกำจัดบั๊กได้ทั้งกลุ่ม แต่ยังไม่พอ ด้วยเหตุผล 3 ข้อ:

  1. คน SQL ดิบบรรทัดเดียว หรือ route admin ที่ลืมตรวจสิทธิ์ ก็ทำลายทุกอย่างได้ Rails เดาไม่ได้ว่าหน้าไหนควรเป็นส่วนตัว
  2. ทั้ง stack เซิร์ฟเวอร์ ฐานข้อมูล proxy CI บัญชีคลาวด์ ถ้ามีคนอ่าน .env ได้ เทมเพลตดีแค่ไหนก็ไม่ช่วย
  3. เวลา การโจมตีและ CVE ใหม่ๆ มาทุกเดือน ความปลอดภัยคืองานดูแลต่อเนื่อง ไม่ใช่ทำครั้งเดียวจบ
Rails เริ่มต้นให้ดี: view ที่ escape แล้ว, CSRF token, query ที่ปลอดภัย, คุกกี้เข้ารหัส, strong params, security header แอปใหม่ยังมี Brakeman ใน CI ด้วย ให้เพิ่ม bundler-audit สำหรับ CVE ของ gem
ป้องกันให้โดยค่าเริ่มต้นบางส่วน: Rails ช่วย แต่ต้องตั้งค่าหรือทำต่อให้ครบหน้าที่เรา: Rails ไม่ได้ช่วยในเรื่องนี้

การโจมตีเกิดขึ้นที่ไหนจริงๆ

การเจาะระบบจริงส่วนใหญ่ไม่ได้ถอดรหัสอะไร แต่เดินเข้ามาทางบั๊กธรรมดา: ลืมตรวจสิทธิ์ ไม่ตรวจ input คุกกี้ที่ส่งผ่าน HTTP

sim: จุดที่อ่อนแอที่สุดลากแถบเลื่อน

ผู้โจมตีเลือกทางที่ง่ายที่สุด ระบบแข็งแรงได้เท่าจุดที่อ่อนที่สุดเท่านั้น


average strength:|what the attacker sees (minimum):

เนื้อหาส่วนที่เหลือของคู่มือ

บทเรียนแบ่งเป็นห้าส่วน เรียงสำหรับทีมที่เพิ่งเริ่มเรื่องความปลอดภัย: injection มาก่อน (02–04 เริ่มจาก SQL injection ที่ทีมเราเคยโดน) ต่อด้วยบัญชีผู้ใช้และการควบคุมสิทธิ์ (05–09) ฝั่งเบราว์เซอร์ (10–12) ฝั่งเซิร์ฟเวอร์และ secret (13–17) และการดูแลระบบ (18–22) แบบทดสอบอยู่ท้ายสุด ให้อ่านตามลำดับ เพราะบทหลังๆ ต่อยอดจากบทก่อนหน้า