با تجزیه و تحلیل کامل هر چهار ، این جواب خیلی طولانی می شود ، اما اجازه دهید طرح های AWS و AliPay را با هم مقایسه کنیم.

برای من این بسیار شبیه به طرح امضا شده JWT / JSON Web Signature (JWS) است. (ویکی پدیا ، مشخصات رسمی در RFC 7515). بنابراین تمام محتوای بدن JSON با امضا محافظت می شود. اما این تمام پیام نیست. پیام HTTP کامل شامل هدرها خواهد بود و چیزی شبیه است (من این را اختراع می کنم)

 POST / api / v3 / Payment / paycancel HTTP / 1.1
میزبان: alipay.com
نماینده کاربر: Mozilla / 5.0 (Windows NT 10.0؛ Win64؛ x64؛ rv: 74.0) Gecko / 20100101 Firefox / 74.0
تایید کنید: */*
پذیرش-زبان: en-US ، en؛ q = 0.5
رمزگذاری پذیرش: gzip ، deflate ، br
مجوز: f2a905cba5482c77c4468d5f62c3cafe35c8c76ff7effae2e15085bd1edb579af9729b487753cc2f95ae9099a005a4ef2c013c8531c0addb8771b527cf3508bb
نوع محتوا: برنامه / json
مراجعه کننده: https://www.google.com/
منبع: https://www.google.com
DNT: 1
اتصال: زنده نگه دارید
محتوا-طول: 787

request "درخواست": {"head": {"نسخه": "2.0.0" ، "function": "alipay.intl.acquiring.agociation.payCancel" ، "clientId": "211xxxxxxxxxxxxxxx044"، "reqTime": " 2001-07-04T12: 08: 56 + 05: 30 "،" reqMsgId ":" 1234567asdfasdf1123fda "،" rezerv ":" {} "}،" body ": {" merchantId ":" 218xxxxxxxxxxxxx023 "،" acquisitionId ": "2015xxxxxxxxxxxxxxxxxxxxx747"}}، "امضا": "c1hTR2RBNHRSNEIwd25GNk5yOFNocGZOTXRISVNXdXpMcGRLb05Xc2tJZ0Njc3BNVkZGemdrZXo0QnJtdFlYa01xWmgxdHl6LzhzTk5VM0YyVlR1MGZPeCtaUDRDbm1Wak51OGJjaXU0aFR0bnl0QTNZMUdaL3lYQVVEK21WWUdYZXlETzNmSHJxRGRJN2szeFYvUThGQ09kMGN1bFRzTjZSUk14TVpxK29xUjJ4K0VqT1hWb2ZwN0JaSndoUUU4VXM0QWw1NzNGUXo1RUhEdkNMeDM1bHEyaG9NaFhMQ1ZMVkRCSGNwQ2dvdHVZNG1nOTFNWGgvcXFjRkdZL2hRS2hHZFdBYlo5dGNwMlE1czJFU2gzN3JxeG5Pd1pycmVwSzhOQzZ2TUJQVWlTUHhRZWZwZXYybkcwSnpBSE9qUlBiQlhZdzFYQlM2UkJZS0FtdWZaWmlRPT0 ="}

اکنون ، با طرح امضای Alipay ، فقط بدنه JSON محافظت می شود ، نه هدرهای HTTP. آیا با متوقف کردن درخواست شما و تغییر سرآیند های HTTP ، یک مهاجم می تواند آسیب ببیند؟ شاید.

صفحه AWS که به آن پیوند دارید می گوید:

برای امضای یک درخواست ، ابتدا یک هش (هضم) درخواست را محاسبه می کنید. سپس از مقدار هش ، برخی اطلاعات دیگر از درخواست ، و کلید دسترسی پنهانی خود برای محاسبه هش دیگر معروف به امضا استفاده می کنید. سپس به یکی از روش های زیر امضا را به درخواست اضافه می کنید:

• با استفاده از هدر مجوز HTTP.
• افزودن یک مقدار رشته پرس و جو به درخواست. از آنجا که امضای بخشی از URL در این حالت است ، به این نوع URL به آدرس اینترنتی تعیین شده گفته می شود.

اگرچه آن صفحه جزئیات فنی کاملی را ارائه نمی دهد ، به نظر می رسد که آنها در تلاشند تا کل را امضا کنند. درخواست HTTP (از جمله هدرها) و نه فقط بدن JSON.

محاکمه شده است. بارها و بارها.

در سال 1999 RFC2660 پروتکل انتقال ایمنی HyperText (S-HTTP) را تعریف کرد ، که حامل پیام های HTTP درون ظروف رمزنگاری پیام رمزنگاری (CMS) است – همان ترفندی است که S / MIME برای رمزگذاری و امضای ایمیل استفاده می کند. به هر دلیلی ، این هرگز به این نتیجه نرسید.

اخیراً ، من چند تلاش در IETF دیده ام تا درخواست ها و پاسخ های HTTP را با استفاده از هدرها امضا كنیم ، مشابه آنچه در بالا AWS انجام می دهد:

TL؛ DR: امضای پیام های HTTP کاملاً واضح به نظر می رسد ، و این تنها در صورتی است که فقط به امضای بار پاسخگویی و درخواست های ارسال شده اهمیت دهید – آنچه را که Alipay انجام داده است انجام دهید و از JWS استفاده کنید. امضای کل پیام HTTP ، از جمله URL درخواستی و سایر عناوین فریبنده است و نهادهای استاندارد برای بیش از 20 سال تلاش کرده اند مکانیسم امضای HTTP را ارائه دهند که هم امن و هم انعطاف پذیر باشد.