วิธีปฏิบัติที่ดีที่สุดสำหรับการรักษาความปลอดภัย REST API / บริการบนเว็บ [ปิด]

828

เมื่อออกแบบ REST API หรือบริการจะมีแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการด้านความปลอดภัย (การรับรองความถูกต้องการอนุญาตการจัดการข้อมูลผู้ใช้)?

เมื่อสร้าง SOAP API คุณจะต้องมี WS-Security เป็นแนวทางและมีเอกสารมากมายในหัวข้อ ฉันพบข้อมูลน้อยลงเกี่ยวกับการรักษาจุดสิ้นสุด REST

ในขณะที่ฉันเข้าใจว่า REST โดยเจตนาไม่มีข้อกำหนดเหมือนกับ WS- * ฉันหวังว่าวิธีปฏิบัติที่ดีที่สุดหรือรูปแบบที่แนะนำได้เกิดขึ้นแล้ว

การอภิปรายหรือลิงค์ไปยังเอกสารที่เกี่ยวข้องจะได้รับการชื่นชมอย่างมาก หากเป็นเรื่องสำคัญเราจะใช้ WCF กับข้อความ POX / JSON ต่อเนื่องสำหรับ REST API ของเรา / บริการที่สร้างโดยใช้ v3.5 ของ. NET Framework

wcf  security  rest  authorization  rest-security 
— นาธาน
แหล่งที่มา
1
คุณรู้จักแอปพลิเคชั่นเต็มรูปแบบตัวจริงที่ใช้รูปแบบและวิธีปฏิบัติที่ดีกับ REST API และ webServices in github หรือไม่?
— PreguntonCojoneroCabrón

คำตอบ:

298

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

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

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

— เกร็กฮิวกิล
แหล่งที่มา
3
SSL เป็นส่วนสำคัญของความปลอดภัย แต่ไม่ใช่ทุกแอปพลิเคชันที่ต้องการระดับการเข้ารหัส หากมีใครขโมยในระหว่างการขนส่งสิ่งที่คุณกำลังโพสต์ต่อสาธารณะบน Twitter นั่นคือข้อเสียเปรียบที่สำคัญอย่างนั้นหรือ สำหรับการเข้ารหัส SSL ส่วนใหญ่นั้นเป็นที่ต้องการมากกว่า ความต้องการโครงสร้างพื้นฐานของ SSL ค่อนข้างสูงกว่าด้วยเท็กซ์เท็กซ์และไม่มีแคชเซิร์ฟเวอร์ (ตามขอบ) สามารถมีส่วนร่วมในการแคชของเนื้อหาที่เข้าถึงซ้ำแล้วซ้ำอีก ระวังความสามารถในการขยายของคุณอาจลดลงหากคุณต้องการการเข้ารหัสที่นำเสนอ
— นอร์แมน H
36
@NormanH: ข้อโต้แย้งของคุณเป็นเรื่องที่กว้างขวางเพราะถ้าใครสามารถเห็นการทำธุรกรรมทั้งหมดที่ฉันใช้ในการโพสต์ไปที่ Twitter พวกเขาสามารถเลียนแบบฉันและโพสต์ข้อความของตัวเองภายใต้ชื่อของฉัน
— เกร็กฮิวกิล
3
การอ้างอิงจากวิกิพีเดียเกี่ยวกับการรับรองความถูกต้องของ Digest "การรับรองความถูกต้องของการเข้าถึง Digest เป็นหนึ่งในวิธีการที่ตกลงกันซึ่งเว็บเซิร์ฟเวอร์สามารถใช้ในการเจรจาต่อรองข้อมูลประจำตัวกับเว็บเบราว์เซอร์ของผู้ใช้ ปลอดภัยกว่าการตรวจสอบสิทธิ์การเข้าถึงพื้นฐานซึ่งส่งข้อความธรรมดา " ซึ่งจะเป็นวิธีมาตรฐานหนึ่งในการบรรลุสิ่งที่ฉันพูดถึงข้างต้น (ดูen.wikipedia.org/wiki/Digest_access_authenticationสำหรับรายละเอียด)
— Norman H
5
"sending plaintext passwords over the net is almost universally a bad thing"- คุณสามารถอธิบายรายละเอียดเกี่ยวกับ "เกือบ" ได้หรือไม่? เมื่อไรมันจึงเป็นความคิดที่ไม่ดี?
— toniedzwiedz
2
@GregHewgill แม้ในเครือข่ายส่วนตัวฉันไม่ต้องการให้ผู้ใช้ของฉันสามารถดักรหัสผ่านของกันและกันได้ สถานการณ์เดียวที่ฉันนึกได้ซึ่งการส่งรหัสผ่านผ่านเครือข่ายก็คือเมื่อผู้ใช้อยู่คนเดียวในเครือข่าย ความจริงที่ว่าสิ่งเหล่านี้เกิดขึ้นที่อื่นแทบจะไม่เป็นเหตุผลที่จะอนุญาต
— toniedzwiedz
115

