بررسی وجود ۵ آسیب پذیری رایج برروی درگاه پرداخت هدف راورو
آنچه میخوانید، رایتاپ رامین فرجپور، برنامهنویس و محقّق امنیتی، از فرآیند بررسی وجود آسیبپذیریهای Input Validation (مقدار مبلغ از سمت سرور)، آسیب پذیری DoS (اختلال در اتصال به درگاه) ، آسیب پذیری Race Condition (مسابقه شرطی)، آسیب پذیری Double Spending (دو بار خرج کردن) ، آسیب پذیری IDOR (دسترسی منبع/منابع به شئ/اشیاء داخلی برنامه) بر روی هدف سامانهی راورو در پلتفرم باگ بانتی راورو است.
داخل پرانتز:
رامین گزارش مربوط به این رایتاپ را پیش از این در پلتفرم باگ بانتی راورو و برای میدان راورو ثبت کرده و آسیبپذیری نیز درحالحاضر بهطورکامل رفع شده است.
امروزه اکثر کسبوکارها به بستر آنلاین روی آوردهاند و خدمات و محصولات خود را در فضای اینترنت ارائه و عرضه میکنند. تمامی وبسایتها برای انجام تراکنشهای مالی مشتریان خود، نیاز به درگاه پرداخت آنلاین مشتریان دارند. ایجاد درگاه پرداخت با بهرهگیری از دانش برنامه نویسی بهسادگی امکانپذیر است. اما عدم آگاهی و آشنانبودن با نکات امنیتی در این قسمت مهم از سایت، معمولا آسیبها و هزینههای زیادی را برای کسب و کارها بهبار میآورد.
اجازه بدهید ابتدا بررسی کوتاهی از ساختار معمول قسمت درگاه پرداخت در سایتها داشته باشیم و جهت ایجاد زبان مشترک قبل از آغاز، چندین اصطلاح را با یکدیگر مرور کنیم:
در کسب وکار هایی که قصد ارتباط با درگاه بانکی دارند برنامه نویس ها جدولی برای پرداختها و تراکنشها طراحی میکنند.
PaymentId : شماره رکورد پرداخت است که توسط خود دیتابیس مقداردهی میشود
ReferenceNumber : شماره پیگیری فاکتور موجود
SaleReferenceId : شماره پرداخت فاکتور موجود
StatusPayment: وضعیت پرداخت
PaymentFinished: وضعیت نهایی پرداخت
Amount: مبلغ پرداخت شده
BankName: نام بانک سرویس دهنده
UserID: کد کاربر خریدار
BuyDatetime: تاریخ خرید
داخل پرانتز: بسته به نوع بانک متصل به درگاه پرداخت بانک ها ، امکان دارد نام این پارامترها متفاوت باشد.
برای اتصال به درگاه پرداخت، ابتدا تمام این پارامترها، به همراه مبلغ تعیینشده برای شارژ کیف پول، به درگاه پرداخت ارسال میشوند.
از هر چه بگذریم، سخت شکار خوشتر است. ؛) حالا بیایید عینک شکار را به چشممان بزنیم و به سراغ بررسی وجود آسیبپذیریهای مختلف در درگاه پرداخت هدف راورو برویم و به بررسی موارد امنیتیای که در درخواست به درگاه پرداخت از نگاه یک هانتر باید بررسی شود، برویم.
۱. بررسی وجود آسیب پذیری Input Validation (مقدار مبلغ از سمت سرور) در درگاه پرداخت راورو
در قدم اول آسیبپذیربودن درگاه پرداخت نسبت به ورودی را بررسی میکنیم؛ آیا درگاه پرداخت، در اعتبارسنجی ورودی بهخوبی عمل میکند؟ اگر عددی خارج از محدوده وارد شود، سیستم اجازهی ثبت و ارسال را میدهد؟ سرویسی که قصد خریدش را داریم، باید دقیقا همان مبلغی باشد که به سمت درگاه درخواست داده می شود. نباید مبلغ کمتر از چیزی که در سایت برای استفاده از سرویس تعریف شده است، پذیرفته شود.
معمولا بیشتر محدودیت در دریافت مبلغ وجود دارد. اگر این محدودیت در سمت کلاینت بررسی شود و در سمت سرور بررسی نشود این احتمال وجود دارد که با کمترین مبلغ سرویسی خریداری شود.
در این ویدئو سناریوی بررسی وجود آسیب پذیری Input Validation در درگاه پرداخت هدف راورو را مشاهده میکنید. که ظاهرا در سامانهی راورو بررسی در سمت سرور انجام میشود و به همین دلیل سامانه نسبت به آسیب پذیری Input Validation آسیب پذیر نیست.
۲. بررسی وجود آسیب پذیری DoS (اختلال در اتصال به درگاه) در درگاه پرداخت راورو
در قدم دوم آسیبپذیربودن درگاه پرداخت نسبت به آسیبپذیری DoS یا همان Denial of Service را بررسی میکنیم؛ آیا میشود در دسترسیپذیری درگاه برای کاربران مجازش، اختلال ایجاد کرد؟ آیا اختلالی در آیا اختلالی در ظرفیت خرید کالا، بلیت یا ... پیش میآید؟
وقتی درگاه پرداخت نسبت به آسیب پذیری DoS آسیب پذیر می باشد که در بعضی موارد هنگامیکه کاربر اقدام به خرید در سمت درگاه میکند، تب مرورگر خود را close میکند و بدون این که "دکمه انصراف" را بزند و مجددا درخواست پرداخت را بزند، امکان اتصال به درگاه پرداخت برای کاربر مقدور نمیشود.
تماشای ویدئو بررسی وجود آسیب پذیری DoS (اختلال در اتصال به درگاه) در درگاه پرداخت راورو در یوتیوب
تماشای ویدئو بررسی وجود آسیب پذیری DoS (اختلال در اتصال به درگاه) در درگاه پرداخت راورو درآپارات
در مواقعی که صفحهی درگاه پرداخت بانک بارگذاری شده، باید اطلاعات شماره کارتها را وارد کنیم. بعد از اتمام خرید زمانی که در خواست به سمت کسب و کار برمیگردد (callback)، مواردی امنیتی که رخ می دهد به شرح زیر هستند:
۳. بررسی وجود آسیب پذیری Race Condition (مسابقه شرطی) در درگاه پرداخت راورو
حالا بهسراغ بررسی آسیب پذیری بعدی میرویم و آسیبپذیربودن درگاه پرداخت نسبت به آسیبپذیری Race Condition را بررسی میکنیم؛
اگر تلاش کنیم که کارها خارج از نوبت و توالی برنامهریزیشده انجام شوند، چه اتفاقی میافتد؟
آنچه که در بررسی آسیب پذیری Race Condition باید به آن توجه کنیم این است که وقتی ما پرداخت موفقیتآمیزی انجام میدهیم، اطلاعات بازگشتی که از بانک بر گردانده شده است باید در جدول (بالا) ثبت شوند. به همین منظور هنگام ثبت در جدول، سناریو آسیب پذیری Race Condition را در این API بررسی می کنیم که باعث می شود که چندین ثبت با یک پرداخت در جدول صورت گیرد و باعث افزایش مبلغ کیف پول ما میشود.
توجه :
در سیستم هایی که سیستم های توزیع شده (Distributed Systems) این یک چالش برای کسب و کار ها می باشد که این مورد بر حسب نیازمندی کسب و کار باید به درست پیاده سازی شود تا جلوی این حمله گرفته شود.
تماشای ویدئو بررسی وجود آسیب پذیری Race Condition (مسابقه شرطی) در درگاه پرداخت راورو در یوتیوب
تماشای ویدئو بررسی وجود آسیب پذیری Race Condition (مسابقه شرطی) در درگاه پرداخت راورو در آپارات
در این ویدئو سناریوی بررسی وجود آسیب پذیری Input Validation در درگاه پرداخت هدف راورو را میبینید. که سامانه نسبت به آن آسیب پذیر نیست.
۴. بررسی وجود آسیب پذیری Double Spending (دوباره خرج کردن) در درگاه پرداخت راورو
در قدم چهارم آسیبپذیربودن درگاه پرداخت نسبت به آسیبپذیری Double Spending را بررسی میکنیم؛ آیا حواس درگاه به این هست که شاید برای پرداخت چندین بار درخواست ارسال شود؟
در اینجا برای بررسی وجود آسیب پذیری Double Spending، باید حواسمان به این باشد که همان زمانی که درخواست موفقیتآمیز از سمت درگاه بانک برگشته است، باید به همان OrderID که داریم چندین باز درخواست ارسال کنیم. اگر چندین بار در جدول (بالا) رکورد ثبت شود، می توانیم بگوییم نشان از وجود آسیب پذیری Double Spending است.
تماشای ویدئو بررسی وجود آسیب پذیری Double Spending (دوبار خرج کردن) در درگاه پرداخت راورو در یوتیوب
تماشای ویدئو بررسی وجود آسیب پذیری Double Spending (دوبار خرج کردن) در درگاه پرداخت راورو در آپارات
همانطور که در سناریوی موجود در ویدئو مشاهده میکنید، متوجه شدم که بررسی OrderID در سمت سرور انجام شده است (فاکتور) و اینجا خبری از آسیب پذیری Double Spending نیست. تاحالا که درگاه پرداخت راورو در بررسی ۴ آسیب پذیری، آسیب پذیر نبوده است!
۵. بررسی وجود آسیب پذیری IDOR (دسترسی منبع/منابع به شئ/اشیاء داخلی برنامه) در درگاه پرداخت راورو
اگر شما بودید حالا به سراغ بررسی کدام آسیب پذیری میرفتید؟ به نظر من، آسیب پذیری بعدی که شکارچیان آسیبپذیری باید در این قسمت به آن توجه داشته باشند، آسیب پذیری IDOR است. بیایید آسیبپذیربودن درگاه پرداخت نسبت به آسیبپذیری IDOR یا همان Insecure Direct Object References را بررسی کنیم. اگر بعد از یک پرداخت موفق، با Order IDها ( ممکن می باشد در دیگر درگاه ResNum باشد ) بازی کنیم و جای هم قرارشان دهیم، ممکن است آسیبپذیریای کشف شود؟ ؛)
آسیب پذیری IDOR بسته به نوع کسب و کارها سناریوی حمله متفاوت و بهخصوصی دارد، ما اینجا ۳ سناریو را بررسی میکنیم.
۵.۱. اولین سناریویی که به ذهن من رسید این بود که ابتدا باید یک پرداخت موفقیتآمیز انجام دهم، پس از آن از سمت درگاه یک سری دادههای موفقیتآمیز برمیگردند و دوباره باید orderid برای دیگر تراکنش که نیاز به پرداخت دارد به جای orderid که قبلا با آن پرداخت موفق داشتیم، قرار دهیم.
BOOOOOOM
درگاه پرداخت هدف راورو، نسبت به آسیب پذیری IDOR آسیب پذیر بود.
داخل پرانتز: در حال حاضر این آسیب پذیری در پلتفرم باگ بانتی راورو برطرف شده است.
۵.۲. سناریوی دیگری که بهکمک آن میتوان وجود آسیب پذیری IDOR را در سایر سایتها بررسی کرد، این گونه است: در بعضی از کسبوکارها مشاهده می شود برای سرویس های خود بستههای تعرفه ۱ ماهه، ۲ ماهه و یا ۱ ساله قرار میدهند. هر کدام از این تعرفهها دارای پارامترهای بهخصوصی هستند. بیایید با شناسایی و تغییر این پارامترها، تلاش کنیم تعرفه ۱ ساله را با پرداخت مبلغ تعرفهی ۱ ماه انجام دهیم.
داخل پرانتز: این مورد باتوجه به طراحی سایت راورو به منظور شارژ کیف بود در آن قابلاجرا و بررسی نبود.
۵.۳. سناریوی دیگری که بهکمک آن میتوان وجود آسیب پذیری IDOR را در سایر سایتها بررسی کرد، این گونه است: وقتی بعد از پرداختی که از سمت درگاه انجام میشود، یک سری پارامتر در سمت کسبوکارها ایجاد میشوند (مانند؛ billid و شماره فاکتور یا ای دی کاربر )، اگر در اینجا این پارامترها به درستی احراز هویت نشوند، امکان دسترسی به شماره فاکتورها یا تراکنشهای دیگر کاربران و حتی نشت داده های کاربر مقدور است.
توصیه امنیتی:
من در این رایتاپ به بررسی وجود ۵ آسیب پذیری رایج در درگاههای پرداخت، در درگاه پرداخت هدف راورو پرداختم؛ آسیبپذیری Input Validation ( مقدار مبلغ از سمت سرور)، آسیب پذیری DoS ( اختلال در اتصال به درگاه) ، آسیب پذیری Race Condition (مسابقه شرطی)، آسیب پذیری Double Spending (دوبار خرج کردن) ، آسیب پذیری IDOR (دسترسی منبع/منابع به شئ/اشیاء داخلی برنامه).
شاید بتوان نتیجه و توصیهی نهایی را اینگونه بیان کرد:
اگر در پیادهسازی اتصال به درگاه پرداخت، درخواست (request) و تاییدیه (verify) از پرداخت تراکنش انجام نشود، باعث بروز مشکلاتی می شود که نمونههایی از آنها را در این مقاله ذکر کردم.
سایر رایتاپهای منتشرشده از رامین فرجپور:
چگونه توانستم در هدف راورو، آسیبپذیری IDOR را کشف کنم؟
چگونه توانستم آسیبپذیری PII را در هدفهای مربوط به سه میدان مختلف کشف کنم؟
چگونه توانستم با تغییر آدرس action در فرم، Form Action Hijacking انجام بدم؟
حملهی HTTP Flooding در تایید ایمیل برای سوءاستفاده بدون دخالت کاربر
سایر رایتاپهای منتشرشده:
چگونه توانستم آسیبپذیری CRLF Injection را بر روی PayPal کشف کنم؟
بلاگپستهای مرتبط: