هشدار: امنیت ماژول های درگاه پرداخت

[≡ ALEX ≡]

من به عنوان یک برنامه نویس و کسی که قبلا به فعالیت های امنیتی و Hacking و Cracking مشغول بوده و دید کاملی به مسائل هر دو دارد، در برنامه نویسی بسیار محتاط هستم و واقعا در مورد تمام جزئیات زیاد فکر می کنم...

وقتی بحث عجله باشد حتی من هم با تمام وسواسی که دارم یکسری جاها رو بیخیالی طی می کنم و یا فراموش...

مدتی پیش در حین آپدیت اسکریپت پرداخت بانکی پورتال شرکت، متوجه شدم یکسری حفره های امنیتی وجود داره که اگر شخصی یک هکر درست حسابی و مسلط به مباحث باشه به راحتی می تونه استفاده های مختلفی از این موارد بکنه و یا حداقل اش این هست که به عنوان یک Bug موجود در سیستم امکان عملکرد خارج از حیطه تعریف شده فراهم هستش. البته با احتمال کمی که در مورد وجود یک هکر آگاه وجود داشت، تا فرصت کافی در آینده، این مسئله رو ندیده گرفتم. این نکته هم بگم که اسکریپت های دیگری که در سطح وب وجود دارند، چه پولی و چه نال و یا Open Source و با توجه به اینکه اکثر آن ها رو قبلا بررسی کرده و دیده ام، می بایست بگم که وضعیت اکثر آن ها به مراتب خراب تر بوده است.

این مواردی که عرض کردم، مختص بانک و یا سیستم خاصی نیست، چون همه این ها تقریبا به یک صورت عمل می کنند و روند خاص خود را دارند، می توان گفت که تقریبا اغلب و یا اکثر این سیستم ها دچار مشکلات یاد شده هستند.

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

امروز فرصت کافی بود تا برای اولین بار بنشینم و ماژول سیستم جدید شرکت را به صورت اصولی و با پیشبینی همه شرایط کد نویسی کنم. در این بین بیش از پیش به باگ ها و حفره های موجود پی بردم و اینکه اگر برخی از آن ها برطرف نشده و شخصی آگاه قصد هک سیستم را بکند، چقدر در مسائل مالی شرکت ها مشکل بوجود می آید، آن هم بدون اطلاع ایشان، مخصوصا اگر حساب کتاب های خود را بصورت دقیق و دوره ای بررسی ننمایند.

خلاصه مطلب خواستم به شما دوستان عزیز این مورد را اطلاع داده و هشداری داده باشم تا بصورت دقیق و با ذهنی باز در مورد کد های اسکریپت های درگاه پرداخت خود بازنگری داشته باشید و مشکلات موجود را کشف و رفع نمایید تا در آینده خدای ناکرده دچار مشکل نشوید... این مشکلات از کلاهبرداری کاربران تا اشکالات مالی و بهم ریختن حساب کتاب های اتوماسیون شما می تواند گسترده باشد.

موفق و پیروز باشید

[MostafaBestMan]

سلام
ممنون از اطلاع رسانی شما.
اما همانطور که میدانید خیلی از افرادی که از این اسکریپتها استفاده میکنند از برنامه نویسی چیزی نمیدونن چون تخصصشون نیست
بهتر نبود راهکاری برای این مشکل عنوان میکردید که همه بتونن ازش استفاده کنن؟
صرفأ با دادن هشدار که مشکلی حل نمیشه.مخصوصأ در شرایطی که بسیاری از اسکریپتهای موجود ( پولی رایگان اوپن سورس ) رو به خاطر باگ ها زیر سوال بردید.
برای یک کاربر عادی چیزی جز استرس که نکنه اسکریپت من هم باگ داشته باشه ، نداره فکر کنم.
ممنون میشم راهکار درست و مناسبی اگر دارید عنوان کنید.
با تشکر از شما

[≡ ALEX ≡]

