ฉันจะใช้งานวิศวกรรมมากเกินไปหากฉันพิจารณาการทำผิดโดยเจตนาของผู้ใช้หรือไม่

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

เพื่อชี้แจงฉันกำลังเปิดเผยบริการ JSON RESTful แบบนี้:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

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

การรับรองความถูกต้องจะทำกับการตรวจสอบขั้นพื้นฐานผ่าน SSL

ฉันกำลังพูดถึงพฤติกรรม "อันตราย" ที่เป็นไปได้เช่นนี้:

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

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

หรือฉันควรปล่อย Basic Auth ทั้งหมดกำจัด GET และใช้เฉพาะ POST / PUT ที่มีข้อมูลการอนุญาตในนั้น ในขณะที่การรับข้อมูลรางน้ำ GET นั้นยังมีความอ่อนไหว

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

Over-วิศวกรรม? ไม่ใช่เลย. มาตรการต่อต้าน XSRF เป็นส่วนที่จำเป็นของเว็บแอปพลิเคชันหรือบริการที่ปลอดภัย อาจหรือไม่“ ไม่น่าเป็นไปได้สูง” ที่บางคนจะเลือกที่จะโจมตีคุณ แต่นั่นไม่ได้ทำให้ซอฟต์แวร์ของคุณไม่ปลอดภัยน้อยลง

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

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

ฉันควรกำจัด GET

ไม่คำขอ GET ใช้สำหรับคำขอการอ่านที่ไม่มีการเขียนที่ใช้งานอยู่ (เป็น“ idempotent”) มันเป็นเพียงการดำเนินการเขียนที่ต้องการการป้องกัน XSRF

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

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

หากมีการสร้างและบำรุงรักษารหัสกรณีขอบควรได้รับการพิจารณาและจัดการเป็นกรณีไป

การแก้ไขเนื่องจากข้อผิดพลาดบางอย่างในส่วนของฉัน:

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

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

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

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

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

• บริการภายในที่ได้รับการป้องกันโดยไฟร์วอลล์ที่มั่นคงมีโอกาสน้อยที่จะถูกโจมตีมากกว่าบริการบนอินเทอร์เน็ตสาธารณะ

• ผลกระทบจากการที่คนใช้กระดานสนทนาลูกค้าน้อยกว่าผลกระทบของพวกเขาที่ขโมยบัตรเครดิตของลูกค้า

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