ما نوع الضرر الذي يمكن أن يحدثه الشخص من خلال تسجيل الدخول إلى واجهة برمجة تطبيقات بوابة الدفع ومفتاح المعاملة؟

Question

أقوم حاليًا بتعيين مطور ويب للعمل على موقع يعالج بطاقات الائتمان.على الرغم من أنه لن يكون لديه بيانات الاعتماد لتسجيل الدخول إلى واجهة مستخدم بوابة الدفع، إلا أنه سيكون لديه حق الوصول إلى تسجيل الدخول إلى واجهة برمجة التطبيقات ومفتاح المعاملة نظرًا لأنه مضمن في كود التطبيق.

أود أن أكون على دراية بجميع سيناريوهات "ماذا لو" المتعلقة بنوع الضرر الذي يمكن أن يحدثه الشخص بهذه المعلومات.من الواضح أنه يمكنه معالجة بطاقات الائتمان ولكن الأموال تذهب إلى الحساب البنكي لمالك الموقع، لذا لست متأكدًا من مقدار الضرر الذي قد يسببه ذلك.هل يمكن لأي شخص أن يفكر في أي سيناريوهات أخرى محتملة؟

تحديث:بوابة الدفع المستخدمة هي Authorize.net.

Answer 1

هل هم حقا بحاجة الى الوصول الى مواقع الإنتاج الخاصة بك؟

لا تقم بتخزين المفتاح في التعليمات البرمجية الخاصة بك، واحفظها في قاعدة بيانات الإنتاج الخاصة بك، أو على ملف على خادم الإنتاج.

Answer 2

وبعض الإجابات جيدة هنا، سأضيف فقط ان كنت على الارجح بعض المتاعب مع PCI.
PCI-DSS يملي على وجه التحديد الفصل بين الواجبات وعزل بيئات الإنتاج من ديف / اختبار، وحماية مفاتيح التشفير من أي شخص لا تتطلب ذلك، وأكثر من ذلك. كما قالMatthew واتسون، إعادة النظر في هذا الأمر، ولا منح حق الوصول إنتاج للمطورين.

وبوصفها جانبا، وإذا كان يمكن الوصول إلى API مباشرة، كيف يمكنك التأكد من أن "يذهب المال في الحساب المصرفي للشركة المالكة للموقع"؟ ناهيك عن الوصول إلى كل ما بيانات بطاقة الائتمان ...

Answer 3

إذا يحصل المطور الحصول على أرقام بطاقات الائتمان الخام التي يمكن أن تصبح مشكلة أكبر كما يمكن ربط موقعك مع نشاط احتيالي، على افتراض المطور هو تفاحة فاسدة. (ويمكن إعادة توجيه أرقام الحسابات، CCV، تاريخ انتهاء الصلاحية إلى موقع آخر، على الرغم من هذا يجب أن يكون spottable من خلال أدوات الشبكة ومراجعة مدونة شاملة.)

هل أداء API التهمة "$ 1.00" (أو "$ X.XX") للتحقق من بطاقة الائتمان يمكن شحن كمية معينة (وبالتالي تعود النتيجة إلى المتصل، مثل "نعم" أو " لا")؟ إذا كان الأمر كذلك، فإنه يمكن استخدامها لأتمتة التحقق من أرقام حساب بطاقة الائتمان المتداولة على شبكة الإنترنت وإساءة استخدام مثل هذا النظام يمكن أن تؤدي إلى الخلف إلى أنت.

Answer 4

ومع أي بوابة لقد عملت مع، معالج الدفع يربط مفتاح API إلى IP معين أو نطاق IP لموقع التاجر. وقال مع ذلك، ما لم يتم تنفيذ الخبيثة التعليمات البرمجية في السؤال على نفس الخادم كما التاجر (؟) - لا ينبغي أن يكون هناك أي مخاوف أمنية في هذا الشأن

إذا لم تكن هذه هي الحال بالنسبة لموقع التاجر الخاص بك - الاتصال بهم وأسأل ما إذا كان ذلك ممكنا

Answer 5