ไม่มีมาตรฐานสำหรับ REST นอกเหนือจาก HTTP มีบริการ REST ที่กำหนดไว้แล้ว ฉันขอแนะนำให้คุณดูพวกเขาและทำความเข้าใจกับวิธีการทำงานของพวกเขา

ตัวอย่างเช่นเรายืมความคิดมากมายจากบริการ S3 REST ของ Amazon เมื่อพัฒนาของเราเอง แต่เราเลือกที่จะไม่ใช้รูปแบบการรักษาความปลอดภัยขั้นสูงตามลายเซ็นคำขอ วิธีที่ง่ายกว่าคือ HTTP Basic auth over SSL คุณต้องตัดสินใจว่าอะไรดีที่สุดในสถานการณ์ของคุณ

นอกจากนี้ฉันขอแนะนำหนังสือRESTful Web Servicesจาก O'reilly มันอธิบายแนวคิดหลักและมีแนวทางปฏิบัติที่ดีที่สุด โดยทั่วไปคุณสามารถนำโมเดลที่มีให้และแมปไปยังแอปพลิเคชันของคุณเอง

— มาร์ค Renouf
แหล่งที่มา
6
บริการเว็บสงบเป็นหนังสือที่ดีแน่นอน ต้องอ่านในพื้นที่นี้ มันเป็นแรงบันดาลใจอย่างจริงจัง
— EdgarVerona
6
@aehlke ได้รับ upvotes มากมายสำหรับความคิดเห็นที่พิจารณา (1) ไม่มีสิ่งเช่น REST Specification และ (2) Fielding Dissertation ในรูปแบบสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่ายระบุ REST อย่างชัดเจน และ HTTP เป็น 6.3: REST นำไปใช้กับ HTTP
20
HTTP ไม่ใช่ข้อกำหนดสำหรับ REST
— nategood
1
หนังสือ RESTful Web Services มีให้บริการฟรีจากเว็บไซต์ของพวกเขา: crummy.com/writing/RESTful-Web-Services
— icc97
ฉันวางแผนที่จะอ่านหนังสือแล้วฉันก็รู้ว่ามันเป็นเป้าหมายหลักสำหรับรูปแบบ XML ฉันควรใช้หนังสือเล่มนี้พิจารณาความนิยมของ JSON หรือไม่ หรือไม่ขึ้นอยู่กับรูปแบบการแลกเปลี่ยนข้อมูล ต้องการคำแนะนำ
— Bhargav Jhaveri
72

คุณอาจต้องการดูOAuthซึ่งเป็นโพรโทคอลแบบเปิดที่เกิดขึ้นใหม่สำหรับการให้สิทธิ์แบบใช้โทเค็นซึ่งกำหนดเป้าหมายเป็น http apis โดยเฉพาะ

มันคล้ายกับวิธีที่ดำเนินการโดยflickrและจดจำนม "rest" apis (ไม่จำเป็นต้องเป็นตัวอย่างที่ดีของ apis พักผ่อน แต่เป็นตัวอย่างที่ดีของวิธีที่ใช้โทเค็น)

