ตอนที่หนึ่งของชุดนี้ครอบคลุมการจู่โจมแบบฉีด

ในบทความที่ 2 ของซีรีส์เกี่ยวกับ OWASP Top 10 Web Application Security Risks เราจะเจาะลึกเข้าไปในจักรวาลของการพิสูจน์ตัวตนที่เสียหายและภัยคุกคามการเปิดเผยข้อมูล

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

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

นอกจากนี้ เราจะลงรายละเอียดเกี่ยวกับข้อมูลที่ละเอียดอ่อนซึ่งไม่ได้รับการปกป้องอย่างเพียงพอ ซึ่งจะทำให้มีที่ว่างสำหรับช่องโหว่ต่างๆ ดังต่อไปนี้:

• การจัดเก็บข้อมูลที่ละเอียดอ่อนที่ไม่ปลอดภัย :เมื่อข้อมูลที่ละเอียดอ่อนถูกเข้ารหัสด้วยอัลกอริธึมที่อ่อนแอ เช่น MD5
• การเปิดเผยข้อมูลที่ละเอียดอ่อน :เมื่อนักพัฒนาเปิดเผยข้อมูลที่ละเอียดอ่อนที่ไม่ได้เข้ารหัสโดยไม่ได้ตั้งใจใน URL หรือฟิลด์ที่ซ่อนอยู่ เป็นต้น

เช่นเดียวกับบทความแรกในซีรีส์ เราจะใช้ RailsGoat เพื่อสำรวจภัยคุกคามเหล่านี้ในทางปฏิบัติ หากคุณเพิ่งเข้ามาใหม่ โปรดอ่านบทความก่อนหน้าเพื่อตั้งค่าและเรียกใช้แอป

กระโดดเข้าไปเลย!

ภัยคุกคามการตรวจสอบสิทธิ์

เราไม่สามารถอยู่ได้โดยปราศจากการตรวจสอบ ไม่ว่าจะเป็นใน back-end APIs หรือภายในแบบฟอร์ม front-end ก็เป็นหนึ่งในขั้นตอนที่สำคัญที่สุดในการพัฒนาแอปพลิเคชัน เนื่องจากเน้นขีดจำกัดของมาตรการรักษาความปลอดภัยของคุณ

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

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

การแจงนับผู้ใช้

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

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

หน้าเข้าสู่ระบบ Facebook

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

ข้อความชื่อผู้ใช้ไม่ถูกต้อง

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

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

ข้อความรหัสผ่านไม่ถูกต้อง

เมื่อผู้โจมตีรู้ว่าระบบตอบสนองต่อการตรวจสอบแต่ละครั้งแยกกันอย่างไร ก็สามารถสร้างรายการของ possible users และรหัสผ่านทั่วไป/ไม่รัดกุม จากนั้นจึงทำการทดสอบโดยใช้กำลังเดรัจฉานซ้ำกับระบบได้จนกว่าจะมีการเข้าถึง

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

สิ่งหนึ่งที่คุณสามารถทำได้เพื่อหลีกเลี่ยงการแจงนับผู้ใช้คือ ตรวจสอบทั้งชื่อผู้ใช้และรหัสผ่านร่วมกัน และส่งคืนข้อความทั่วไป มาดูแนวทางปฏิบัติกัน!

ภัยคุกคามในการดำเนินการ

ในแอป RailsGoat ให้เปิด user.rb ไฟล์ใน app/models โฟลเดอร์และค้นหา authenticate กระบวนการ. ภายในนั้น คุณอาจพบข้อมูลโค้ดต่อไปนี้:

raise "#{email} doesn't exist!" if !(user)
if user.password == Digest::MD5.hexdigest(password)
  auth = user
else
  raise "Incorrect Password!"
end

อย่างแน่นอน! ข้อความถูกตั้งค่าเพื่อให้ผู้โจมตีทราบว่าผู้ใช้ไม่มีอยู่จริงหรือรหัสผ่านไม่ถูกต้อง

ทดสอบออก ไปที่หน้าเข้าสู่ระบบ RailsGoat แล้วพิมพ์อีเมลและรหัสผ่านแบบสุ่ม คุณอาจเห็นข้อความแสดงข้อผิดพลาดต่อไปนี้:

ไม่มีผู้ใช้รายนี้

มิฉะนั้น ถ้ามีผู้ใช้อยู่ (ken@metacorp.com ตัวอย่างเช่น) แต่รหัสผ่านไม่ถูกต้อง ข้อความต่อไปนี้จะปรากฏขึ้น:

รหัสผ่านไม่ถูกต้อง

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

วิธีแก้ปัญหานี้

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

ภายใน sessions_controller.rb (app/controllers โฟลเดอร์) ค้นหา create เมธอดและเปลี่ยนข้อมูลโค้ดต่อไปนี้

flash[:error] = e.message

ดังต่อไปนี้:

flash[:error] = "Your credentials aren't valid."

