เหตุใดเราจึงต้องการความปลอดภัยของบริการ REST หากเรามี HTTPS


13

ฉันอ้างถึงบทความที่ยอดเยี่ยมhttp://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ซึ่งพูดถึง amazon เช่นความปลอดภัยสำหรับบริการเว็บ อย่างไรก็ตามฉันถูกถามคำถามในทีมว่าทำไมเราถึงต้องการถ้าเราใช้ HTTPS อยู่แล้ว ฉันไม่สามารถตอบได้เพราะจริง ๆ แล้วดูเหมือนว่าฉันจะพูดถูก

มีสถานที่ให้บริการ REST ที่ HTTPS อาจไม่ทำงานหรือไม่ ชอบเว็บไซต์บุคคลที่สามหรือไม่

หากใครมีประสบการณ์ในการรักษาความปลอดภัยบริการทางเว็บผ่านทางเว็บสาธารณะกรุณาเล่าถึงประสบการณ์ของคุณ

ขอบคุณล่วงหน้า.

แก้ไข: เพื่อชี้แจงฉันไม่ได้พูดถึงการตรวจสอบผู้ใช้ แต่การตรวจสอบลูกค้าเพิ่มเติม การพิสูจน์ตัวตนผู้ใช้สามารถถือว่าเป็นข้อความธรรมดาผ่าน HTTPS + REST

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


3
เหมาะที่สุดสำหรับsecurity.stackexchange.com ?
jweyrich

1
บางทีคุณอาจจะถูก แต่คำถามของฉันคือหมอที่เกี่ยวข้อง

คำตอบ:


13

ทำไมเราต้องให้ Gmail - หรือเว็บไซต์อื่น ๆ ที่มีบัญชีผู้ใช้ - ชื่อผู้ใช้และรหัสผ่านของเราหากมันใช้ HTTPS อยู่แล้ว? คำตอบนั้นเหมือนกับคำตอบสำหรับคำถามของคุณ

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

ความน่าเชื่อถือที่มีอยู่ใน HTTPS ขึ้นอยู่กับผู้ออกใบรับรองหลักที่ติดตั้งล่วงหน้าในซอฟต์แวร์เบราว์เซอร์ (ซึ่งเทียบเท่ากับการพูดว่า "ฉันเชื่อถือผู้ออกใบรับรอง (เช่น VeriSign / Microsoft / ฯลฯ ) เพื่อบอกฉันว่าใครควรไว้ใจ"

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


ขอโทษคุณเข้าใจผิดหรือฉันไม่ชัดเจน เอกสาร Amazon APi ระบุว่าเราควรใช้ HTTPS แต่ถ้าเราไม่แล้วเราจะลงชื่อในคำขอ รหัสผ่านชื่อผู้ใช้ไม่เกี่ยวข้องในตอนนี้

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

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

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

1
+1 มันยอดเยี่ยมที่คุณพูดถึงใบรับรองลูกค้า แต่ไม่จำเป็นว่าเซิร์ฟเวอร์จะออกใบรับรอง พวกเขาเพียงแค่ต้องลงนามโดย CA ที่เชื่อถือได้; โดยทั่วไปเหมือนกับเซิร์ฟเวอร์ certs ทำงาน
JimmyJames

3

HTTPS ดีมากในการป้องกันการดักฟังและการโจมตี "คนที่อยู่ตรงกลาง" มันเข้ารหัสการรับส่งข้อมูลทั้งหมดสำหรับเซสชัน

แต่เนื่องจากคนส่วนใหญ่ใช้ใบรับรองเริ่มต้นซึ่งมาพร้อมกับเบราว์เซอร์และไม่รู้ว่าจะสร้างใบรับรองส่วนตัวของตนเองหรือกำหนดค่าเบราว์เซอร์ให้ใช้งานได้อย่างไร

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


ฉันคิดว่าคุณสนิทกับสิ่งที่ฉันขอมาก ดังนั้นคุณแนะนำว่าเราควรจะยังคงลงนามคำขอบนฝั่งไคลเอ็นต์แม้ว่าเราจะใช้ HTTPS?

2

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

โรเบิร์ต


0

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

อย่างไรก็ตามการรับรองความถูกต้องพื้นฐาน HTTP นั้นใช้ได้กับบริการสาธารณะส่วนใหญ่

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