— John Spurlock
แหล่งที่มา
3
แต่ดูเหมือนว่า oAuth แบบ 2 ขาซึ่งฉันคิดว่าเป็นสิ่งที่ต้องการที่นี่ไม่ครอบคลุม (ขาดข้อมูล) เท่าที่ขา 3 ขา
— redben
4
OAuth เกี่ยวกับการมอบอำนาจเช่นฉันเป็นเจ้าของข้อมูล / บัญชีให้บริการ A โต้ตอบกับข้อมูลของฉันในบริการ B (เช่นฉันปล่อยให้ Twitter เขียนบน facebook ของฉัน) มันไม่ได้รับอนุญาตในแง่ที่กว้างขึ้นซึ่งเกี่ยวกับการควบคุมสิ่งที่ผู้ใช้สามารถทำกับทรัพยากร (ข้อมูลข้อมูลบริการ ... ) นี่คือที่ที่ XACML เข้าสู่ขั้นตอน XACML ให้คุณกำหนดนโยบายการให้สิทธิ์ว่าใครสามารถทำอะไรได้บ้าง
— David Brossard
60

พบรายการตรวจสอบที่ยอดเยี่ยมในGithub :

การรับรอง

  • อย่าสร้างวงล้อใหม่ในการตรวจสอบสิทธิ์การสร้างโทเค็นที่เก็บรหัสผ่าน ใช้มาตรฐาน

  • ใช้Max Retryและจำคุกคุณสมบัติในการเข้าสู่ระบบ

  • ใช้การเข้ารหัสข้อมูลที่สำคัญทั้งหมด

JWT (โทเค็นเว็บ JSON)

  • ใช้คีย์ที่ซับซ้อนแบบสุ่ม (JWT Secret) เพื่อทำให้เดรัจฉานบังคับให้โทเค็นยากมาก

  • อย่าแยกอัลกอริทึมจากส่วนของข้อมูล บังคับใช้อัลกอริทึมในแบ็กเอนด์ (HS256 หรือ RS256)

  • ทำให้โทเค็นหมดอายุ ( TTL, RTTL) สั้นที่สุดเท่าที่จะทำได้

  • อย่าเก็บข้อมูลที่ละเอียดอ่อนไว้ในเพย์JWTโหลดมันสามารถถอดรหัสได้อย่างง่ายดาย

OAuth

  • ตรวจสอบredirect_uriฝั่งเซิร์ฟเวอร์เสมอเพื่อให้อนุญาต URL ที่อนุญาตเท่านั้น

  • พยายามแลกเปลี่ยนรหัสเสมอและไม่ใช้โทเค็น (ไม่อนุญาตresponse_type=token)

  • ใช้พารามิเตอร์ของรัฐที่มีกัญชาสุ่มเพื่อป้องกันCSRFในOAuthกระบวนการตรวจสอบ

  • กำหนดขอบเขตเริ่มต้นและตรวจสอบพารามิเตอร์ขอบเขตสำหรับแต่ละแอปพลิเคชัน

เข้าไป

  • จำกัด การร้องขอ (Throttling) เพื่อหลีกเลี่ยงการโจมตี DDoS / brute-force

  • ใช้ HTTPS ทางฝั่งเซิร์ฟเวอร์เพื่อหลีกเลี่ยง MITM (Man In The Middle Attack)

  • ใช้HSTSส่วนหัวด้วย SSL เพื่อหลีกเลี่ยงการโจมตี SSL Strip

อินพุต

  • ใช้วิธี HTTP ที่เหมาะสมตามการดำเนินการ: GET(อ่าน), POST(สร้าง), PUT/PATCH(แทนที่ / อัปเดต) และDELETE(เพื่อลบบันทึก) และตอบกลับด้วย405 Method Not Allowedหากวิธีที่ร้องขอนั้นไม่เหมาะสมสำหรับทรัพยากรที่ร้องขอ

  • ตรวจสอบชนิดเนื้อหาตามคำขอAcceptส่วนหัว (การเจรจาต่อรองเนื้อหา) ให้มีเพียงรูปแบบของคุณได้รับการสนับสนุน (เช่นapplication/xml, application/jsonฯลฯ ) และตอบสนองกับ406 Not Acceptableการตอบสนองถ้าไม่ตรง

  • ตรวจสอบcontent-typeข้อมูลที่โพสต์เป็นคุณยอมรับ (เช่นapplication/x-www-form-urlencoded, multipart/form-data, application/jsonฯลฯ )

  • ตรวจสอบการป้อนข้อมูลของผู้ใช้เพื่อหลีกเลี่ยงช่องโหว่ทั่วไป (เช่น XSS, SQL-Injection, การเรียกใช้โค้ดจากระยะไกล ฯลฯ )

  • อย่าใช้ข้อมูลที่ละเอียดอ่อน (ข้อมูลประจำตัวรหัสผ่านโทเค็นความปลอดภัยหรือคีย์ API) ใน URL แต่ใช้Authorizationส่วนหัวมาตรฐาน

  • ใช้บริการ API เกตเวย์เพื่อเปิดใช้งานการแคชRate Limitนโยบาย (เช่นโควต้าการขัดขวางการ จำกัด อัตราการเกิดพร้อมกัน) และปรับใช้ทรัพยากร API แบบไดนามิก

