التحقق من صحة إدخال المستخدم؟

Question

أنا مرتبك للغاية بشأن شيء ما وكنت أتساءل عما إذا كان شخص ما يمكن أن يشرح.

في PHP ، التحقق من صحة إدخال المستخدم حتى htmlentitiies ، يتم استخدام mysql_real_escape_string قبل الإدراج في قاعدة البيانات ، وليس على كل شيء كما أنا أفضل استخدام التعبيرات العادية عندما أستطيع أن أجدهم يصعب العمل معهم. من الواضح الآن أنني سأستخدم mysql_real_escape_string لأن البيانات تدخل في قاعدة البيانات ولكن لست متأكدًا من أنه ينبغي أن أستخدم htmlentities () فقط عند الحصول على بيانات من قاعدة البيانات وعرضها على صفحة ويب كما تفعل ذلك قبل أن تقوم بتغيير البيانات التي يتم إدخالها من قبل شخص ما. لا يحتفظ بنموذجه الأصلي الذي قد يسبب مشاكل إذا أردت استخدام هذه البيانات لاحقًا للاستخدام لشيء آخر.

على سبيل المثال ، لديّ دفتر زوار مع 3 حقول اسم وموضوع ورسالة. من الواضح الآن أن الحقول يمكن أن تحتوي على أي شيء مثل التعليمات البرمجية الضارة في علامات JS بشكل أساسي ، والآن ما يربكني هو السماح لي أن أقول إنني شخص ضار وقررت استخدام علامات JS وبعض كود JS الخبيث وتقديم النموذج ، والآن لدي ضار في الأساس. بيانات عديمة الفائدة في قاعدة البيانات الخاصة بي. الآن باستخدام htmlentities عند إخراج الكود الخبيث إلى صفحة الويب (دفتر الزوار) التي ليست مشكلة لأن HTMLENTITITS حولتها إلى ما يعادلها آمنًا ، لكن في نفس الوقت لدي رمز ضار عديمة الفائدة في قاعدة البيانات التي لم أكن أفضلها.

لذا ، بعد قول كل هذا سؤالي هو هل يجب أن أقبل حقيقة أن بعض البيانات في قاعدة البيانات ربما تكون ضارة وعديمة الفائدة وطالما أستخدم htmlentities على الإخراج ، سيكون كل شيء على ما يرام أو هل يجب أن أفعل شيئًا آخر أيضًا؟

قرأت الكثير من الكتب التي تقول حول تصفية البيانات حول استقبالها والهروب من إخراجها ، بحيث يتم الاحتفاظ بالشكل الأصلي ولكنها تعطي أمثلة مثل ضمان حقل فقط هو فقط استخدام وظائف مدمجة بالفعل في PHP وما إلى ذلك ، لكنني لم أجد أبدًا أي شيء فيما يتعلق بضمان شيء مثل كتاب زوار حيث تريد أن يكتب المستخدمون أي شيء يريدونه ، ولكن أيضًا كيف يمكنك تصفية هذه البيانات بصرف النظر عن mysql_real_escape_string () للتأكد من عدم كسر استعلام DB؟

هل يمكن لأحد أن يغلق هذا الالتباس أخيرًا ويخبرني بما يجب أن أفعله وما هي أفضل الممارسات؟

شكرا لأي شخص يمكن أن يشرح.

هتافات!

Answer 1

هذا سؤال طويل ، لكنني أعتقد أن ما تطرحه فعليًا يتلخص في:

"هل يجب أن أهرب من HTML قبل إدخاله في قاعدة البيانات الخاصة بي ، أو عندما أذهب لعرضها؟"

الإجابة المقبولة بشكل عام على هذا السؤال هي أنه يجب عليك الهروب من HTML (عبر htmlspecialchars) عندما تذهب لعرضه للمستخدم ، و ليس قبل وضعها في قاعدة البيانات.

والسبب هو: تخزن قاعدة البيانات بيانات. ما تضعه فيه هو ما كتبه المستخدم. عندما تتصل mysql_real_escape_string, ، لا يغير ما يتم إدراجه في قاعدة البيانات ؛ إنه يتجنب فقط تفسير مدخلات المستخدم كبيانات SQL. htmlspecialchars هل نفس الشيء بالنسبة لـ HTML ؛ عند طباعة مدخلات المستخدم ، سوف يتجنب تفسيره على أنه HTML. إذا كنت ستتصل htmlspecialchars قبل الإدراج ، لم تعد مخلصًا.

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

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

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

Answer 2

mysql_real_escape_string() هو كل ما تحتاجه لعمليات قاعدة البيانات. سيضمن أنه لا يمكن للمستخدم الضار تضمين شيء ما في بيانات "سيفعل" استفساراتك.

htmlentities() و htmlspecialchars() تعال إلى اللعب عندما تعمل مع إرسال الأشياء إلى العميل/المتصفح. إذا كنت ترغب في تنظيف HTML المعادية ، فستكون أفضل حالًا في استخدامها htmlpurifier, ، والتي ستقوم بتجريد البيانات إلى الأساس وخرقها مع التبييض وإعادة بنائها بشكل صحيح.

Answer 3

لا يوجد سبب يدعو للقلق بشأن وجود رمز جافا سكريبت ضار في قاعدة البيانات إذا كنت تهرب من HTML عندما يخرج. فقط تأكد من أنك تفلت من أي شيء يخرج من ديسيبل.