پرداخت و افزاره‌های هوشمند

گسترش روزافزون کاربرد افزاره‌های هوشمند و در پی آن رشد چشمگیر استفاده از برنامک‌های بومی ، تامین امنیت پرداخت در این حوزه را به یکی از چالش‌های روزآمد صنعت پرداخت‌های الکترونیکی تبدیل نموده است . روش صفحهْ پرداختِ میزبانی‌شدهْ مبتنی بر جهت‌دهی  بین دامنه‌ی پذیرنده و پرداخت در ترکیب با سازوکار SSL/TLS ، امنیت فرآیند پرداخت‌های برخط در وب‌گاه‌ها را فراهم می‌نماید اما کاربرد رایج شده‌ی آن در برنامک‌های بومی افزاره‌های هوشمند (برای نمونه در برنامکهای بازارچه‌های محلی بسترهای هوشمند Android و iOS در ایران) چالش‌برانگیز و ناامن است چرا که عملا جهت‌دهی بین دو دامنه‌ی پذیرنده و پرداخت چه از دید تعامل با رابط کاربری و چه از دید انتقال فرمان اجرا  صورت نمی‌پذیرد . در حقیقت نبود روش‌های پرداخت الکترونیک بهینه شده برای سناریوهای حوزه کسب‌وکارهای افزاره‌های هوشمند به ویژه پرداخت درون برنامکی  سبب گردیده تا فراهم‌کنندگان این خدمات در کشور روش‌های موجود را به شیوه‌ای ناامن به کار گیرند که عدم توجه نهادهای ناظر بر سامانه‌های پرداخت به این مشکل ، ممکن است عواقب جبران‌ناپذیری را متوجه صنعت پرداخت‌های الکترونیکی به ویژه در حوزه‌ی رو به رشد برنامک‌های افزاره‌های هوشمند نماید .

پرداخت‌های الکترونیکی را می‌توان با شاخص‌های گوناگونی مانند الگوی پرداخت  ، فناوریهای به کار رفته ، فرآیند انجام کار (یا مدل پرداخت) و نقش‌های درگیر در آن و بسیاری شاخص‌های دیگر ، دسته‌بندی نمود . بر اساس شاخصِ حضورِ  ابزار پرداخت ، پرداخت‌ها را می‌توان در دو گروه ؛ پرداخت‌های حضوری  و غیرحضوری  ، دسته‌بندی نمود .

امنیت در پرداخت‌های غیرحضوری

در پرداخت حضوری ، دارنده (و ابزار پرداخت) باید در مکان فیزیکی خاصی نزد پذیرنده (یا ابزار پذیرش) حاضر گردد (برای نمونه پرداخت از طریق پایانه‌های پرداخت) اما در پرداخت غیرحضوری ، دارنده می‌تواند از طریق یک پایانه‌ی راه دور مجازی روی یک شبکه‌ی رایانه‌ای ، فرآیند پرداخت را آغاز و هدایت نماید (مانند خرید از فروشگاه‌های مجازی و پرداخت برخط) . در الگوی عمومی پرداخت مبتنی بر چهار نقش ، اطلاعاتِ پرداختِ دارنده شامل شناسه‌ی یکتای ابزار پرداخت و اطلاعات اعتبارسنجی ابزار پرداخت توسط ابزارِ پذیرشِ پذیرنده ، دریافت شده و توسط یک واسط پرداخت  (و یا یک شبکه‌ی پرداخت) که عموما شامل بانک پذیرنده در ارتباط با بانک صادرکننده است ، پردازش شده و عملیات پرداخت انجام می‌پذیرد . با توجه به استانداردها و ملاحظات امنیتی اعمال شده بر ابزارهای پذیرش ، هر چند الگوی عمومی پرداخت در پرداخت‌های حضوری ، با امنیت قابل قبولی انجام می‌شود ، اما در پرداخت‌های غیر حضوری ، مخاطرات امنیتی بسیاری دارنده را تهدید می‌نمایند . در حقیقت با توجه به عدم حضور فیزیکی دارنده و ابزار پرداخت در پرداخت‌های غیر حضوری ، حفظ امنیت در این گونه از پرداخت‌ها بسیار مهم بوده و استانداردها و الزامات مشخصی برای کاهش ریسک این دسته از تراکنشهای مالی در نظر گرفته می‌شود .