هل تسمح بوابة الدفع لعكس التهم؟ إذا كان الأمر كذلك هناك احتمال وجود عدد من الحيل يتم تشغيل.

Answer 6

هل يقوم الموقع بمعالجة المبالغ المستردة؟هل سيحدث ذلك في المستقبل؟

إذا كنا نتحدث عن الاستخدامات الشائنة، فقد يتم التحقيق مع مالك الموقع في حالة إجراء الكثير من عمليات الشراء غير المصرح بها.كيف سيؤثر ذلك أنت إذا تم التحقيق مع المالك؟

Answer 7

ومن وصفك يبدو أن هذا المطور من الحصول على تفاصيل بطاقات العملاء في هذه الحالة على خصوصية العملاء قد تتعرض للخطر. قد تفكر في صيغة العقد بشكل مناسب للتأكد من أن يتم تغطية هذه الزاوية.

ولكن النقطة الرئيسية هي أنه إذا كنت تعمل على مشروع الحساسة / معلومات فمن الأفضل لك أن تجد الناس هل يمكن الوثوق بها. التعاقد مع بيت البرمجيات للقيام بهذه المهمة قد يوفر لك بعض النوم في وقت لاحق.

Answer 8

وأولا وقبل كل شيء، فمن الأفضل لك أن أبدا تخزين هذا النوع من المعلومات في نص عادي. وعادة ما يأخذ الناس هذا عن معرفة المستعملة للأرقام بطاقات الائتمان (للأسف، فقط لأسباب قانونية)، ولكن ينبغي مشفرة أي نوع من البيانات الخاصة التي لا تريد الآخرين مع المشاهدة الوصول إلى قاعدة البيانات / شفرة المصدر. يجب تخزين معلومات الحساب في مكان ما في شكل مشفرة بشكل جيد، ويجب توفير حساب اختبار للمطورين لاستخدامها في محطات العمل تنميتها. بهذه الطريقة، فقط الناس مع وصول الخادم قادرون أن نرى حتى المعلومات المشفرة.

وبهذه الطريقة، يمكن أن يكون لديك قاعدة بيانات على محطة العمل المطور بمعلومات API الحساب اختبار المخزنة (مشفرة أمل) في انها قاعدة بيانات محلية، ولكن عندما ينعكس رمز على خادم الإنتاج فإنه لا يزال استخدام حية، بوابة حقيقية المعلومات المخزنة على قاعدة بيانات خادم الإنتاج دون رمز إضافية / التكوين.

ومع هذا قال، وأنا لا أعتقد أن مبرمجا مع API تفاصيل المصادقة يمكن أن تفعل الكثير. وفي كلتا الحالتين، فإنه لا يستحق المخاطرة - في رأيي

وهذا الأمل مساعدة.

وPS: إذا كان شيئا سيئا لا ينتهي يحدث، فإنك يمكن أن تولد دائما مفتاح جديد في واجهة على شبكة الإنترنت authorize.net بعد أن كنت قد اتخذت الاحتياطات للتأكد من أنها لن يحدث مرة أخرى

.

Answer 9

في حالة معينة من Authorize.Net أنها لن تكون قادرة على القيام الاعتمادات نحو بطاقات الائتمان الخاصة بهم منذ Authorize.Net يسمح فقط هذا الذي ينبغي القيام به في العمليات المنفذة من خلالها في غضون الأشهر الستة الماضية. والاستثناء الوحيد الذي يسمح إذا تم منحك استثناء لتسديدات غير المرتبطة. إذا كنت قد وقعت أعمال إدارية مناسبة لهذا وشخص لديه تسجيل الدخول API ومفتاح الصفقة ثم بعد ذلك يمكن معالجة الاعتمادات نحو بطاقات الائتمان الخاصة بهم. الطريقة الوحيدة بالنسبة لك للقبض على هذا سيكون لرصد البيانات الخاصة بك بعناية.

لمساعدة في تخفيف هذا يجب تغيير مفتاح معاملتك فور الانتهاء من عمل يقومون به بالنسبة لك. ومن شأن ذلك أن يجعل المفتاح لديهم عديمة الفائدة بعد 24 ساعة.