ตอนนี้ ทุกครั้งที่ผู้ใช้พิมพ์ชื่อผู้ใช้หรือรหัสผ่านผิด นั่นคือข้อความที่พวกเขาจะได้รับ:

ข้อมูลประจำตัวไม่ถูกต้อง

อีกวิธีในการดำเนินการคือเปลี่ยนข้อความสองข้อความภายใน users.rb รุ่น

รหัสผ่านที่อ่อนแอ

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

นี่เป็นหนึ่งในขั้นตอนที่สำคัญที่สุดในการป้องกันการแจงนับผู้ใช้

ภัยคุกคามในการดำเนินการ

ใน RailsGoat ให้เปิด user.rb ไฟล์และค้นหาโค้ดบรรทัดแรกก่อนนิยามคลาส:

validates :password,
    presence: true,
    confirmation: true,
    length: {
      within: 6..40
    },

    ...

นี่เป็นตัวอย่างที่ชัดเจนของรหัสผ่านที่ถูกตรวจสอบอย่างไม่รัดกุม เนื่องจากมีการตรวจสอบเฉพาะความยาวเท่านั้น

วิธีแก้ปัญหานี้

การแก้ปัญหาค่อนข้างง่าย ตรวจสอบรหัสผ่านของคุณกับข้อกำหนดที่เข้มงวดกว่านี้ เช่น:

• อย่างน้อย 1 ตัวพิมพ์เล็กและ 1 ตัวพิมพ์ใหญ่
• อย่างน้อย 1 หลัก
• อย่างน้อย 10 ตัวอักษร

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

ในการแก้ปัญหานี้ภายใน RailsGoat เพียงแทนที่คุณสมบัติ length ด้วยค่าต่อไปนี้:

:format => {:with => /\A.*(?=.*[a-zA-Z])(?=.*[0-9])(?=.{10,}).*\z/},

จากนั้นไปที่หน้าลงทะเบียน กรอกข้อมูลในฟิลด์ และระบุรหัสผ่านที่ไม่รัดกุม เมื่อคุณส่ง ข้อความแสดงข้อผิดพลาดจะปรากฏขึ้น:

รหัสผ่านไม่ถูกต้อง

คุกกี้ไม่จำกัด

ในบทความก่อนหน้านี้ เราได้อุทิศเวลาบางส่วนเพื่อทำความเข้าใจว่าการโจมตี XSS เกิดขึ้นได้อย่างไร เนื่องจากเกิดขึ้นโดยอนุญาตให้ผู้โจมตีเรียกใช้สคริปต์ที่เป็นอันตราย ข้อมูลสำคัญอาจถูกขโมยจากคุกกี้ของเซสชัน หากเราไม่ป้องกันการเข้าถึงแอตทริบิวต์ เช่น document.cookie ในโค้ด JavaScript ของคุณ

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

ในทางกลับกัน คุกกี้จะปลอดภัยขึ้นเล็กน้อยหากคุณทำตามขั้นตอนที่ถูกต้องเพื่อสร้างคุกกี้ เช่น การตั้งค่า HttpOnly ธง.

กล่าวโดยย่อ คุกกี้ที่เก็บข้อมูลเซสชันและตั้งค่าด้วย HttpOnly ไม่สามารถเข้าถึงการตั้งค่าสถานะจาก JavaScript Document.cookie เอพีไอ วิธีนี้เฉพาะเซิร์ฟเวอร์เท่านั้นที่จะได้รับ

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

ภัยคุกคามในการดำเนินการ

Rails ช่วยคุณด้วยการตั้งค่าคุกกี้ทั้งหมดโดยอัตโนมัติด้วย HttpOnly ธง. วิธีนี้ยอดเยี่ยมเพราะช่วยให้นักพัฒนาที่ไม่รู้ตัวหลีกเลี่ยงการถูกแฮ็กแอป

ในการทดสอบตัวอย่างนี้ เราต้องปิดการใช้งานคุณสมบัตินี้ ซึ่ง RailsGoat ทำอย่างชัดเจนภายใน session_store.rb ไฟล์ที่อยู่ใน config/initializers โฟลเดอร์ ลองดูสิ!

จากนั้น ไปที่หน้าลงทะเบียนอีกครั้ง กรอกข้อมูลในช่องให้ถูกต้อง และป้อนเนื้อหาต่อไปนี้ลงใน ชื่อ ฟิลด์:

<script>
  alert(document.cookie);
</script>

เมื่อคุณส่งแบบฟอร์ม ระบบจะสร้างผู้ใช้พร้อมกับข้อความแจ้งเตือนต่อไปนี้:

ข้อความแจ้งเตือนเปิดเผยคุกกี้เซสชัน RailsGoat

วิธีแก้ปัญหานี้

ในกรณีนี้ ค่อนข้างตรงไปตรงมา อย่าปิดการใช้งาน HttpOnly ตั้งค่าสถานะในแอป Rails ของคุณ

