كيفية ضمان تحميل HTTP جاء من Authentic execution

Question

نحن بصدد كتابة تطبيق Windows الأصلي (MFC) الذي سيقوم بتحميل بعض البيانات على تطبيق الويب الخاص بنا. سيسمح تطبيق Windows للمستخدم بتسجيل الدخول وبعد ذلك سيتم تحميل بعض البيانات بشكل دوري إلى تطبيق الويب الخاص بنا. سيتم التحميل عبر Post Simple HTTP لتطبيق الويب الخاص بنا. القلق الذي أواجهه هو كيف يمكننا التأكد من أن التحميل جاء فعليًا من تطبيقنا ، وليس من حليقة أو شيء من هذا القبيل. أعتقد أننا نبحث في نوع من التشفير الرئيسي/الخاص هنا. لكنني لست متأكدًا مما إذا كان بإمكاننا بطريقة ما تضمين مفتاح عام في تطبيق WIN APP القابل للتنفيذ ويتم القيام به. أم أن هذا المفتاح العام سيكون سهل الاستخراج واستخدامه خارج تطبيقنا؟

على أي حال ، نحن نبني كلا الجانبين (العميل والخادم) إلى حد كبير أي شيء هو خيار ، ولكن يجب أن يعمل من خلال HTTP (s). ومع ذلك ، فإننا لا نتحكم في تطبيق تنفيذ تطبيق Win (Client) ، بالإضافة إلى أن المستخدم الذي يقوم بتطبيق التطبيق على نظامه/نظامه هو الوحيد الذي يحصل على شيء من خلال ألعاب النظام.

Answer 1

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

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

Answer 2

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

لكنني لست متأكدًا مما إذا كان بإمكاننا بطريقة ما تضمين مفتاح عام في تطبيق WIN APP القابل للتنفيذ ويتم القيام به.

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

أو هل سيكون من السهل جدًا استخراجها واستخدامها خارج تطبيقنا؟

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

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

Answer 3

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

من المؤكد أن نظامًا معقدًا يربط مفتاحًا بعنوان MAC لجهاز كمبيوتر على سبيل المثال.

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

Answer 4

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

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