الأمان مع قيم QueryString في ASP.NET MVC

Question

كيف يمكنك التأكد بشكل صحيح من أن المستخدم لا يتلاعب بقيم QueryString أو قيم URL الإجراء؟ على سبيل المثال ، قد يكون لديك إجراء تعليق حذف على CommentController الذي يأخذ CommentId. قد يبدو عنوان URL الإجراء/تعليقات/حذف/3 لحذف التعليق مع المعرف 3.

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

هل تقوم بإجراء مكالمات قاعدة بيانات متعددة لاسترداد التعليق وتحقق من أن مؤلف التعليق يطابق المستخدم الذي يستدعي إجراء الحذف؟

هل تقوم بدلاً من ذلك بتمرير CommentId و UserId إلى الإجراء المخزن الذي يقوم بالحذف والقيام بحذف حيث يساوي userId و commentID القيم التي تم تمريرها؟

هل من الأفضل تشفير قيم سلسلة الاستعلام؟

Answer 1

لم تكن.

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

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

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

Answer 2

تعتبر معاملات الاستعلام enrypting وفك التشفير عملية تافهة وهناك بعض الأمثلة الرائعة على كيفية القيام بذلك باستخدام httpmodule هنا على stackoverflow.

"أنت لا" ، "لا يمكنك" ، أو "ليس من السهل" ببساطة استجابات مقبولة في هذا اليوم وهذا العصر ...

Answer 3

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

Answer 4

فكر في استخدام التقنية الموضحة في مقالة ستيفن والتر نصيحة رقم 46 - لا تستخدم روابط الحذف لأنها تخلق ثقوب أمان الذي يستخدم [accountVerbs (httpverbs.delete)

Answer 5

يمكنك أيضًا السماح فقط بطلبات البريد لحذف إجراء وحدة التحكم باستخدام سمة ACTIVE AVER كما هو موضح أدناه.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Delete(int? id)
{
    //Delete
}

بعد ذلك ، يمكنك أيضًا استخدام رمز مضاد للأوراق كما هو موضح هنا:

http://blog.codeville.net/2008/09/01/prevent-cross-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 6

لقد قمت بأشياء غير تقليدية تأخذ QueryString ، أو ضغطها ، أو Base64 أو فقط ترميزها ، بحيث يصبح "CommentId = 4 & userId = 12345" "رمزًا = 1A2B23DE12769"

إنه في الأساس "الأمن من خلال الغموض" ، لكنه يجعل الكثير من العمل لشخص يحاول اختراق الموقع.

Answer 7

لا يمكنك القيام بذلك بسهولة.

لديّ ذكريات رائعة لموقع استخدم عناوين URL لإجراء الحذف.

كان كل شيء على ما يرام حتى بدأوا البحث في زحف الإنترانت.

Ooops ، وداعا بيانات.

أود أن أوصي بحل لا تستخدم فيه QueryStrings لأي شيء لا ترغب في تحريره.