در یک تراکنش مبتنی بر شبکه‌های رایانه‌ای ممکن است به نحوی اطلاعاتِ پرداختِ دارنده ، افشا شده و یا به سرقت رود و سارق سپس می‌تواند با جعلِ هویت  به روشهای مختلف از ابزار پرداخت سوء استفاده نماید . در سناریو خرید از فروشگاه‌های مجازی که یک نمونه از پرداخت‌های غیر حضوری به شمار می‌آید ، ابزار پذیرش وبگاه فروشنده است و مطابق الگوی عمومی پرداخت ، پذیرنده اطلاعاتِ پرداختِ دارنده را از طریق وبگاه دریافت  می‌نماید تا از طریق واسط پرداختی که پذیرنده بدان متصل است ، تراکنش پرداختْ پردازش گردد . در این حالت یک پذیرنده‌ی متقلب ممکن است اطلاعات پرداخت دارندگان را پنهانی ذخیره نموده و سپس از آن سوء استفاده نماید . این موضوع به ویژه هنگامی که ابزار پرداخت دارندگان کارتهای نقدی و روش تسویه در واسط پرداخت آنی باشد ، تهدید امنیتی بسیار مهمی به شمار می‌آید .

استاندارد SET یا تراکنش الکترونیکی امن ، الگو و روشی از پرداخت را با هدف جلوگیری از افشا یا سرقت اطلاعات پرداختِ دارنده توسط پذیرنده ، پیشنهاد می‌نماید اما پیاده‌سازی و کاربری آن ، بسیار سخت و پیچیده است . از این رو شماری از فراهم کنندگان و توسعه‌دهنده‌گان برتر خدمات پرداخت (مانند Visa و MasterCard) ، روشها و الگوهای دیگری را که کاربری ساده‌تر و پیاده‌سازی آسانتری نسبت به SET دارند ، توسعه داده و به کار گرفته‌اند .

الگوهای مبتنی بر تفکیک و جهت‌دهی بین دامنه‌ها

روش ۳D Secure یا ۳D SET ، هر دو روشهای ساده‌تری از SET مبتنی بر الگوی سه دامنه (۳D) هستند که در تراکنش‌‌های پرداختِ برخط ، از آنها پیروی می‌شود . در روش ۳D Secure ، سه دامنه شامل ؛ دامنه‌ی دارنده و صادرکننده‌ی کارت (بر روی هم دامنه‌ی پرداخت) ، دامنه‌ی فروشنده (یا پذیرنده) و پذیرنده‌ی پرداخت  (بر روی هم دامنه‌ی پذیرنده) و یک دامنه‌ی میانی ، تعریف گردیده و فرآیند به گونه‌ای است که مرورگرِ وبِ دارنده ، بین دامنه‌ی پرداخت و دامنه‌ی پذیرنده ، جهت‌دهی  می‌شود . جهت‌دهی بین دامنه‌ها در همه‌ی روشهای مبتنی بر تفکیک دامنه‌ها ، برای جلوگیری از افشا یا سرقت اطلاعات پرداخت دارنده توسط پذیرنده که یکی از هدفهای SET می‌باشد ، در نظر گرفته شده است . هر چند روشهای مبتنی بر سه دامنه ، کاربری ساده‌تر و پیاده‌سازی آسان‌تری نسبت به SET دارند ، اما همچنان هزینه‌های پیاده‌سازی و نگه‌داری سامانه‌های مبتنی بر چنین روشهایی برای پذیرندگان به ویژه پذیرندگان خُرد به سبب الزامات استاندارد PCI بالاست . افزون بر این یکی دیگر از مشکلات روش ۳D Secure ، آنستکه بخشی از اطلاعات پرداخت (برای نمونه PIN) در یک پنجره popup روی وب‌گاه پذیرنده ، از دارنده دریافت می‌شود که یک تهدید امنیتی است چرا که یک پذیرنده‌ی متقلب می‌تواند با جعل  و شبیه‌سازی پنجره‌ی Verified By Visa اقدام به دریافت اطلاعاتِ پرداختِ دارنده ، نماید  .

صفحهْ پرداخت میزبانی‌شده

