منع سوء إدخال البيانات

Question

هو ممارسة جيدة مندوب التحقق من صحة البيانات بالكامل إلى مشغل قاعدة بيانات القيود ؟

التحقق من صحة البيانات من التطبيق لا يمنع صالح الإدراج من برنامج آخر (ربما كتب في لغة أخرى من قبل فريق آخر).باستخدام قاعدة بيانات القيود يمكنك تقليل النقاط التي تحتاج للقلق حول صالحة إدخال البيانات.

إذا وضعت التحقق من صحة كل من في قاعدة بيانات التطبيق, صيانة تصبح مملة ، لأن لديك لتحديث الكود الذي يعرف كيف العديد من التطبيقات ، مما يزيد من احتمال الأخطاء البشرية.

أنا فقط لا أرى هذا يجري كثيرا ، وتبحث في رمز من مشاريع البرمجيات الحرة.

Answer 1

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

هذا يمكن القيام به على حد سواء بسيطة التحقق من صحة المدخلات (مثل الأرقام أو التواريخ) والبيانات ذات الصلة مثل أن مقيدة المفاتيح الخارجية.

في ملخص, الفكرة هي تحديد القواعد في مكان واحد (قاعدة البيانات معظم الوقت) و قد رمز في طبقات أخرى من شأنها أن فرض تلك القواعد.

Answer 2

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

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

مذعورا ؟ بي ؟ لا, من ذوي الخبرة فقط.

Answer 3

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

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

Answer 4

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

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

هذا هو مورد جيد الأساسية التحقق من نقاط الضعف:

http://ha.ckers.org/xss.html

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

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

إذا كان لديك العديد من التطبيقات التفاعل مع قاعدة البيانات, ثم قد لا ترغب في تكرار والحفاظ على قواعد التحقق من الصحة عبر تطبيقات متعددة ، إذن قاعدة البيانات قد يكون أفضل مكان.

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

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