ความปลอดภัยของโครงร่างการพิสูจน์ตัวตน REST

228

พื้นหลัง:

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

คำถาม SO เหล่านี้มีประโยชน์อย่างยิ่งที่จะให้ฉันเริ่มต้น:

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

ในการรับคำถาม:

ทั้ง S3 และ OAuth พึ่งพาการลงชื่อ URL คำขอพร้อมกับส่วนหัวที่เลือกไม่กี่รายการ ทั้งคู่ไม่ได้ลงนามในเนื้อความคำขอสำหรับคำขอ POST หรือ PUT นี่ไม่ใช่ความเสี่ยงที่จะเกิดการโจมตีจากคนกลางซึ่งจะคอยดูแล url และส่วนหัวและแทนที่เนื้อหาที่ร้องขอด้วยข้อมูลใด ๆ ที่ผู้โจมตีต้องการ

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

— dF
แหล่งที่มา

6

Amazon S3 สามารถรวม Content-MD5 เป็นส่วนหนึ่งของสตริงส่วนหัวเพื่อป้องกันการโจมตี MITM ที่คุณอธิบาย

— laz

8

MD5 เป็นฟังก์ชันแฮชอ่อนแอมากและการใช้งานของมันได้รับกำลังใจเป็นเวลาหลายปีขณะนี้: en.wikipedia.org/wiki/MD5 ใช้ SHA2 ทุกวันนี้ MD5 เป็นลิปสติกบนหมูที่มีวิกฤตความเป็นตัวตน

— Henrik

6

Startcomมีใบรับรอง SSL ฟรีที่ไม่ทิ้งคำเตือนใบรับรองในเบราว์เซอร์หลัก

— Plato

5