صفحهْ پرداختِ میزبانی‌شده یا صفحهْ سفارشِ میزبانی‌شده ، هر دو روش‌هایی مبتنی بر جهت‌دهی دامنه بین پذیرنده و پرداخت می‌باشند که با هدف حل مشکلات دیگر روش‌های مبتنی بر تفکیک دامنه‌ها پیشنهاد شده‌اند . هر دو روش با جهت‌دهی دامنهْ مانع از افشای اطلاعات پرداخت دارنده به پذیرنده شده و همزمان پذیرنده را از صرف هزینه‌های پیاده‌سازی PCI رهایی می‌بخشند چرا که صفحهْ پرداخت در بستر امن پذیرنده‌ی پرداخت میزبانی می‌شود .

برای نمونه در خرید از یک فروشگاه مجازی یکپارچه شده با صفحهْ پرداختِ میزبانی‌شده ، نخست دارنده در مرورگر وبْ و از طریق واسط کاربری وب‌گاه پذیرنده (در دامنه‌ی پذیرنده) ، خرید را انجام داده و هنگام پرداخت ، مرورگر وبْ به صفحهْ پرداختِ میزبانی‌شده در وبگاه پذیرنده‌ی پرداخت (در دامنه‌ی پرداخت) جهت‌دهی می‌شود تا اطلاعات پرداخت را وارد نماید و پس از آن ، دوباره در مرورگر وب به وب‌گاه پذیرنده جهت‌دهی می‌شود که جهت‌دهی بین دو وب‌گاه بصورت HTML Redirect ، رخ می‌دهد .

مهمترین ویژگی راهکار صفحهْ پرداختِ میزبانی شده یا صفحهْ سفارشِ میزبانی‌شده ، جهت‌دهی دارنده بین دو دامنه (یا بستر) پذیرنده و پرداخت چه از نظر دیداری و تعامل با واسط کاربری و چه از نظر انتقال فرمان اجرا است و در  ترکیب با سازوکار SSL/TLS ، فرآیند پرداخت‌های برخط در وب‌گاه‌ها را تا حد قابل قبولی امن می‌نماید اما کاربرد صفحهْ پرداختِ میزبانی‌شده در برنامک‌های بومی افزاره‌های هوشمند چالش برانگیز و نا امن است .

روش صفحهْ پرداختِ میزبانی‌شده در ایران (به اشتباه) تحت نام خدمات درگاه پرداخت اینترنتی (یا درگاه پرداخت) ارائه می‌شود و در چنین حالتی پذیرنده‌ی پرداخت یا بانک پذیرنده به عنوان فراهم‌ کننده‌ی خدمات پرداخت ، زیرساخت پرداخت میزبانی‌شده  را فراهم می‌آورد . در این حالت درگاه پرداخت در ارتباط با یک واسط یا شبکه‌ی پرداخت (شبکه‌ی شاپرک) اعتبارسنجی اطلاعات پرداخت دارنده و تسویه‌ی بین پذیرنده و دارنده را انجام می‌دهد .

صفحهْ پرداخت میزبانی‌شده و برنامک‌های افزاره‌های هوشمند

روش رایج در کاربرد و یکپارچه‌سازی صفحه پرداخت میزبانی‌شده با برنامک‌های بومی (برای نمونه در برنامکهای بازارچه‌های محلی بسترهای هوشمند Android و iOS در ایران) ، استفاده از سرویس‌گیرنده‌های وب جاسازی‌شده  در رابط کاربری برنامک‌های بومی است . در این روش هنگام پرداخت ، صفحهْ پرداختِ میزبانی‌شده از طریق یک سرویس‌گیرنده‌ی وب جاسازی‌شده در همان رابط کاربری برنامک پذیرنده به دارنده نمایش داده می‌شود . در این روش هرچند ظاهراً دارنده اطلاعاتِ پرداختْ را در صفحهْ پرداختِ میزبانی‌شده از یک وبگاه در دامنه‌ی پرداخت ، وارد می‌نماید اما هیچ جهت‌دهی بین دو بستر پذیرنده و پرداخت ، چه از نظر دیداری و چه از نظر انتقال کامل فرمان اجرا رخ نمی‌دهد که این نکته خلاف هدف روش‌های مبتنی بر جهت‌دهی بین دامنه (یا بستر) پذیرنده و پرداخت بوده و مشکل تهدیدات ناشی از جعل را نه تنها کاهش نمی‌دهد بلکه خود یک حفره‌ی امنیتی برای انجام حملات فیشینگ به شمار می‌آید .