سلام
ممنون از اطلاع رسانی شما.
اما همانطور که میدانید خیلی از افرادی که از این اسکریپتها استفاده میکنند از برنامه نویسی چیزی نمیدونن چون تخصصشون نیست
بهتر نبود راهکاری برای این مشکل عنوان میکردید که همه بتونن ازش استفاده کنن؟
صرفأ با دادن هشدار که مشکلی حل نمیشه.مخصوصأ در شرایطی که بسیاری از اسکریپتهای موجود ( پولی رایگان اوپن سورس ) رو به خاطر باگ ها زیر سوال بردید.
برای یک کاربر عادی چیزی جز استرس که نکنه اسکریپت من هم باگ داشته باشه ، نداره فکر کنم.
ممنون میشم راهکار درست و مناسبی اگر دارید عنوان کنید.
با تشکر از شما

حقیقتش به علت کمبود وقت بیشتر از یک هشدار کاری نمی تونم برای دوستان انجام بدم. چون هر سیستم و هر بانکی روش کار خاص خودش رو داره و بصورت کلی نمیشه راه حل ارایه کرد.

من برای سیستم HostBill و درگاه بانک سامان (که به نظرم از همه درگاه های بانکی از لحاظ عملکرد و نیز سیستم فنی و وب سرویس، بهتر و راحت تر هستش) حدود 1000 خط کد نویسی کردم (کلاس دیتابیس و ... رو حساب نکردم، فقط کلاس و فایل های اصلی ماژول) تا خیالم از همه نظر راحت شد... البته بخشی از این موارد بدون کمک بانک و ارایه دادن یک Documentation کامل شاید غیر ممکن می نمود... برخی از بانک ها هستند که DOC خیلی ناقص و پر رمز و رازی رو ارایه کرده اند (همچون پارسیان) و کد نویسی برای چنین بانک های بسیار رنج آور هستش و در برخی موارد انعطاف لازم را نیز از کاربر سلب می کنند.

به هر صورت بهتره امیدوار باشید که دیگر برنامه نویسان این انجمن و نیز ارایه دهنگان ماژول ها یک بازنگری داشته باشند و سعی کنند همه موارد را پوشش دهند. به عنوان یک راهنمایی خدمت این دسته عرض کنم که هکر را در مراحل مختلف فرض کرده و فکر کنید پله پله دسترسی بیشتری پیدا کرده و شما باید در آن سطح ایشان را متوقف کنید. مهمترین نکته نیز در مورد عدم پرینت اطلاعات پرداخت در خروجی HTML هستش... بهتره به جای این کار از یک Database Session استفاده کنید. و نیز Verify و Validate کردن تمامی داده ها... موارد دیگری هم هستند که با کمی دقت و صرف وقت پیدا خواهید کرد. موارد تابلو مثل Escape کردن داده های ورودی به دیتابیس جهت جلوگیری از SQL Injection و ... را نیز که حتما فراموش نخواهید کرد. در کل موارد خیلی پیچیده ای نیستند و فقط نیازمند دقت برنامه نویس در مورد مسائل امنیتی می باشند.

موفق باشید

[rezaonline.net]

یکی از مواردی که بنده به دوستان پیشنهاد میکنم ، چنانچه از ماژول استفاده میکنید حتما سورس باز باشد و کد نشده باشد .
یک مورد دیگه استفاده ، ماژول بانکهای پاسارگاد و گردشگری و سیستم های مشابه این دو بانک که اعتبار سنجی با استفاده از کلید خصوصی انجام میشود ، دقت کنید که کلید خصوصی از طریق url قابل دسترس نباشد .

