متى يكون من الأفضل تعقيم مدخلات المستخدم؟

Question

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

Answer 1

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

بعد ذلك، أيًا كان ما يقرأ البيانات (غالبًا خادم) أقوم بإجراء فحص سلامة عندما أقرأ البيانات، فقط للتأكد من عدم حدوث أي شيء بسبب مستخدم أكثر تصميماً (مثل تحرير الملفات يدويًا، أو حتى تعديل الحزم !)

يحرر:بشكل عام، قم بالتعقيم مبكرًا وقم بالتعقيم في أي وقت تفقد فيه البيانات ولو لثانية واحدة (على سبيل المثال:حفظ الملف -> فتح الملف)

Answer 2

لسوء الحظ، لم يفهم أي من المشاركين تقريبًا بوضوح ما الذي يتحدثون عنه.حرفياً.فقط @Kibbee تمكن من تصحيح الأمر.

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

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

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

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

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

لذلك، من وجهة نظر الاستخدام في الحياة الواقعية، فإن الطريقة الصحيحة الوحيدة هي

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

Answer 3

أقوم بتطهير بيانات المستخدم الخاصة بي تمامًا مثل Radu ...

1. من جانب العميل الأول باستخدام كل من Regex والتحكم في إدخال الأحرف المسموح به في حقول النماذج المعطاة باستخدام JavaScript أو jQuery المرتبط بالأحداث ، مثل Onchange أو Onblur ، الذي يزيل أي مدخلات غير مسموح بها قبل تقديمها.ومع ذلك ، أدرك أن هذا ليس له تأثير فقط على السماح لهؤلاء المستخدمين بمعرفة ، أنه سيتم فحص البيانات من جانب الخادم أيضًا.إنه تحذير أكثر من أي حماية فعلية.

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

3. التالي، ولا ينبغي لي حتى أن أقول هذا، ولكن دائمًا، وأعني دائماً, ، قم بتشغيل البرامج النصية الخاصة بك في وضع taint.هذا يجبرك على عدم الحصول على كسول ، وأن تكون مجتهدًا بشأن الخطوة رقم 4.

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

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

5. أخيرًا ، هو تصفية جميع المحاولات التلقائية للروبوتات هذه الأيام ، مع نظام "المصادقة البشرية" ، مثل Captcha.هذا أمر مهم بما فيه الكفاية في هذه الأيام التي أخذت فيها الوقت الكافي لكتابة مخطط "المصادقة الإنسانية" الخاصة بي الذي يستخدم الصور ومدخلات "الإنسان" لإدخال ما يرونه في الصورة.لقد فعلت ذلك لأنني وجدت أن أنظمة Captcha Type تزعج المستخدمين حقًا (يمكنك أن تقول من خلال عيونهم المغطاة من محاولة فك الحروف المشوهة ...عادة مرارا وتكرارا).هذا مهم بشكل خاص للبرامج النصية التي تستخدم إما SendMail أو SMTP للبريد الإلكتروني ، لأن هذه هي المفضلة لبروتكول الرسائل غير المرغوب فيها الجائعة.

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

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

أو باختصار، كما تقول أمي في كثير من الأحيان..."أفضل آمنة من آسف".

تحديث:

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

Answer 4

يعتمد ذلك على نوع التعقيم الذي تقوم به.

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

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

Answer 5

الشيء الأكثر أهمية هو أن تكون ثابتًا دائمًا عند الهروب.التعقيم المزدوج العرضي أمر ضعيف وعدم التعقيم خطير.

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

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

Answer 6

المبكر أمر جيد، بالتأكيد قبل أن تحاول تحليله.يجب تطهير أي شيء ستخرجه لاحقًا، أو ستنقله بشكل خاص إلى مكونات أخرى (مثل shell وSQL وما إلى ذلك).

ولكن لا تبالغ في ذلك - على سبيل المثال، تتم تجزئة كلمات المرور قبل تخزينها (أليس كذلك؟).يمكن لوظائف التجزئة قبول البيانات الثنائية التعسفية.ولن تقوم أبدًا بطباعة كلمة المرور (أليس كذلك؟).لذا، لا تقم بتحليل كلمات المرور، ولا تقوم بتطهيرها.

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

Answer 7

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

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

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

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

Answer 8

رأيي هو تعقيم مدخلات المستخدم في أقرب وقت ممكن من جانب العميل والخادم، وأنا أفعل ذلك على هذا النحو

1. (جانب العميل) ، اسمح للمستخدم بإدخال مفاتيح محددة فقط في الحقل.
2. (جانب العميل) ، عندما يذهب المستخدم إلى الحقل التالي باستخدام Onblur ، اختبر الإدخال الذي أدخله مقابل regexp ، ولاحظ المستخدم إذا لم يكن هناك شيء جيد.
3. (جانب الخادم) ، اختبر الإدخال مرة أخرى ، إذا كان يجب أن يكون الحقل صحيحًا ، فاحصل مجرد الهروب منهم.إذا كان هناك أي شيء مريب، قم بإيقاف تنفيذ البرنامج النصي وإرجاع إشعار إلى المستخدم بأن البيانات التي أدخلها غير صالحة.

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

Answer 9

تنظيف البيانات قبل تخزينها.بشكل عام، لا يجب أن تقوم بالتحضير أي إجراءات SQL دون تنظيف الإدخال أولاً.لا تريد تعريض نفسك لهجوم حقن SQL.

أنا نوع من اتباع هذه القواعد الأساسية.

1. قم فقط بتعديل إجراءات SQL، مثل INSERT وUPDATE وDELETE من خلال POST.لا تحصل أبدا.
2. الهروب من كل شيء.
3. إذا كنت تتوقع أن يكون إدخال المستخدم شيئًا ما، فتأكد من التحقق من أنه شيء ما.على سبيل المثال، أنت تطلب رقمًا، ثم تأكد من أنه رقم.استخدام عمليات التحقق من الصحة.
4. استخدم المرشحات.تنظيف الشخصيات غير المرغوب فيها.

Answer 10

المستخدمين أشرار!

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

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

Answer 11

افترض أن جميع المستخدمين ضارون.تطهير كافة المدخلات في أقرب وقت ممكن.نقطة.

Answer 12

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

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

من المؤكد أن هذا يتطلب الكثير من العمل مقدمًا، ولكن إذا كانت البيانات مهمة، فهذا استثمار جدير بالاهتمام.

Answer 13

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

Answer 14

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