การประมวลผล

  • ตรวจสอบว่าอุปกรณ์ปลายทางทั้งหมดได้รับการปกป้องด้านหลังการพิสูจน์ตัวตนหรือไม่เพื่อหลีกเลี่ยงกระบวนการตรวจสอบสิทธิ์ที่เสีย

  • ID ทรัพยากรของผู้ใช้ควรหลีกเลี่ยง ใช้ / me / orders แทน / user / 654321 / orders

  • อย่าเพิ่ม ID อัตโนมัติ ใช้ UUID แทน

  • หากคุณกำลังวิเคราะห์ไฟล์ XML ตรวจสอบให้แน่ใจว่าเอนทิตีการแยกวิเคราะห์ไม่ได้เปิดใช้งานเพื่อหลีกเลี่ยง XXE (การโจมตีเอนทิตีภายนอก XML)

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

  • ใช้ CDN สำหรับการอัปโหลดไฟล์

  • หากคุณกำลังเผชิญกับข้อมูลจำนวนมากให้ใช้ Workers and Queues เพื่อประมวลผลให้มากที่สุดเท่าที่จะทำได้ในเบื้องหลังและตอบกลับอย่างรวดเร็วเพื่อหลีกเลี่ยง HTTP Blocking

  • อย่าลืมปิดโหมดDEBUG

เอาท์พุต

  • ส่งX-Content-Type-Options: nosniffส่วนหัว

  • ส่งX-Frame-Options: denyส่วนหัว

  • ส่งContent-Security-Policy: default-src 'none'ส่วนหัว

  • นำลายนิ้วมือหัว - X-Powered-By, Server, X-AspNet-Versionฯลฯ

  • กองทัพcontent-typeสำหรับการตอบสนองของคุณถ้าคุณกลับมาแล้วการตอบสนองชนิดเนื้อหาของคุณapplication/jsonapplication/json

  • อย่าส่งคืนข้อมูลที่ละเอียดอ่อนเช่นข้อมูลรับรองรหัสผ่านโทเค็นความปลอดภัย

  • ส่งคืนรหัสสถานะที่เหมาะสมตามการดำเนินการที่เสร็จสมบูรณ์ (เช่น200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowedฯลฯ )

— Andrejs
แหล่งที่มา
1
รายการที่ดีแม้ว่าจะมีความเห็นเล็กน้อย - และมันเริ่มต้นด้วย imho ไร้สาระ: "อย่าใช้การรับรองความถูกต้องเบื้องต้นใช้การรับรองความถูกต้องมาตรฐาน (เช่น JWT, OAuth)" คุณไม่สามารถรับมาตรฐาน y ได้มากกว่า Basic Auth และมีตำแหน่งโดยเฉพาะสำหรับ API ที่ไคลเอ็นต์ไม่ใช่เบราว์เซอร์ (สำหรับเบราว์เซอร์ JWT มักจะเหมาะสมกว่า) OAuth ตรงกันข้ามใช้ชุดการประนีประนอมอื่นทั้งหมดสำหรับการรับรองความถูกต้องและไม่สามารถเปรียบเทียบได้กับ Basic Auth และ JWT
— johndodo
คุณขวา BasicAuth ด้วย HTTPS เป็นเรื่องธรรมดา แต่ก็เป็นที่ถกเถียงกันอย่างถึงพริกถึงขิง - security.stackexchange.com/questions/988/... ฉันจะลบประเด็นนี้ออกไป
— Andrejs
43

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