ดังนั้น ให้ลบ httponly: false การตั้งค่าและรีสตาร์ทเซิร์ฟเวอร์ เมื่อคุณพยายามดำเนินการแบบเดียวกัน ข้อความเตือนต่อไปนี้จะปรากฏขึ้น:

ไม่มีข้อความแจ้งเตือน

สถานการณ์อื่นๆ

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

การปิดแท็บเบราว์เซอร์เพียงอย่างเดียวไม่เพียงพอต่อการออกจากระบบแอปพลิเคชัน

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

อย่างไรก็ตาม นี่คือครึ่งทางของการโจมตีด้วยการขโมย

การเปิดเผยข้อมูลที่ละเอียดอ่อน

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

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

นอกจากนั้น ขึ้นอยู่กับพื้นที่ธุรกิจเฉพาะที่แอปพลิเคชันของคุณกำลังทำงานอยู่ สิ่งสำคัญคือต้องปรึกษากฎหมายท้องถิ่นเพื่อพิจารณาว่ากฎการปฏิบัติตามข้อกำหนดอื่นๆ มีผลบังคับใช้ด้วยหรือไม่

ต่อไปนี้คือตัวอย่างที่ชัดเจนของช่องโหว่นี้:

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

มาวิเคราะห์สถานการณ์ทั่วไปบางส่วนกัน

ที่เก็บข้อมูลที่มีความละเอียดอ่อนที่ไม่ปลอดภัย

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

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

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

ภัยคุกคามในการดำเนินการ

ดังที่เราได้เห็นแล้ว RailsGoat ตั้งใจเก็บรหัสผ่านของผู้ใช้ไว้เป็นแฮช MD5 คุณสามารถดูสิ่งนี้ได้ใน user.rb รุ่น:

def hash_password
  if self.password.present?
      self.password = Digest::MD5.hexdigest(password)
  end
end

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

วิธีแก้ปัญหานี้

มีหลายวิธีในการแก้ไขปัญหานี้ แต่บางทีวิธีหนึ่งที่มีชื่อเสียงที่สุดคือการใช้แฮชเกลือ เช่น วิธีที่ BCrypt จัดหาให้

แม้ว่า Rails จะมาพร้อมกับความสามารถเริ่มต้นในการจัดการกับ Bcrypt แต่ lib ที่มีชื่อเสียงก็ถูกใช้อย่างกว้างขวางเพื่อจุดประสงค์นี้:bcrypt-ruby:

gem install bcrypt

เมื่อคุณแมปโมเดลของคุณกับโมเดล รหัสผ่านจะถูกตั้งค่าและรับจากฐานข้อมูลอย่างไร lib ปรับทุกอย่างอื่นโดยอัตโนมัติ:

require 'bcrypt'

class User < ActiveRecord

  include BCrypt

  def password
    @password ||= Password.new(password_hash)
  end

  def password=(new_password)
    @password = Password.create(new_password)
    self.password_hash = @password
  end
end

อย่างไรก็ตาม โฟลว์ต้องการคอลัมน์สตริงเพิ่มเติม (password_hash ) ที่ตารางเพื่อจัดเก็บแฮชรหัสผ่านสำหรับอัลกอริธึม BCrypt

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

เปิดเผยมากเกินไป

ไม่ว่าคุณจะทำงานกับ REST API หรือจุดปลาย GraphQL ตรวจสอบให้แน่ใจว่าได้ส่งคืนเฉพาะที่จำเป็นเพื่อให้ไคลเอ็นต์ทำงานได้

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

ตรวจสอบ API ของคุณเสมอเพื่อรับรองว่าไม่ว่าข้อมูลที่ละเอียดอ่อนจะถูกส่งคืนมาก็ตาม ก็จะทำเช่นนั้นด้วยการเข้ารหัสที่เหมาะสมและอยู่ในที่ที่เหมาะสมเท่านั้น

ภัยคุกคามในการดำเนินการ

เมื่อพูดถึงข้อมูลของผู้ใช้ สิ่งสำคัญคือต้องสร้างกลไกการรักษาความปลอดภัยเพื่อให้แน่ใจว่าข้อมูลที่สำคัญจะไม่รั่วไหล

เปิด users_controller.rb ไฟล์ใน api/v1 โฟลเดอร์ คุณจะพบวิธีการดังต่อไปนี้:

def show
  respond_with @user.as_json
end

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

ไม่ใช่แค่ user โมเดลแต่รวมถึงโมเดลอื่นๆ ที่มีข้อมูลที่ละเอียดอ่อนจำเป็นต้องเลือกแอตทริบิวต์ที่ API จะมองเห็นได้

วิธีแก้ปัญหานี้

โชคดีที่ Rails มีวิธีที่ง่ายมากในการจัดการกับมัน เรามาแทนที่ as_json . กัน ด้วยวิธีการดังต่อไปนี้:

def as_json
  super(only: [:id, :email])
end

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

สรุปผล

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

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

แล้วพบกันใหม่ป้ายหน้า!