سرویس‌گیرنده‌ی‌ وب (یا WebView) فناوری بسته‌بندی  نمودن کارکردهای پایه‌ی مرورگرهای وب مانند ؛ پرداز صفحات وب ، ناوبری و اجرای JavaScript در قالب یک جزء نرم‌افزاری با قابلیت جاسازی در رابط کاربری برنامک‌های بومی است . تعامل بین برنامک و سرویس‌گیرنده‌ی وب دو سویه است . برنامک می‌تواند کُد JavaScript را در صفحات وب ، درج و یا فراخوانی نماید . همچنین برنامک می‌تواند رویدادهای صفحات وب را پایش و دریافت نماید . بنابراین یک برنامک مخرب از پذیرنده‌ی متقلب ، می‌تواند در صفحه پرداخت میزبانی‌شده یک کُد JavaScript را پنهانی درج نماید تا هنگامی که دارنده اطلاعات پرداخت را از طریق صفحه پرداخت ارسال می‌نماید ، یک نسخه از اطلاعات پرداخت را پنهانی در برنامک ذخیره نماید . بدین ترتیب ممکن است اطلاعات پرداخت دارنده توسط پذیرنده‌ی متقلب به سرقت رود . از این رو جاسازی صفحات پرداختِ میزبانی‌شده در برنامک‌های بومی از طریق WebViewها عملا خلاف فلسفه‌ی طراحی روشهای مبتنی بر تفکیک دامنه (یا بستر) و جهت‌دهی بین دامنه‌ها برای امن‌سازی پرداخت‌های الکترونیکی است .

پرداخت درون برنامکی

یکی دیگر از روشهای رایج پرداخت الکترونیکی در برنامک‌های بومی ، پرداخت دورن برنامکی است که راهکار بومی بیشتر سامانه‌های عامل هوشمند است . پرداخت درون برنامکی  ، سازوکاری است که دارنده بدون ترک برنامک بومی و از طریق یک رابط کاربری که فناوری پرداخت درون برنامکی آنرا فراهم می‌نماید ، می‌تواند پرداخت خود را انجام دهد . برای نمونه سامانه‌ی عامل هوشمند iOS از شرکت Apple ، پرداخت درون برنامکی In – App Purchase و پلتفرم هوشمند Android از شرکت Google ، راهکار In – App Billing را برای پرداخت درون برنامکی فراهم آورده است . همچنین شرکت Microsoft راهکار In – App Purchase را در سیستم عامل هوشمند Windows Phone OS برای پرداخت درون برنامکی فراهم نموده است. افزون بر فناوریهای پرداخت درون برنامکی ارائه شده توسط سازندگان سامانه‌های عامل هوشمند ، راهکارهای دیگری نیز از طرف شرکت‌های ثالث پیشنهاد شده است که برای نمونه می‌توان از PayPal نام برد . در فناوری پرداخت درون برنامکی ، پذیرنده اطلاعات خرید را از طریق رابط کاربری برنامک پذیرنده ، از دارنده دریافت می‌نماید . سپس هنگام پرداخت توابعی از واسط برنامه‌نویسی کاربردی  پرداخت درون برنامکی را فراخوانی می‌نماید . این فراخوانی سبب هدایت کاربر به یک دنباله از رابطهای کاربری گردیده که دارنده اطلاعات پرداخت را در آنها وارد می‌نماید بدون آنکه برنامک پذیرنده را ترک و تعامل با آن را پایان دهد . رابطهای کاربری پرداخت توسط سازوکار پرداخت درون برنامکی ایجاد و به کاربر نمایش داده می‌شود . اساسی‌ترین مشکل فناوری‌های پرداخت درون برنامکی عدم تطابق با مدلهای تفکیک دامنه و تغییر دامنه بین پذیرنده و پرداخت در فرآیند پرداخت است که این موضوع سبب می‌گردد تا این فناوری‌ها مستعد تهدیدات و حملات جعل و فیشینگ باشند . در حقیقت یک پذیرنده متقلب می‌تواند رابطهای کاربری پرداخت درون برنامکی را جعل و دارنده را تشویق به ورود اطلاعات پرداخت در رابط کاربری جعلی نماید و بدین ترتیب اطلاعات پرداخت دارندگان را سرقت کند .

این نوشته بخشی از مقاله‌ای است که در چهارمین همایش سالانه بانکداری الکترونیک و نظام‌های پرداخت (بهمن‌ماه ۱۳۹۳) ارائه شده است .

یک نسخه قابل چاپ از این مقاله ، اینجا و یک نگارش بهتر از آن اینجا در دسترس است .