توصیه‌های امنیتی پرداخت درون‌برنامه‌ای
دریافت فایل llm.txt — خلاصهٔ انگلیسی توصیه‌های امنیتی پرداخت درون‌برنامه‌ای.
برای جلوگیری از جعل خرید، دستکاری اطلاعات پرداخت و دسترسی غیرمجاز به محصولات درون‌برنامه‌ای، لازم است هنگام پیاده‌سازی سرویس پرداخت مایکت، اصول امنیتی را رعایت کنید.
در ادامه، مهم‌ترین توصیه‌های امنیتی برای توسعه و انتشار برنامه‌های دارای پرداخت درون‌برنامه‌ای ارائه شده است.
۱. اعتبارسنجی خرید را در سرور انجام دهید
یکی از مهم‌ترین اقدامات امنیتی، اعتبارسنجی اطلاعات خرید و بررسی امضای دیجیتال در سرور است.
انجام اعتبارسنجی صرفاً در سمت کلاینت، امکان دستکاری یا دور زدن فرآیند تأیید خرید را از طریق مهندسی معکوس برنامه افزایش می‌دهد.
برای افزایش امنیت، توصیه می‌شود:
- امضای دیجیتال و اطلاعات خرید را در سرور اعتبارسنجی کنید.
- پیش از فعال‌سازی محصول یا ارائه خدمات، از معتبر بودن خرید اطمینان حاصل کنید.
- ارتباط بین برنامه و سرور را از طریق HTTPS برقرار کنید.
- وضعیت خریدها و محصولات تحویل‌داده‌شده را در سرور ثبت کنید تا از استفاده مجدد از یک خرید جلوگیری شود.
- اطلاعات دریافتی از کلاینت را بدون اعتبارسنجی معتبر تلق ی نکنید.
نکته: انتقال اعتبارسنجی به سرور، احتمال دستکاری فرآیند تأیید خرید را کاهش می‌دهد، اما به‌تنهایی تضمین‌کننده امنیت کامل نیست.
۲. از محتوای دیجیتال محافظت کنید
اگر برنامه شما محتوای پولی مانند فایل‌های صوتی، تصویری یا سایر منابع دیجیتال ارائه می‌دهد، از قرار دادن نسخه محافظت‌نشده این محتوا در فایل APK خودداری کنید.
زیرا محتوای موجود در فایل APK ممکن است از طریق مهندسی معکوس یا استخراج فایل‌ها در دسترس افراد غیرمجاز قرار گیرد.
برای محافظت از محتوای دیجیتال:
- محتوای پولی را پس از اعتبارسنجی خرید، از سرور در اختیار کاربر قرار دهید.
- برای دریافت محتوا از ارتباط امن HTTPS استفاده کنید.
- دسترسی به محتوای پولی را بر اساس وضعیت خرید و مجوزهای کاربر کنترل کنید.
- در صورت نیاز به ذخیره محلی محتوا، از روش‌های رمزنگاری مناسب استفاده کنید.
- کلیدهای رمزنگاری حساس را به‌صورت ثابت و قابل استخراج در برنامه قرار ندهی د.
در صورت ذخیره محتوای حساس روی حافظه خارجی دستگاه، توجه داشته باشید که این فضا ممکن است در دسترس سایر برنامه‌ها یا کاربران قرار گیرد.
توصیه: در صورت امکان، محتوای حساس را در حافظه اختصاصی برنامه ذخیره کنید و برای مدیریت کلیدهای رمزنگاری از امکانات امنیتی اندروید مانند Android Keystore استفاده کنید.
۳. از مبهم‌سازی کد (Code Obfuscation) استفاده کنید
مبهم‌سازی کد، فرآیند تحلیل و مهندسی معکوس برنامه را دشوارتر می‌کند و می‌تواند احتمال شناسایی و دستکاری بخش‌های حساس را کاهش دهد.
برای این منظور، توصیه می‌شود از ابزار R8 که در سیستم ساخت اندروید پشتیبانی می‌شود، استفاده کنید.
هنگام فعال‌سازی مبهم‌سازی کد:
- کلاس‌ها و متدهای غیرضروری را از نسخه نهایی برنامه حذف کنید.
- نام کلاس‌ها، متدها و فیلدهای قابل مبهم‌سازی را تغییر دهید.
- از قرار دادن اطلاعات حساس و کلیدهای محرمانه در کد برنامه خودداری کنید.
- قوانین موردنیاز کتابخانه‌های استفاده‌شده را در تنظیمات R8 لحاظ کنید.
در صورت استفاده از کتابخانه‌ای که به حفظ کلاس‌های مشخصی نیاز دارد، قوانین مربوط به آن را در فایل تنظیمات R8 یا ProGuard اضافه کنید.
برای مثال، در صورت نیاز به حفظ کلاس‌های مربوط به Billing API، ممکن است از قانون زیر استفاده شود:
-keep class com.android.vending.billing.** { *; }
نکته: این قانون باید فقط در صورت نیاز و مطابق مستندات نسخه کتابخانه مورد استفاده اضافه شود. حفظ غیرضروری کلاس‌ها می‌تواند اثربخشی مبهم‌سازی را کاهش دهد.
مبهم‌سازی کد یک لایه امنیتی تکمیلی است و جایگزین اعتبارسنجی سمت سرور نمی‌شود.
۴. از کدهای نمونه بدون بررسی امنیتی استفاده نکنید
کدهای نمونه پرداخت درون‌برنامه‌ای معمولاً برای آموزش نحوه استفاده از APIها ارائه می‌شوند و لزوماً برای استفاده مستقیم در محیط عملیاتی مناسب نیستند.
پیش از انتشار برنامه:
- کدهای نمونه را متناسب با معماری برنامه خود بازبینی و پیاده‌سازی کنید.
- مدیریت خطاها و وضعیت‌های مختلف پرداخت را تکمیل کنید.
- اعتبارسنجی خرید و کنترل دسترسی به محصولات را به‌صورت مستقل پیاده‌سازی کنید.
- از باقی ماندن اطلاعات آزمایشی، تنظیمات توسعه و لاگ‌های حساس در نسخه نهایی جلوگیری کنید.
۵. از مقادیر تصادفی امن (Secure Nonce) استفاده کنید
در صورت نیاز به تولید شناسه‌های تصادفی برای درخواست‌ها یا مکانیزم‌های امنیتی، از مقادیر غیرقابل پیش‌بینی استفاده کنید.
یک Nonce امن باید ویژگی‌های زیر را داشته باشد:
- با استفاده از مولد اعداد تصادفی امن تولید شود.
- قابل پیش‌بینی نباشد.
- در محدوده اعتبار موردنظر، یکتا باشد.
- در صورت استفاده برای جلوگیری از حملات بازپخش (Replay Attack)، امکان استفاده مجدد از آن کنترل شود.
در اندروید می‌توانید برای تولید مقادیر تصادفی امن از کلاس SecureRandom استفاده کنید.
نکته: استفاده از Nonce به‌تنهایی مانع حملات بازپخش نمی‌شود. سرور باید اعتبار و وضعیت استفاده از آن را نیز بررسی کند.
۶. از Developer Payload برای ارتباط دادن خرید با کاربر استفاده کنید
در نسخه‌هایی از API پرداخت مایکت که از Developer Payload پشتیبانی می‌کنند، می‌توانید هنگام ارسال درخواست خرید، یک رشته اختیاری را همراه درخواست ارسال کنید.
این مقدار پس از انجام فرآیند خرید، همراه اطلاعات تراکنش به برنامه بازگردانده می‌شود.
برای استفاده امن از این قابلیت:
- از یک شناسه مرتبط با سفارش یا کاربر استفاد ه کنید.
- مقدار ارسال‌شده را در سیستم خود ثبت کنید.
- پس از دریافت پاسخ خرید، مقدار بازگشتی را با مقدار ثبت‌شده مقایسه کنید.
- اعتبارسنجی را ترجیحاً در سرور انجام دهید.
- از قرار دادن اطلاعات حساس مانند رمز عبور یا توکن‌های احراز هویت در Developer Payload خودداری کنید.
توجه کنید که مقدار طول رشته‌ی developerPayload نمی‌تواند بیش‌تر از ۸۰۰ کاراکتر باشد.
مهم: Developer Payload به‌تنهایی اثبات‌کننده مالکیت یا اعتبار خرید نیست و نباید جایگزین اعتبارسنجی امضای دیجیتال و اطلاعات تراکنش شود.
۷. امکان لغو دسترسی به محصولات را فراهم کنید
اگر برنامه شما محتوای پولی یا قابلیت‌های ویژه را از طریق سرور ارائه می‌دهد، توصیه می‌شود مدیریت دسترسی کاربران نیز در سمت سرور انجام شود.
با این روش می‌توانید در شرایطی مانند نامعتبر شدن خرید، بازپرداخت یا شناسایی سوءاستفاده، دسترسی کاربر به خدمات مربوطه را مدیریت کنید.
برای این منظور:
- وضعیت خرید و مجوز دسترسی کاربران را در سرور نگهداری کنید.
- پیش از ارائه خدمات حساس، اعتبار دسترسی کاربر را بررسی کنید.
- امکان لغو یا اصلاح دسترسی را در صورت نامعتبر شدن خرید فراهم کنید.
- تغییرات وضعیت خرید و دسترسی را برای بررسی‌های بعدی ثبت کنید.
لغو دسترسی باید بر اساس اطلاعات معتبر و سیاست‌های مشخص انجام شود تا از مسدود شدن اشتباه کاربران جلوگیری شود.
۸. کلید عمومی پرداخت مایکت را به‌درستی مدیریت کنید
مایکت برای هر برنامه یک کلید عمومی پرداخت (Public Key) اختصاصی ارائه می‌دهد که برای اعتبارسنجی امضای اطلاعات خرید استفاده می‌شود.
توجه داشته باشید که کلید عمومی، برخلاف کلید خصوصی، اطلاعات محرمانه محسوب نمی‌شود و افشای آن به‌تنهایی امکان جعل امضای معتبر را فراهم نمی‌کند.
بااین‌حال، برای کاهش احتمال دستکاری فرآیند اعتبارسنجی:
- اعتبارسنجی خرید را ترجیحاً در سرور انجام دهید.
- کلید عمومی معتبر هر برنامه را از پنل توسعه‌دهندگان مایکت دریافت کنید.
- از دریافت یا جایگزینی کلید عمومی از منابع نامعتبر خودداری کنید.
- در صورت استفاده از اعتبارسنجی سمت کلاینت، آن را تنها یک لایه امنیتی تکمیلی در نظر بگیرید.
نکته: روش‌هایی مانند ساخت رشته کلید در زمان اجرا یا استفاده از عملیات XOR ممکن است استخراج کلید از کد را دشوارتر کنند، اما امنیت واقعی فرآیند پرداخت را تضمین نمی‌کنند.
جمع‌بندی
برای پیاده‌سازی امن پرداخت درون‌برنامه‌ای مایکت، اعتبارسنجی سمت سرور، مدیریت صحیح مالکیت خرید، محافظت از محتوای دیجیتال و جلوگیری از تحویل تکراری محصولات را در اولویت قرار دهید.
ابزارهایی مانند R8، استفاده از مقادیر تصادفی امن و مبهم‌سازی کد می‌توانند امنیت برنامه را افزایش دهند، اما نباید جایگزین کنترل‌های امنیتی اصلی شوند.