— stinkymatt
แหล่งที่มา
ที่จริงแล้วเราใช้สิ่งนี้สำหรับการผสานรวมเช่นเดียวกับอุโมงค์ vpn ที่เข้ารหัสเพื่อสนับสนุนระบบเก่าที่เราไม่ได้ควบคุมที่ไม่สามารถสื่อสารผ่าน https ได้
— Casey
ใบรับรองไคลเอ็นต์สามารถสร้างปัญหาได้เมื่อคุณต้องการโหลดบาลานซ์ ... สามารถทำได้ แต่จะไม่ส่งตรงไปข้างหน้าน้อยลง
— Jeremy Logan
2
@fiXedd - สิ่งที่ตรงกันข้ามคือประสบการณ์ของฉันที่มีต่อลูกค้าเพราะพวกเขาไร้สัญชาติอย่างแท้จริง การเชื่อมต่อที่ผ่านการรับรองความถูกต้องของไคลเอนต์สามารถโหลดได้สมดุลกับ load balancer โดยไม่คำนึงถึงความเหนียวของการเชื่อมต่อเพราะพวกเขาต้องการสถานะที่ใช้ร่วมกันอย่างไม่มีศูนย์ระหว่างไคลเอนต์และเซิร์ฟเวอร์
— กลิ่นเหม็น
4
โอ้คุณทำได้ .... คุณสามารถให้ load balancer ส่งต่อทราฟฟิก TCP แต่คุณไม่สามารถมี load balancer เป็นจุดสิ้นสุดสำหรับ SSL
— Jeremy Logan
จะยังคงปลอดภัยหรือไม่หากใบรับรองไคลเอ็นต์และสิทธิ์การใช้งานรูทเป็นแบบลงชื่อด้วยตนเอง สิทธิรูตจะถูกอิมพอร์ตไปยังหน่วยงานผู้ออกใบรับรองรูทที่เชื่อถือได้ของลูกค้า
— จอยซ์
38

ทุกคนในคำตอบเหล่านี้มองข้ามการควบคุมการเข้าถึง / การอนุญาตที่แท้จริง

หากตัวอย่างเช่น REST APIs / บริการเว็บของคุณเกี่ยวกับ POSTing / GETing เวชระเบียนคุณอาจต้องการกำหนดนโยบายควบคุมการเข้าถึงว่าใครสามารถเข้าถึงข้อมูลและภายใต้สถานการณ์ใด ตัวอย่างเช่น

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

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

มาตรฐานอื่น ๆ ที่นี่มีไว้สำหรับต่อไปนี้:

  • OAuth: id การรวมกลุ่มและการมอบอำนาจเช่นให้บริการกระทำในนามของฉันในบริการอื่น (Facebook สามารถโพสต์ไปยัง Twitter ของฉัน)
  • SAML: การระบุตัวตน / เว็บ SSO SAML นั้นเกี่ยวกับว่าผู้ใช้คือใคร
  • มาตรฐาน WS-Security / WS- *: เน้นการสื่อสารระหว่างบริการ SOAP มีความเฉพาะเจาะจงกับรูปแบบการส่งข้อความระดับแอปพลิเคชัน (SOAP) และพวกเขาจัดการกับแง่มุมของการส่งข้อความเช่นความน่าเชื่อถือ, ความปลอดภัย, ความลับ, ความสมบูรณ์, อะตอมมิก, อีเวนติ้ง ... ไม่มีการควบคุมการเข้าถึงที่ครอบคลุม

XACML เป็นผู้ไม่เชื่อเรื่องเทคโนโลยี สามารถใช้กับแอปพลิเคชัน Java,. NET, Python, Ruby ... บริการบนเว็บ, REST API และอื่น ๆ

ต่อไปนี้เป็นแหล่งข้อมูลที่น่าสนใจ:

