تشفير/obfuscate معلمات HTTP

Question

نحن نعمل حاليًا على شبكة ويب بسيطة للغاية ، ونود ذلك "obfuscate" (ماذا سيكون المصطلح الصحيح؟) أو تشفير معلمة الطلب بطريقة أو بأخرى ، حتى نتمكن من تقليل فرصة مستخدم الخمول من إرسال بيانات تعسفية.

على سبيل المثال ، يبدو عنوان URL /webapp?user=Oscar&count=3

نود أن يكون هناك شيء مثل: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT ولوح هذه القيمة فك تشفيرها في الخادم مع معلومات الطلب الحقيقي.

قبل الذهاب إلى تنفيذ شيء مثل هذا بأنفسنا (وربما نفعله خطأ) أود أن أعرف ما إذا كان هناك شيء للقيام بذلك بالفعل؟

لدينا Java على الخادم و JavaScript على العميل.

Answer 1

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

تحرير التوسع

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

لا يمنع استخدام SSL العميل من العبث بالبيانات ، لكنه يمنع رجال الوسط من الرؤية أو العبث به. كما أنه يرشد المتصفحات المحفورة برفاهية بعدم تخزين البيانات الحساسة في تاريخ عنوان URL.

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

لذلك ، لإنهاءها:

1. الأمن عن طريق التشويش ليس الأمن على الإطلاق.
2. لا يمكنك الوثوق ببيانات المستخدم ، حتى لو كانت محجوبة.التحقق من صحة بياناتك.
3. يساعد استخدام قنوات الاتصال الآمنة (SSL) على منع التهديدات الأخرى ذات الصلة.
4. يجب أن تتخلى عن نهجك وتفعل الشيء الصحيح. الشيء الصحيح ، في حالتك ، ربما يعني إضافة آلية مصادقة مع نظام امتياز لمنع المستخدمين من الوصول إلى الأشياء التي لا يتمتعون بامتيازها بما يكفي لرؤيتها - بما في ذلك الأشياء التي قد يحاولون الوصول إليها عن طريق العبث باستخدام معلمات الحصول على. إجابة غاري آر, ، وكذلك تعليق ديف وويل ويل هذا واحد على رأسه.

Answer 2

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

SALT = "so9dnfi3i21nwpsodjf";

function computeUrl(url) {
  return url + "&hash=" + md5(url + SALT );
}

function checkUrl(url) {
  hash = /&hash=(.+)/.match(url);
  oldUrl = url.strip(/&hash=.+/);
  return md5(oldUrl + SALT ) == hash;
}

Answer 3

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

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

القاعدة الذهبية هنا هي عدم السماح بكل شيء ، باستثناء الأشياء التي تعرفها آمنة.

Answer 4

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

ثم يمكنك فقط:

http://example.com/service?x=123&y=Bob&sig=ABCD1324

تكشف هذه التقنية البيانات (أي يمكنهم "رؤية" أن XYZ = 123) ، لكنهم لا يستطيعون تغيير البيانات.

هناك ميزة "التشفير" (وأنا أستخدم هذا المصطلح بشكل فضفاض). هذا هو المكان الذي تقوم فيه بتشفير قسم المعلمة بأكمله من عنوان URL.

هنا يمكنك أن تفعل شيئًا مثل:

http://example.com/service?data=ABC1235ABC

الشيء الجميل في استخدام التشفير هو اثنين.

واحد يحمي البيانات (لا يمكن للمستخدم رؤية أن XYZ = 123 ، على سبيل المثال).

الميزة الأخرى هي أنه قابل للتمديد:

http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc

هنا ، يمكنك فك تشفير الحمولة الأصلية ، والقيام بدمج (آمنة) مع البيانات الجديدة.

لذلك ، يمكن للطلبات إضافة بيانات إلى الطلب ، فقط لا تغيير البيانات الموجودة.

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

من الواضح أنك لا تريد القيام بأي من هذا على العميل. ليس هناك داعي. إذا تمكنت من القيام بذلك ، "يمكنهم" القيام بذلك ولا يمكنك معرفة الفرق ، لذلك قد لا تفعل ذلك على الإطلاق - إلا إذا كنت تريد "تشفير" البيانات على منفذ HTTP العادي (مقابل TLS ، ولكن بعد ذلك سوف يتساءل الناس بحكمة "لماذا عناء").

بالنسبة لجافا ، كل هذا العمل يذهب في مرشح ، هذه هي الطريقة التي فعلت بها. يتم عزل النهاية الخلفية عن هذا.

إذا كنت ترغب في ذلك ، يمكنك جعل النهاية الخلفية معزولة تمامًا عن هذا مع مرشح خارجي يتولى تشفير URL/التوقيع في طريقه للخروج.

هذا أيضًا ما فعلته.

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

الجانب المشرق هو كل جانب المحتوى "فقط يعمل" ، لأنهم لا يعرفون أي شيء عنه.

هناك أيضًا بعض التعاملات الخاصة عند التعامل مع JavaScript (حيث أن المرشح لن يعرف بسهولة حيث يوجد عنوان URL للتشفير). لقد قمت بحل هذا عن طريق طلب توقيع عناوين URL ليكون محددًا "var signedurl = '....'" ، حتى أتمكن من العثور على تلك بسهولة في الإخراج. ليس سحق عبء على المصممين كما قد تعتقد.

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

الألم للقيام به ، لكنه لطيف بشكل عام في النهاية.

Answer 5

شيء مثل jcryption؟

http://www.jcryption.org/examples/

Answer 6

يمكنك تشفير البيانات باستخدام BASE64 أو شيء مشابه. أود أن أشفر الحجج Inself في JSON لتسلسلها.