وبسرویس بانک ها بنده شدیدا طرفدا وبسرویس بانک ملی (سداد هستم ) .
در تمامی بانکها عملیات در دو مرحله باید انجام شود ، یکیش مرحله شروع پرداخت که یک request به بانک هست .
بعضی از بانک ها مثل پارسیان و ملی در این مرحله باید وبسرویس بانک رو درخواست کرد و بعد ارجاع داد به بانک که این خودش خوبه و یک مرحله امنیتی هست چون ارسال اطلاعات با استفاده از وبسرویس از سمت سرور انجام میشود و کاربر اطلاعات اصلی را متوجه نمیشود .
اما بعضی از بانکها مثل تجارت ، سامان ، اقتصاد نوین و ... باید ارسال اطلاعات بصورت متد post با فرم باشد ، که به راحتی میشود مبلغ ارسالی را دستکاری کرد
برنامه نویس در برگشت باید حتماً حتماً مبلغ ارسالی به درگاه رو با توجه به عملیات verify که انجام میده مقایسه کنه و در صورت مغایرت اقدامات لازم رو انجام بده .

عملیات verify یا بررسی صحت تراکنش در همه بانکها وجود داره و الزامی باید انجام بشه .
در بعضی بانکها مثل ملی اگر عملیات verify بعد از 20 دقیقه از سمت فروشگاه انجام نشه مبلغ پرداختی به حساب پرداخت کننده برگشت داده میشه اما بعضی از بانکها مثل پاسارگاد متاسفانه چنین نیست .
و این مشکلی ایجاد میکنه
به طور مثال اگر در خرید شارژ وقتی به سایت فروشنده برمیگردد سایت داون باشه باید برید شناسه پرداخت رو بفرستید به فروشنده و اون استعلام کنه و خلاصه دردسرهایی داره .

این توصیه ای که جناب ≡ ALEX ≡ کردند رو جدی بگیرید .
موفق باشید

[rezaonline.net]

یکی از مواردی که بنده به دوستان پیشنهاد میکنم ، چنانچه از ماژول استفاده میکنید حتما سورس باز باشد و کد نشده باشد .
یک مورد دیگه استفاده ، ماژول بانکهای پاسارگاد و گردشگری و سیستم های مشابه این دو بانک که اعتبار سنجی با استفاده از کلید خصوصی انجام میشود ، دقت کنید که کلید خصوصی از طریق url قابل دسترس نباشد .

وبسرویس بانک ها بنده شدیدا طرفدا وبسرویس بانک ملی (سداد هستم ) .
در تمامی بانکها عملیات در دو مرحله باید انجام شود ، یکیش مرحله شروع پرداخت که یک request به بانک هست .
بعضی از بانک ها مثل پارسیان و ملی در این مرحله باید وبسرویس بانک رو درخواست کرد و بعد ارجاع داد به بانک که این خودش خوبه و یک مرحله امنیتی هست چون ارسال اطلاعات با استفاده از وبسرویس از سمت سرور انجام میشود و کاربر اطلاعات اصلی را متوجه نمیشود .
اما بعضی از بانکها مثل تجارت ، سامان ، اقتصاد نوین و ... باید ارسال اطلاعات بصورت متد post با فرم باشد ، که به راحتی میشود مبلغ ارسالی را دستکاری کرد
برنامه نویس در برگشت باید حتماً حتماً مبلغ ارسالی به درگاه رو با توجه به عملیات verify که انجام میده مقایسه کنه و در صورت مغایرت اقدامات لازم رو انجام بده .

عملیات verify یا بررسی صحت تراکنش در همه بانکها وجود داره و الزامی باید انجام بشه .
در بعضی بانکها مثل ملی اگر عملیات verify بعد از 20 دقیقه از سمت فروشگاه انجام نشه مبلغ پرداختی به حساب پرداخت کننده برگشت داده میشه اما بعضی از بانکها مثل پاسارگاد متاسفانه چنین نیست .
و این مشکلی ایجاد میکنه
به طور مثال اگر در خرید شارژ وقتی به سایت فروشنده برمیگردد سایت داون باشه باید برید شناسه پرداخت رو بفرستید به فروشنده و اون استعلام کنه و خلاصه دردسرهایی داره .

این توصیه ای که جناب ≡ ALEX ≡ کردند رو جدی بگیرید .
موفق باشید

[rezaonline.net]

