Oauth 2 - การเรียงลำดับพารามิเตอร์และความสมบูรณ์ของลายเซ็น

ฉันมีสองคำถาม:

คำถามที่ 1: เหตุใด OAuth2 จึงจำเป็นต้องสั่งและเข้ารหัสพารามิเตอร์ (สำหรับ 2 ทาง)

สิ่งที่ต้องกังวลคือลายเซ็นที่ตรงกันทั้งสองด้านของข้อมูลที่กำหนด (สตริงแบบสอบถาม)

เราสามารถตรวจสอบลายเซ็นที่สร้างขึ้นโดยใช้สตริงการสืบค้นได้ (เช่น ?a=1&b=2) เนื่องจากลายเซ็นถูกสร้างขึ้นตามคีย์ลับซึ่งเฉพาะไคลเอนต์และผู้ให้บริการเท่านั้นที่ทราบ เราจึงสามารถพิจารณาเฉพาะสตริงการสืบค้นโดยไม่ต้องเรียงลำดับ/เข้ารหัสใดๆ

แล้วการสั่ง/เข้ารหัสแล้วสร้างลายเซ็นมีข้อดีอย่างไร?

คำถามที่ 2: ลายเซ็นนี้จะช่วยฉันจากการโจมตีแบบแทรกกลางได้อย่างไร

หากฉันต้องส่งคำขอเช่นนี้ไปยังเซิร์ฟเวอร์ของฉันจากไคลเอนต์:

increaseUserPoints?userId=1&pointsToAdd=5&appId=x&token=XYZ

ตอนนี้โทเค็น XYZ จะยังคงเหมือนเดิมเสมอ ดังนั้นแฮกเกอร์จึงสามารถโพสต์คำขอเดียวกันต่อไปเพื่อเพิ่ม points เนื่องจากโทเค็นที่สร้างขึ้นจาก appId ที่กำหนดเหมือนกัน เซิร์ฟเวอร์จะอนุญาตสิ่งนี้ คดีนี้จัดการอย่างไร?


person Learner    schedule 05.03.2012    source แหล่งที่มา
comment
เหตุใดจึงติดแท็ก oauth-2 และคุณกำลังหารือเกี่ยวกับ HMAC   -  person Mukus    schedule 24.03.2017


คำตอบ (1)


คำถามที่ 1: การเรียงลำดับพารามิเตอร์การสืบค้นทำให้ HMAC มีประสิทธิภาพ

สมมติว่าคุณมีพารามิเตอร์ 2 ตัว: 'pointsToAdd' และ 'appId' การใช้สตริงการสืบค้น pointsToAdd=X&appID=y จะสร้าง HMAC อื่นเป็น appID=y&pointsToAdd=X เนื่องจากทั้งคุณและเซิร์ฟเวอร์จำเป็นต้องสร้าง HMAC เดียวกันเพื่อตรวจสอบคำขอที่มีพารามิเตอร์การสืบค้นที่ไม่ได้เรียงลำดับล้วนล้มเหลว

คำถามที่ 2: สิ่งนี้จะช่วยคุณจากการถูกโจมตีเนื่องจากมีเพียงคุณและเซิร์ฟเวอร์เท่านั้นที่ทราบวิธีการลงนามคำขอของคุณ

คุณมีรหัสลับและมีเพียงคุณและเซิร์ฟเวอร์เท่านั้นที่รู้ คีย์นี้จะลงนามในคำขอ หาก HMAC ไม่ตรงกันตามรหัสลับนี้ คำขอจะล้มเหลว

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

person tonyhb    schedule 07.03.2012
comment
แล้วการโจมตีซ้ำล่ะ? เว้นแต่ว่ามีการใช้การประทับเวลาเป็นส่วนประกอบในการสร้างโทเค็น เซิร์ฟเวอร์จะเล่นซ้ำ - person Mukus; 24.03.2017