— David Brossard
แหล่งที่มา
2
ฉันไม่เข้าใจว่าทำไมคุณไม่สามารถใช้ระบบโทเค็นที่จะได้รับผู้ใช้และสิทธิ์ของเขาซึ่งเป็นสิ่งเดียวกัน
— Stan
คุณสามารถใช้วิธีตามโทเค็น มันใช้งานได้ดีเช่นกัน แต่คุณยังต้องใช้ตรรกะที่กำหนดว่าจะให้สิทธิ์ใดที่ผู้ใช้ได้รับในคำอื่น ๆ ซึ่งสิทธิ์ที่จะแทรกภายในโทเค็น นั่นคือสิ่งที่ XACML สามารถช่วยให้คุณประสบความสำเร็จ นอกจากนี้ยังหลีกเลี่ยงโทเค็นบวม
— David Brossard
2
ในฐานะที่เป็นความคิดเห็นด้านข้าง "9 ถึง 5" มีส่วนในการรักษาความปลอดภัยอย่างไร ราวกับว่าผู้โจมตีมีการใช้งานในเวลากลางคืนเท่านั้น? อย่าพูดถึงความหมายของการใช้อย่างรุนแรงราวกับว่าแพทย์จะทำงาน "9 ถึง 5" เท่านั้น
— Roland
นั่นเป็นข้อกำหนดทั่วไปในสถานการณ์ด้านการดูแลสุขภาพ ลองใช้ HL7 ดู มีสถานการณ์แตกแก้วเกินไปในกรณีที่แพทย์จะต้องเข้าถึงนอกเวลา สำหรับแฮกเกอร์เมื่อพวกเขาอยู่ในการเดิมพันทั้งหมดจะปิด
— David Brossard
1
เพื่อนร่วมงานของฉันบางคนกำลังตรวจสอบเรื่องนี้อยู่ ขอบคุณ @SimplyG
— David Brossard
25

ฉันใช้ OAuth สองสามครั้งและใช้วิธีอื่น (BASIC / DIGEST) ฉันขอแนะนำ OAuth ด้วยใจจริง ลิงค์ต่อไปนี้เป็นแบบฝึกหัดที่ดีที่สุดที่ฉันเคยเห็นในการใช้ OAuth:

http://hueniverse.com/oauth/guide/

— Rob Ottaway
แหล่งที่มา
แม้ว่านี่จะเป็นคำตอบที่เก่ามากที่เกี่ยวข้องกับ OAuth 1.0 แต่ก็น่าสังเกตว่าผู้เขียนลิงก์ที่คุณอ้างถึงได้กล่าวถึง OAuth 2.0 : "ฉันได้ข้อสรุปว่า OAuth 2.0 เป็นโปรโตคอลที่ไม่ดี ... เมื่อเทียบกับ OAuth 1.0, ข้อมูลจำเพาะ 2.0 นั้นซับซ้อน, ทำงานร่วมกันน้อยลง, มีประโยชน์น้อยลง, ไม่สมบูรณ์มากขึ้นและที่สำคัญที่สุดคือปลอดภัยน้อยลง " . เพื่อความชัดเจนความคิดเห็นที่ฉันอ้างถูกสร้างขึ้นมาหลายปีหลังจากที่คุณโพสต์คำตอบของคุณ
— skomisa
17

หนึ่งในโพสต์ที่ดีที่สุดที่ฉันเคยเจอเกี่ยวกับการรักษาความปลอดภัยที่เกี่ยวข้องกับส่วนที่เหลือเป็นมากกว่าที่1 RainDrop MySpace API นั้นใช้ OAuth เพื่อความปลอดภัยและคุณสามารถเข้าถึงช่องทางที่กำหนดเองได้อย่างเต็มที่ในรหัส RestChess ซึ่งฉันได้ทำการสำรวจด้วย นี้ถูก demo'd ที่ผสมและคุณจะพบการโพสต์ที่นี่

— degnome
แหล่งที่มา
ขอบคุณสำหรับลิงค์ (1 RainDrop) - การสนทนาเกี่ยวกับความปลอดภัยที่น่าสนใจมากเพราะเกี่ยวข้องกับ SOAP v REST
— นาธาน
15

