Oauth 2 - pemesanan params dan integritas tanda tangan

Saya punya dua pertanyaan:

Q1: Mengapa OAuth2 mengharuskan param diurutkan dan dikodekan (untuk 2 leg)?

Yang perlu dikhawatirkan hanyalah tanda tangan yang cocok di kedua akhir untuk data yang diberikan (string kueri).

Kita cukup memeriksa tanda tangan yang dihasilkan menggunakan string kueri.(mis. ?a=1&b=2). Karena tanda tangan dihasilkan berdasarkan kunci rahasia yang hanya diketahui oleh klien dan penyedia, kami hanya dapat mempertimbangkan string kueri tanpa pemesanan/pengkodean apa pun.

Lalu apa keuntungannya melakukan pemesanan/encoding lalu membuat tanda tangan?

Q2: Bagaimana tanda tangan ini dapat menyelamatkan saya dari serangan man-in-the middle?

Jika saya harus membuat permintaan seperti ini ke server saya dari klien:

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

Sekarang token XYZ akan selalu sama, sehingga peretas dapat terus mengirimkan permintaan yang sama untuk meningkatkan points. Karena token yang dihasilkan dari appId yang diberikan sama, server akan mengizinkannya. Bagaimana kasus ini ditangani?


oauth-2.0
person Learner    schedule 05.03.2012    source sumber
comment
Mengapa ini diberi tag oauth-2 dan Anda sedang mendiskusikan HMAC?   -  person Mukus    schedule 24.03.2017

Jawaban (1)


arrow_upward
5
arrow_downward

Q1: Mengurutkan parameter kueri memberikan kewarasan pada HMAC.

Katakanlah Anda memiliki dua parameter: 'pointsToAdd' dan 'appId'. Menggunakan string kueri pointsToAdd=X&appID=y membuat HMAC berbeda dengan appID=y&pointsToAdd=X. Karena Anda dan server perlu membuat HMAC yang sama untuk memverifikasi permintaan yang memiliki parmeter kueri tidak berurutan yang gagal.

Q2: Ini menyelamatkan Anda dari serangan karena hanya Anda dan server yang tahu cara menandatangani permintaan Anda.

Anda memiliki kunci rahasia, dan hanya Anda dan server yang mengetahuinya. Kunci ini menandatangani permintaan. Jika HMAC tidak cocok dengan kunci rahasia ini, permintaan akan gagal.

Karena semua parameter telah digunakan untuk membuat HMAC, permintaan tersebut aman dari serangan MITM — peretas tidak dapat mengubah, menambah, atau menghapus parameter kueri apa pun, atau server akan menghasilkan HMAC yang berbeda ketika mencoba memberi otorisasi dan permintaan gagal.

person tonyhb    schedule 07.03.2012
comment
Bagaimana dengan serangan ulangan? Kecuali stempel waktu digunakan sebagai komponen untuk menghasilkan token, server akan memutar ulang token tersebut. - person Mukus; 24.03.2017