وقتی دربارهی امنیت بانک و فین‌تک صحبت میشود، تصویر ذهنی معمولاً شبکه‌ی داخلی و مرکز داده است. اما آنچه هر مهاجم ناشناسی در اینترنت به آن دسترسی دارد چیز دیگری است: پورتال بانکداری آنلاین، اپلیکیشن موبایل و APIهایی که پشت آن قرار دارند، و درگاه پرداخت. همهی این‌ها برنامهی وب هستند و با همان دسته‌بندی آسیب‌پذیری‌های برنامهی وب شکسته میشوند — با این تفاوت که در حوزه‌ی مالی، نقص‌های مجوزدهی و منطق کسبوکار مستقیماً به پول تبدیل میشوند.
در یک نگاه
- درگاه بانکداری آنلاین و API پرداخت، برنامهی وب‌اند و همان کنترلهای برنامهی وب را لازم دارند.
- غالب یافته‌های پرخطر مالی: مجوزدهی و منطق کسبوکار — نه رمزنگاری شکسته.
- PCI DSS در بند ۱۱٫۴ تست نفوذ داخلی و خارجی را دستکم هر ۱۲ ماه و پس از هر تغییر مهم الزام میکند، و آزمون مجدد پس از رفع اجباری است.
- شرایط رقابتی در جریان‌های مالی، آسیب‌پذیری واقعی و قابل بهرهبرداری از راه دور است.
سطح حملهی واقعی یک سازمان مالی
فهرست چیزهایی که از اینترنت در دسترس‌اند و همگی برنامهی وب‌اند:
- پورتال بانکداری آنلاین و پنل کاربری سرویس‌های مالی؛
- APIهایی که اپلیکیشن موبایل از آن‌ها استفاده میکند — معمولاً همان APIهایی که کمترین آزمون را دیده‌اند، چون «کاربر مستقیماً به آن‌ها دسترسی ندارد»؛
- درگاه پرداخت و مسیرهای بازگشت تراکنش (callback)؛
- پنل‌های مدیریتی و ابزارهای داخلی که به‌اشتباه در معرض اینترنت قرار گرفته‌اند؛
- سرویس‌های شریک و مسیرهای یکپارچه‌سازی با ارائهدهندگان بیرونی.
فرض غلط رایج دربارهی مورد دوم است: API اپلیکیشن موبایل دقیقاً به همان اندازهی وبسایت در دسترس است. کافی است کسی ترافیک اپلیکیشن را با یک پروکسی ببیند تا همهی نقاط انتهایی، پارامترها و ساختار پاسخ در اختیارش باشد. آزمون آن هم آزمون برنامهی وب است، نه چیز دیگری.
نقص‌های مجوزدهی و منطق کسبوکار
در OWASP Top 10:2025، دسته‌ی A01:2025 با عنوان کنترل دسترسی شکسته در رتبه‌ی نخست است و OWASP اعلام کرده در ۱۰۰٪ برنامه‌های آزموده‌شده شکلی از آن دیده شده. در سرویس‌های مالی این دسته گران‌ترین یافته‌هاست:
- IDOR روی شناسه‌ی حساب یا تراکنش. تغییر یک شناسه در درخواست و دیدن صورت‌حساب کاربر دیگر. ضعف متناظر آن در فهرست ضعف‌های MITRE، CWE-639 است: دور زدن مجوزدهی از طریق کلید تحت کنترل کاربر.
- ارتقای سطح دسترسی. کاربر عادی که به عملیات نقش پشتیبانی یا اپراتور دسترسی پیدا میکند، معمولاً چون کنترل فقط در رابط کاربری پنهان شده بود.
- دستکاری پارامتر مبلغ یا واحد پول. اگر مبلغ نهایی از سمت کاربر می‌آید و در سرور دوباره محاسبه نمی‌شود، مسئله حل‌نشده است.
- شرایط رقابتی در جریان‌های مالی. ارسال هم‌زمان چند درخواست برداشت یا اعمال کد تخفیف پیش از بهروزرسانی موجودی.
«شرایط رقابتی روی اینترنت عملی نیست، چون تأخیر شبکه اجازه نمی‌دهد.» این ادعا دیگر درست نیست. حملهی تکبستهای مبتنی بر HTTP/2 اثر نوسان شبکه را عملاً حذف میکند؛ در پژوهش منتشرشده‌ی PortSwigger، ۳۰ درخواست از ملبورن به دوبلین در پنجره‌ای کمتر از یک میلی‌ثانیه به سرور رسیده‌اند. ابزار این کار هم در دسترس عموم است. در جریان‌های مالی، این یعنی هر عملیاتی که «فقط یک بار» باید انجام شود، باید در سطح پایگاهداده تضمین شود — قفل درونبرنامهای در معماری چنداینستنسی کار نمیکند.
PCI DSS و الزام تست نفوذ
اگر داده‌ی کارت پرداخت پردازش، ذخیره یا منتقل میشود، PCI DSS مرجع مستقیم است. نسخه‌ی فعال، v4.0.1 است که در ۱۱ ژوئن ۲۰۲۴ منتشر شد؛ نسخه‌ی v4.0 در ۳۱ دسامبر ۲۰۲۴ بازنشسته شد و الزامات آینده‌دار v4.x از ۳۱ مارس ۲۰۲۵ اجباری شده‌اند.
| بند | الزام |
|---|---|
| ۱۱٫۴٫۱ | متدولوژی تست نفوذ مکتوب و پیاده‌شده؛ پوشش کل محیط داده‌ی کارت، آزمون از داخل و خارج شبکه، آزمون لایه‌ی برنامه و لایه‌ی شبکه، و نگه‌داری نتایج و شواهد رفع دستکم ۱۲ ماه |
| ۱۱٫۴٫۲ | تست نفوذ داخلی دستکم هر ۱۲ ماه و پس از هر ارتقا یا تغییر مهم زیرساخت یا برنامه، توسط فرد واجد صلاحیت و مستقل از سازمان |
| ۱۱٫۴٫۳ | همان شرایط برای تست نفوذ خارجی |
| ۱۱٫۴٫۴ | رفع آسیب‌پذیری‌های قابل بهرهبرداری و تکرار آزمون برای راستیآزمایی اصلاحات |
| ۱۱٫۴٫۵ | آزمون کنترلهای جداسازی دستکم هر ۱۲ ماه و پس از هر تغییر در آن کنترل‌ها |
| ۱۱٫۴٫۶ | برای ارائهدهندگان خدمت: همان آزمون جداسازی، دستکم هر شش ماه |
دو نکته‌ی عملی: نخست، بند ۱۱٫۴٫۴ آزمون مجدد را الزامی میکند — پس تعهد آزمون مجدد باید از ابتدا در قرارداد و در برآورد هزینه لحاظ شود. دوم، «تغییر مهم» را باید خودتان تعریف کنید؛ در عمل، انتشار یک قابلیت مالی جدید مصداق روشن آن است.
برای متن دقیق الزامات، مرجع رسمی سند PCI SSC است و ترجمه‌ی این جدول جایگزین آن نیست.
در یک ارزیابی مالی چه چیزی آزموده میشود؟
فراتر از چک‌لیست عمومی، این موارد در سرویس‌های مالی وزن ویژه دارند:
- ماتریس مجوزدهی کامل. هر عملیات، با هر نقش، روی داده‌ی هر کاربر دیگر. این پرزحمت‌ترین و پربازده‌ترین بخش کار است.
- یکپارچگی جریان تراکنش. آیا می‌توان یک مرحله را پرش کرد، دوباره ارسال کرد، یا در میانه رها کرد؟ دسته‌ی
A10:2025دقیقاً همین را هدف گرفته: بهرهبرداری از بازگشت ناقص در تراکنش نیمه‌تمام. - محدودیت نرخ و ضدخودکارسازی روی ورود، بازیابی گذرواژه، تأیید کد یک‌بارمصرف و استعلام‌ها.
- مدیریت نشست: ابطال سمت سرور، انقضای واقعی، و رفتار خروج در محیط‌های ورود یکپارچه.
- مسیرهای بازگشت پرداخت. آیا وضعیت تراکنش فقط بر اساس پارامتر بازگشتی کاربر تعیین میشود یا با استعلام سمت سرور تأیید میشود؟
- ثبت رخداد و هشدار روی عملیات مالی حساس — الزام
A09:2025.
پوشش کامل و ساختارمند این موارد در چک‌لیست تست نفوذ آمده و برای سرویس‌های فروش آنلاین، امنیت فروشگاه اینترنتی همین منطق را با تمرکز بر سبد خرید و پرداخت ادامه می‌دهد.
نقطه‌ی شروع برای یک سازمان مالی
ترتیبی که بیشترین کاهش ریسک را می‌دهد:
- موجودی کامل سطح در معرض اینترنت، شامل APIهای اپلیکیشن موبایل و مسیرهای شریک.
- بازبینی متمرکز مجوزدهی در لایه‌ی دسترسی به داده، نه در کنترلرها به‌شکل پراکنده.
- تضمین اتمی‌بودن عملیات مالی در سطح پایگاهداده: تراکنش با سطح ایزولهسازی مناسب، قفل رکورد یا قید یکتایی.
- ارزیابی مستقل با تمرکز بر مجوزدهی و منطق — تست نفوذ وب.
- ثبت رخداد و هشدار روی مسیرهای مالی، به‌همراه تمرین تشخیص در جریان ارزیابی.
- آموزش تیم توسعه روی همین الگوها — دوره‌ی سازمانی توسعه‌ی امن.
در حوزه‌ی مالی، نتیجه‌ی یک ارزیابی خوب معمولاً غافلگیرکننده است: بیشترین یافته‌های پرخطر نه در رمزنگاری، بلکه در ساده‌ترین بررسی‌هایی است که انجام نشده‌اند.
پرسش‌های متداول
امنیت بانکداری آنلاین چه تفاوتی با امنیت سایتهای دیگر دارد؟
از نظر فنی، سطح حمله همان سطح حملهی برنامهی وب است. تفاوت در پیامد و در وزن دستههاست: نقص مجوزدهی و منطق کسبوکار مستقیماً به زیان مالی تبدیل میشود و الزامات نظارتی مانند PCI DSS هم اضافه میشوند.
PCI DSS هر چند وقت یکبار تست نفوذ میخواهد؟
بند ۱۱٫۴ تست نفوذ داخلی و خارجی را دستکم هر ۱۲ ماه و پس از هر ارتقا یا تغییر مهم زیرساخت یا برنامه الزام میکند. آزمون کنترلهای جداسازی هم سالانه است و برای ارائهدهندگان خدمت هر شش ماه. رفع یافتهها باید با تکرار آزمون راستیآزمایی شود.
آیا API اپلیکیشن موبایل هم باید تست نفوذ شود؟
بله و معمولاً اولویت بالایی دارد. API دقیقاً به همان اندازهی وبسایت از اینترنت در دسترس است و مشاهدهی ترافیک اپلیکیشن با یک پروکسی، همهی نقاط انتهایی و پارامترها را آشکار میکند. آزمون آن، آزمون برنامهی وب است.
رمزنگاری قوی جلوی این حملات را نمیگیرد؟
نه. رمزنگاری از داده در حال انتقال و سکون محافظت میکند، اما دربارهی اینکه آیا کاربر مجاز به دیدن یک رکورد هست یا نه چیزی نمیگوید. حملهای که با یک نشست معتبر و روی کانال رمزنگاریشده انجام میشود، از دید رمزنگاری کاملاً عادی است.
شرایط رقابتی در سیستمهای مالی واقعاً قابل بهرهبرداری است؟
بله. حملهی تکبستهای مبتنی بر HTTP/2 اثر نوسان شبکه را عملاً حذف کرده و ابزارش هم در دسترس عموم است. راهکار درست، تضمین در سطح پایگاهداده است — تراکنش با ایزولهسازی مناسب، قفل رکورد، بهروزرسانی شرطی اتمی یا قید یکتایی. قفل درونبرنامهای در معماری چنداینستنسی کار نمیکند.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حملهی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.