یکی از مواردی که بنده به دوستان پیشنهاد میکنم ، چنانچه از ماژول استفاده میکنید حتما سورس باز باشد و کد نشده باشد .
یک مورد دیگه استفاده ، ماژول بانکهای پاسارگاد و گردشگری و سیستم های مشابه این دو بانک که اعتبار سنجی با استفاده از کلید خصوصی انجام میشود ، دقت کنید که کلید خصوصی از طریق url قابل دسترس نباشد .

وبسرویس بانک ها بنده شدیدا طرفدا وبسرویس بانک ملی (سداد هستم ) .
در تمامی بانکها عملیات در دو مرحله باید انجام شود ، یکیش مرحله شروع پرداخت که یک request به بانک هست .
بعضی از بانک ها مثل پارسیان و ملی در این مرحله باید وبسرویس بانک رو درخواست کرد و بعد ارجاع داد به بانک که این خودش خوبه و یک مرحله امنیتی هست چون ارسال اطلاعات با استفاده از وبسرویس از سمت سرور انجام میشود و کاربر اطلاعات اصلی را متوجه نمیشود .
اما بعضی از بانکها مثل تجارت ، سامان ، اقتصاد نوین و ... باید ارسال اطلاعات بصورت متد post با فرم باشد ، که به راحتی میشود مبلغ ارسالی را دستکاری کرد
برنامه نویس در برگشت باید حتماً حتماً مبلغ ارسالی به درگاه رو با توجه به عملیات verify که انجام میده مقایسه کنه و در صورت مغایرت اقدامات لازم رو انجام بده .

عملیات verify یا بررسی صحت تراکنش در همه بانکها وجود داره و الزامی باید انجام بشه .
در بعضی بانکها مثل ملی اگر عملیات verify بعد از 20 دقیقه از سمت فروشگاه انجام نشه مبلغ پرداختی به حساب پرداخت کننده برگشت داده میشه اما بعضی از بانکها مثل پاسارگاد متاسفانه چنین نیست .
و این مشکلی ایجاد میکنه
به طور مثال اگر در خرید شارژ وقتی به سایت فروشنده برمیگردد سایت داون باشه باید برید شناسه پرداخت رو بفرستید به فروشنده و اون استعلام کنه و خلاصه دردسرهایی داره .

این توصیه ای که جناب ≡ ALEX ≡ کردند رو جدی بگیرید .
موفق باشید

[Ehsan lashkari]

مثل این می مونه که بخوای بری مسافرت یکی بگه

ماشینت خرابه ها ، مواظب باش!

کجاش خرابه؟ چی کارش کنم؟ کجا ببرم درستش کنم ؟

بگه اینا رو نمی دونم ، ولی ماشینت خرابه!

[≡ ALEX ≡]

مثل این می مونه که بخوای بری مسافرت یکی بگه

ماشینت خرابه ها ، مواظب باش!

کجاش خرابه؟ چی کارش کنم؟ کجا ببرم درستش کنم ؟

بگه اینا رو نمی دونم ، ولی ماشینت خرابه!

البته مثال بهترش اینه که من و شما هر دو در حال رانندگی هستیم و من متوجه میشم در ماشین تون بازه و یا لاستیک عقب پنچر شده، در حین حرکت به شما هشدار میدم که بزنید کنار و یه فکری به حالش بکنید...

[Ehsan lashkari]

اختیار دارید استاد
دیگه یه پنچری رو خودمون می تونیم عوض کنیم یا حتی پنچری رو بگیریم!
ولی کار هر کسی نیست موتور رو باز کنه و دوباره جمعش کنه!

ولی هشدار شما رو جدی میگیریم

[shingo]

کلا موارد امنیتی بسیار زیادی توسط این سرویس ها نادیده گرفته میشه

از اصول امنیتی پایه برای این کار استفاده از ssl هست تا اطلاعات به صورت رمزنگاری شده بین سایت و مشتریان تبادل بشه

ولی متاسفانه اون طور که بنده خیر دارم تقریبا هیچ کدوم از سرویس دهنده ها ssl رو روی سرویسشون راه اندازی نکردند