ขอบคุณสำหรับคำแนะนำที่ยอดเยี่ยม เราลงเอยด้วยการใช้ส่วนหัว HTTP แบบกำหนดเองเพื่อส่งโทเค็นข้อมูลเฉพาะตัวจากลูกค้าไปยังบริการเพื่อเตรียมการรวม RESTful API ของเราเข้ากับ Zermatt Identity Framework จาก Microsoft ผมได้อธิบายปัญหาที่เกิดขึ้นที่นี่และแก้ปัญหาของเราที่นี่ ฉันยังใช้คำแนะนำของtweaktและซื้อRESTful Web Services - หนังสือที่ดีมากถ้าคุณกำลังสร้าง RESTful API ไม่ว่าชนิดใด

— นาธาน
แหล่งที่มา
1
วิธีการนี้ฟังดูแปลกสำหรับฉัน อะไรทำให้ผู้โจมตีไม่สามารถใช้โทเค็นตัวตนเพื่อหลอกลวงลูกค้า HTTPS ไม่ปกป้อง URL หรือที่ส่วนหัวเป็นครั้งสุดท้ายที่ฉันจะตรวจสอบ ...
— Gili
2
อืม ... ไม่แน่ใจว่าคุณพูดถูก ฉันเชื่อว่ายกเว้นส่วนหัวบางส่วนที่จำเป็นต้องทำความเข้าใจกับการเข้ารหัสชนิดใดส่วนหัวอื่น ๆ ทั้งหมดจะถูกเข้ารหัส
— นาธาน
51
ว่าเป็นสิ่งที่ผิด. HTTPS ปกป้องทุกอย่าง มันไป: จับมือ TCP ... จับมือ TLS ... <ENCRYPTED> รับ / foo 200 ตกลง ... teardown </ENCRYPTED>
— Mark Renouf
1
โปรดทราบว่าคุณสามารถส่งโทเค็นเป็นคุกกี้ (แทนส่วนหัวที่กำหนดเอง) สิ่งนี้ทำงานได้ดีในเบราว์เซอร์เนื่องจากใช้ส่วนหัว HTTP ที่มีพฤติกรรมมาตรฐานในชุดเครื่องมือและแอปพลิเคชันส่วนใหญ่ ในด้านบริการคุกกี้ไม่จำเป็นต้องเกี่ยวข้องกับเซสชันคุณสามารถใช้เพื่อสื่อสารโทเค็นใด ๆ ที่คุณต้องการ
— Bruce Alderson
11
เครื่อง Wayback เป็นสิ่งที่สวยงาม: คำอธิบายปัญหาและการแก้ปัญหา
— cjc343
14

OWASP (Open Web Application Security Project) มีชีตชีตบางส่วนที่ครอบคลุมเกี่ยวกับการพัฒนา Web Application ทุกด้าน โครงการนี้เป็นแหล่งข้อมูลที่มีค่าและเชื่อถือได้มาก เกี่ยวกับบริการ REST คุณสามารถตรวจสอบได้ที่: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

— WelsonJR
แหล่งที่มา
7

ฉันจะแนะนำ OAuth 2/3 คุณสามารถค้นหาข้อมูลเพิ่มเติมได้ที่http://oauth.net/2/

— Abhijit Gaikwad
แหล่งที่มา
8
สนใจที่จะอธิบายอย่างละเอียดว่าทำไมคุณถึงแนะนำรุ่นที่ 2 เมื่อมันยังไม่สมบูรณ์? IMHO เวอร์ชัน 1.0a ยังคงเป็นโซลูชั่นที่มั่นคงสำหรับแอพส่วนใหญ่
— Butifarra
6

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

— Parisa Kachoui
แหล่งที่มา
6

ความจริงที่ว่าโลก SOAP นั้นค่อนข้างได้รับการคุ้มครองด้วยมาตรฐานความปลอดภัยไม่ได้หมายความว่ามันปลอดภัยโดยค่าเริ่มต้น ในตอนแรกมาตรฐานนั้นซับซ้อนมาก ความซับซ้อนไม่ได้เป็นเพื่อนที่ดีในเรื่องความปลอดภัยและความเสี่ยงในการติดตั้งเช่นการโจมตีโดยใช้ลายเซ็น XMLนั้นมีเฉพาะที่นี่

สำหรับสภาพแวดล้อม. NET ฉันไม่ได้ช่วยอะไรมากนัก แต่“ การสร้างบริการบนเว็บด้วย Java” (อิฐที่มีผู้เขียนประมาณ 10 คน) ได้ช่วยฉันมากในการทำความเข้าใจสถาปัตยกรรมความปลอดภัย WS- * และโดยเฉพาะอย่างยิ่งปัญหา