@SeanKAnderson (คุยโว: ฉันคิดว่ามันไร้สาระที่ผู้คนพูดถึง 99.99999% s เมื่ออินเทอร์เน็ตอยู่ภายใต้การถูกโจมตีโดยหน่วยงานสายลับซึ่งมีการโจมตีอัตโนมัติจำนวนมากในปี 2008 - มันเป็นวิธีแปลก ๆ ในการจัดการกับปัญหาที่แท้จริง - "Naaah จะไม่เป็นปัญหาสำหรับคุณยายของฉันที่จะไม่สามารถแฮ็คมันได้"

— Henrik

2

@Plato ฉันขอแนะนำ LetsEncrypt วันนี้เพื่อรับใบรับรอง SSL ฟรี

— shuttle87

168

คำตอบก่อนหน้านี้กล่าวถึง SSL ในบริบทของการถ่ายโอนข้อมูลเท่านั้นและไม่ครอบคลุมการตรวจสอบ

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

หากคุณไม่ได้ใช้การตรวจสอบความถูกต้องไคลเอนต์ TLS คุณจะต้องใช้รูปแบบการตรวจสอบสิทธิ์แบบย่อย (เช่นรูปแบบที่กำหนดเองของ Amazon Web Service) หรือ OAuth 1.0a หรือแม้กระทั่งการรับรองความถูกต้องพื้นฐาน HTTP (แต่ผ่าน SSL เท่านั้น)

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

สำหรับผู้ที่สนใจฉันได้ขยายเป็นคำถามเกี่ยวกับHTTP แผนการตรวจสอบและวิธีการทำงาน

— Les Hazlewood
แหล่งที่มา

16

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

— Tim Gautier

1

คำตอบที่ดี. ฉันยังอยากจะแนะนำให้มีรูปลักษณ์ที่ทรัพยากรที่ดีเหล่านี้ .. owasp.org/index.php/Web_Service_Security_Cheat_Sheetและowasp.org/index.php/REST_Security_Cheat_Sheet (ร่าง)

— dodgy_coder

2

เพียงแค่จุดเล็กน้อย แต่การใช้ SSL ยังมีประโยชน์เพิ่มเติมในการป้องกันการดักฟังและการโจมตีกลาง

— dodgy_coder

@Les Hazlewood คุณช่วยอธิบายได้หรือไม่ว่า HTTP การตรวจสอบสิทธิ์พื้นฐานผ่าน Https สามารถช่วยในการกำหนดเซิร์ฟเวอร์ให้รู้ว่าใครกำลังพูดถึง

— ฤดูใบไม้ผลิ

@Les Hazlewood ที่นี่ฉันถามในคำถาม; tnx stackoverflow.com/questions/14043397/…

— ฤดูใบไม้ผลิ

60

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

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

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

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

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

(อัปเดตเพื่อครอบคลุมความหมายของการเชื่อมต่อ SSL เท่านั้น)

— mahemoff
แหล่งที่มา

3

คุณสามารถรับใบรับรอง SSL ของ GoDaddy ในราคา $ 30 ต่อปีฉันคิดว่า ฉันรู้สึกตกใจเมื่อเห็นว่า Verisign SSL certs นั้นราคาเท่าไหร่ ($ 600 ต่อปีหรือบางอย่างถ้าฉันจำได้ถูกต้อง?) แต่ตัวเลือก GoDaddy นั้นเป็นไปได้อย่างสมบูรณ์แบบ

— Brian Armstrong

19

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

— Pauld

5

Ryan: การเข้ารหัส SSL ในปัจจุบันใช้พลังงานประมวลผลค่อนข้างน้อยเมื่อเทียบกับสิ่งที่คุณใช้เพื่อสร้างการตอบสนองด้วยเฟรมเวิร์กแอพเช่น Django หรือ Rails เป็นต้น

— Cameron Walsh

4

certs จาก startcom นั้นฟรีและได้รับการยอมรับอย่างกว้างขวาง cacert.org เป็นทางเลือกแบบเปิดที่มีการยอมรับน้อย

— Dima Tisnek

17

นี่ไม่ได้ตอบคำถามซึ่งเกี่ยวกับการรับรองความถูกต้อง

— Sam Stainsby

8

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

— wowest
แหล่งที่มา

2

ใบรับรองที่ลงนามด้วยตนเองนั้นฟรี แต่ AFAIK คุณยังคงต้องการ IP แบบคงที่

— dF

8

@dF ไม่มีข้อกำหนดของการมี IP แบบคงที่ยกเว้นข้อกำหนดการออกใบอนุญาตบางรายการของการค้าที่ต้องชำระสำหรับใบรับรอง

— Chris Marisic

หากคุณมีการควบคุมร้านค้าใบรับรองที่ปลายทั้งสองด้าน (ไคลเอนต์ & เซิร์ฟเวอร์) นี่อาจเป็นตัวเลือกที่ทำงานได้ แต่ ... การจัดการใบรับรองและการจัดจำหน่ายอาจซับซ้อนกว่าในการผลิตมากกว่าในสภาพแวดล้อมการพัฒนา อย่าลืมเข้าใจความซับซ้อนของทางเลือกนี้ก่อนที่จะทำความเข้าใจ

— aled

5

หากคุณต้องการแฮชของเนื้อความเป็นหนึ่งในพารามิเตอร์ใน URL และ URL นั้นถูกเซ็นชื่อผ่านคีย์ส่วนตัวการโจมตีแบบ Man-in-the-middle จะสามารถแทนที่เนื้อหาด้วยเนื้อหาที่จะสร้าง แฮชเดียวกัน ทำได้ง่ายด้วยค่าแฮชของ MD5 อย่างน้อยตอนนี้และเมื่อ SHA-1 แตกหักคุณก็จะได้ภาพ

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

— ZaDDaZ
แหล่งที่มา

9

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

— Tim Gautier

3

ในความเป็นจริงที่เป็นต้นฉบับ S3 รับรองความถูกต้องไม่อนุญาตให้มีเนื้อหาที่จะลงนามแม้จะมีลายเซ็น MD5 อ่อนแอ คุณสามารถบังคับใช้ทางเลือกในการรวมส่วนหัวของ Content-MD5 ใน HMAC (สตริงที่จะเซ็นชื่อ)

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

โครงร่างการพิสูจน์ตัวตน v4 ใหม่ของพวกเขามีความปลอดภัยมากขึ้น

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

— djsadinoff
แหล่งที่มา

1

จำไว้ว่าคำแนะนำของคุณทำให้ลูกค้าสื่อสารกับเซิร์ฟเวอร์ได้ยาก พวกเขาจำเป็นต้องเข้าใจโซลูชันที่เป็นนวัตกรรมของคุณและเข้ารหัสข้อมูลตามลำดับโมเดลนี้ไม่ดีสำหรับ API สาธารณะ (เว้นแต่คุณเป็น amazon \ yahoo \ google .. )

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

การเข้ารหัส XML (มาตรฐาน W3C)

ความปลอดภัยของ XML

— LiorH
แหล่งที่มา