الإخراج أو تصفية الإدخال؟

Question

الإخراج أو تصفية الإدخال؟

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

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

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

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

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

يتم تصفية البيانات الآن اعتمادًا على السياق ، على سبيل المثال ، يمكنني الحصول على البيانات من قاعدة البيانات المقدمة في مستند HTML كنص مُحسّن عاديًا ، أو كـ HTML أو أي شيء في أي مكان.

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

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

لذا ، بدلاً من الذهاب مع "تصفية مدخلاتك" ، ربما يجب أن يكون "التحقق من صحة المدخلات الخاصة بك ، وتصفية المخرجات الخاصة بك".

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

Answer 1

لا يوجد "تصفية" عام للإدخال والمخرجات.

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

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

يعد الهروب مسألة سياق ، ومن المنطقي حقًا عندما تقوم بشيء مع البيانات التي يمكن تسممها عن طريق حقن شخصيات معينة. الهروب من أحرف HTML في البيانات التي ترسلها إلى المتصفح. الهروب من أحرف SQL في البيانات التي ترسلها إلى قاعدة البيانات. اقتباسات الهروب عندما تكتب البيانات داخل JavaScript <script> العلامات. فقط كن على دراية بكيفية تفسير البيانات التي تتعامل معها من قبل النظام الذي تمرره إليه والهروب وفقًا لذلك.

Answer 2

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

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

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

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

Answer 3

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

يطلب إجراء تصفية الإخراج بدلاً من تصفية الإدخال حقن SQL.