— kravietz
แหล่งที่มา
4

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

— Robert Morschel
แหล่งที่มา
4

ฉันต้องการเพิ่ม (สอดคล้องกับ stinkeymatt) ทางออกที่ง่ายที่สุดคือการเพิ่มใบรับรอง SSL ในเว็บไซต์ของคุณ ตรวจสอบให้แน่ใจว่า URL ของคุณคือ HTTPS: // ที่จะครอบคลุมการรักษาความปลอดภัยการขนส่งของคุณ (ปังสำหรับเจ้าชู้) ด้วย URL ของ RESTful แนวคิดก็คือทำให้ง่าย (ไม่เหมือน WS * security / SAML) คุณสามารถใช้การเชื่อมต่อ oAuth2 / openIDหรือแม้แต่ Basic Auth (ในกรณีง่าย ๆ ) แต่คุณจะต้องใช้ SSL / HTTPS โปรดตรวจสอบความปลอดภัย ASP.NET Web API 2 ที่นี่: http://www.asp.net/web-api/overview/security (บทความและวิดีโอ)

— มานิชเชน
แหล่งที่มา
3

เมื่อ @Nathan จบลงด้วยการที่เป็นส่วนหัว HTTP แบบง่ายและบางคนก็บอกว่า OAuth2 และใบรับรอง SSL ฝั่งไคลเอ็นต์ สิ่งสำคัญของมันคือ ... REST API ของคุณไม่ควรจัดการเรื่องความปลอดภัยเพราะมันควรจะอยู่นอกขอบเขตของ API

ควรวางเลเยอร์ความปลอดภัยไว้ด้านบนไม่ว่าจะเป็น HTTP Header หลังเว็บพร็อกซี (วิธีการทั่วไปเช่น SiteMinder, Zermatt หรือแม้แต่ Apache HTTPd) หรือซับซ้อนเป็น OAuth 2

สิ่งสำคัญคือคำขอควรทำงานได้โดยไม่ต้องมีการโต้ตอบกับผู้ใช้ปลายทาง สิ่งที่จำเป็นต้องมีเพื่อให้แน่ใจว่าการเชื่อมต่อกับ REST API นั้นได้รับการรับรองความถูกต้องแล้ว ใน Java EE เรามีแนวคิดเกี่ยวกับสิ่งuserPrincipalที่สามารถหาได้ในHttpServletRequestที่สามารถได้รับในนอกจากนี้ยังได้รับการจัดการในตัวบอกเกี่ยวกับการปรับใช้ซึ่งรูปแบบ URL สามารถปลอดภัยได้ดังนั้นโค้ด REST API ไม่จำเป็นต้องตรวจสอบอีกต่อไป

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

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

— Archimedes Trajano
แหล่งที่มา
3

สำหรับ Web Application Security คุณควรดูที่ OWASP ( https://www.owasp.org/index.php/Main_Page ) ซึ่งให้ cheatsheets สำหรับการโจมตีด้านความปลอดภัยต่างๆ คุณสามารถรวมมาตรการต่าง ๆ ได้มากที่สุดเพื่อรักษาความปลอดภัยแอปพลิเคชันของคุณ เกี่ยวกับความปลอดภัยของ API (การอนุญาต, การพิสูจน์ตัวตน, การจัดการข้อมูลผู้ใช้) มีหลายวิธีตามที่กล่าวไว้แล้ว (พื้นฐาน, Digest และ OAuth) มีรูลูปใน OAuth1.0 ดังนั้นคุณสามารถใช้ OAuth1.0a (OAuth2.0 ไม่ได้รับการยอมรับอย่างกว้างขวางเนื่องจากข้อกังวลเกี่ยวกับข้อกำหนด)

— java_geek
แหล่งที่มา
2

ไม่นานมานี้ แต่คำถามยังคงมีความเกี่ยวข้องแม้ว่าคำตอบอาจเปลี่ยนไปเล็กน้อย

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

Express-gateway.ioเป็นรุ่นล่าสุดและเป็นเกตเวย์ API

— Matt Bannert
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.