أمان تطبيق العميل: نصائح عملية لمطور الواجهة الأمامية

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

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

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

في عام 2001 ، أسس Mark Curfy و Dennis Groves مشروع OWASP (مشروع أمان تطبيق الويب المفتوح). هذا هو مشروع مفتوح المصدر دولي لتبادل الخبرات في مجال مكافحة الثغرات الأمنية في تطبيقات العميل ، حيث يشارك عدد كبير من مهندسي أمن التطبيقات. يملأ مجتمع OWASP المدخل بالعديد من المقالات التي تحتوي على معلومات عن الثغرات ، ومواد التدريب ، وأدوات اختبار الهجمات والصد. يتم وصف الهجمات الحقيقية ، يتم الكشف عن جوانبها وما يجب القيام به لمنع التهديدات.

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

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

بوابة

أولاً ، دعنا نتحدث عن البيانات الحساسة في Git. من الناحية المثالية ، يتم تخصيص مستودع منفصل للأسرار لتخزين البيانات الحساسة. منه ، أثناء التجميع للتكليف ، يتم سحب البيانات السرية للأعلى ومخيطها في التطبيق. اليوم ، تحظى أسرار Hashicorp Vault و Keywhiz و Docker و Azure Key Vault وعدد من الآخرين بشعبية كبيرة.

ولكن ماذا لو لم يكن لديك مثل هذا التخزين؟ يمكنك استخدام الأدوات لتشفير وإخفاء الملفات باستخدام أسرار من شأنها أن تزيد من قدرات أنظمة التحكم في الإصدار.

أول ما يتبادر إلى الذهن هو حل BlackBox العالمي. يمكن استخدامه مع أي نظام للتحكم في الإصدار ، على سبيل المثال ، Mercurial ، Git ، إلخ. بالإضافة إلى ذلك ، هناك امتدادان لـ Git: git-crypt و git-secret. أوصي باستخدام الثانية ، لأنه بدا لي أكثر ملائمة للاستخدام وأكثر قابلية للفهم من حيث الوصف في الوثائق الرسمية. بعد تثبيت git-secret ، ستحتاج إلى تهيئته في مستودع Git. تذكر أن تحدد الامتداد المراد استخدامه في ملف .gitattributes . بعد ذلك ، قم بتكوين إمكانية الوصول إلى الأسرار: حدد المستخدمين الذين تريد توفير الوصول إلى البيانات الحساسة لهم. ثم قم بإضافة الملفات مع البيانات الحساسة git-secret-hide خلال git-secret-hide . يمكنك الحصول على الملفات المخفية من خلال git-secret-reveal.

Webpack

هناك طريقة أخرى للقضاء على التهديدات وهي تكوين webpack بشكل صحيح. للحماية من XSS و XEE والهجمات المماثلة ، يجب مراعاة الالتزام بسياسات CORS (مشاركة الموارد المشتركة) و CSP (سياسة أمان المحتوى). في كلتا الحالتين ، من المهم اتباع الرؤوس من أجل التحقق من دقة بعض البرامج النصية المستخدمة في المشروع. لدى المتصفحات آليات للتحقق من موثوقية مصدر معين ، على سبيل المثال ، ستصدر Safari تحذيرات في كل خطوة إذا تم تكوين CORS و CSP بشكل غير صحيح.

هناك طريقتان للامتثال لـ CORS و CSP. الأول هو تكوين رؤوس الاستجابة في النهاية الخلفية. والثاني هو تسجيل كل السياسات من خلال العلامات الوصفية والسمات. يوصى باستخدام الطريقة الأخيرة إذا كان لديك مطورون ذوو كسول ، فهم مشغولون دائمًا وغير مهتمين بسياسات الأمان. يمكن تسجيل العلامات الوصفية فور إنشاء التطبيق. الإضافات مثل html-webpack-plugin ، و html-webpack-exclude-stocks-plugin ، script-ext-html-webpack-plugin ، و csp-html-webpack-plugin و crypto ستساعدنا في هذا. بالإضافة إلى ذلك ، إذا كان لديك موارد لجهة خارجية في مشروعك (على سبيل المثال ، روابط لخطوط خارجية مستخدمة في CSS ؛ موارد محملة من CDN ، وما إلى ذلك) ، أوصي باستخدام webpack-subresource-integrity-plugin أيضًا. وبالتالي ، سوف تقوم بإعلام المستعرض بأن الموارد المحملة في البرنامج النصي موثوق بها ، ولا توجد فيها حقن ، فهي كاملة وغير ملوثة. وحتى إذا قام شخص ما بحقن بيانات ضارة في المورد ، وقمت بتحميلها ، فيجب أن تكون مستعدًا لذلك وحماية مشروعك من مثل هذه التهديدات.

أريد أن أولي اهتمامًا خاصًا للترتيب الذي يتم به إنشاء مثيلات الفئة للإضافات. يجب أن يكون الترتيب مثل هذا:

 const SHA256 = (str) => CRYPTO.createHash('sha256').update( str, 'utf8').digest('base64'); const sha256Str = SHA256( '' + Date.now() ); […] new HtmlWebpackPlugin({   filename: 'index.html',   template: 'public/index.html' }), new ScriptExtHtmlWebpackPlugin({    custom: [{           test: /\.js$/,           attribute: 'nonce',           value: 'nonce-' + sha256Str    }] }), new HtmlWebpackExcludeAssetsPlugin(), new CspHtmlWebpackPlugin({    'base-uri': '\'self\'',    'object-src': '\'none\'',    'script-src': ['\'self\'', '\'unsafe-eval\'', '\'nonce-' + sha256Str + '\''],    'style-src': ['\'unsafe-inline\'', '\'self\''] }, {    devAllowUnsafe: false,    enabled: true,    hashingMethod: 'sha256' }), new SriPlugin({    hashFuncNames: ['sha256', 'sha384'],    enabled: true }), […] 

بعد ذلك ، أثناء التجميع ، ستعرض <hed> الوصفية http-equiv=content-security-policy . سيتم كتابة التوجيهات في سمة content ، والتي توضح البرامج النصية والموارد التي يمكن الوثوق بها.

يُظهر توجيه القاعدة الأساسية عنوان URL الأساسي الذي يتم استخدامه لتحميل البرامج النصية و CSS والصور وأكثر من ذلك.

عادةً لا يتم تحميل الكائنات ، لذلك none تضبط none على الأمر object-sr c.

ينطبق توجيه script-src على البرامج النصية JS.

لا تنسَ تسجيل سمة من النوع nnce-<hshVlue> كل مرة. علاوة على ذلك ، يجب حساب التجزئة باستخدام خوارزمية SHA256 أو SHA512.

بالنسبة لتوجيهات style-src ، يتميز مشروعنا بخصوصية: نستخدم المكونات المصممة لكتابة CSS لكل مكون وعزلهم عن بعضهم البعض. وبالتالي ، من الضروري تحديد أنه فينا يتم استخدام style-src unsafe-inline في style-src ، وإلا فإن المكونات المصممة سوف تسقط.

سيتم تعيين علامة script تلقائيًا على رقم nnce-<hshVlue> integrity cross-origin . يخبرون المتصفح أنه يتم سحب الموارد من مصادر موثوقة. وإلا ، إذا رأى المستعرض أن المورد لا يتطابق مع CSP أو CORS ، فلن يقوم بتحميل هذا البرنامج النصي أو ملف CSS فقط ، وسيكتب شيئًا في وحدة التحكم مثل: "انتبه إلى هذا البرنامج النصي ، إلى هذا السطر حيث يمكنك التهيئة ذلك. انظروا ، لديك شيء خاطئ! " .

توفر وثائق MDN و OWASP و W3C إرشادات لتطبيق سياسات CSP و CORS. بالإضافة إلى ذلك ، فإن أي أدوات لاختبار الاختراق سوف تبلغ عن الامتثال لقواعد CORS و CSP في المشروع. أي إطار أو أداة من شأنها إجراء اختبار تلقائي للمشروع سوف يشير إلى وجود عيوب.

مصادقة المستخدم

نحن نستخدم OpenID Connect وبروتوكول Kerberos. يتم استخدام معيار OpenID شائع إلى حد ما لمصادقة المستخدمين الخارجيين.

Kerberos هو أكثر ملاءمة للشبكة الداخلية ، في البنك يتم استخدامه للمصادقة التلقائية للموظفين. لنفترض أن هناك آلة محلية يعمل عليها موظف في المنظمة. لقد قام بالتصديق مرة واحدة على هذا الجهاز ، ومن ثم لن يحتاج إلى إدخال تسجيل الدخول وكلمة المرور مرة أخرى في أي مكان: يقوم الموظف بتسجيل الدخول إلى أي تطبيق ويقوم النظام بالتصديق على الفور. يحتوي Kerberos على إعدادات دقيقة للجهاز المحلي ، وهذا أمر صعب لأنه يجب تكوينه لكل كمبيوتر وكل مستعرض. إذا قام Internet Explorer عادةً بسحب الإعدادات الافتراضية ، وسحب Chrome إعدادات IE ، فيجب على Firefox تكوينها بشكل منفصل. سيجد Safari على MacOS X الإعدادات نفسها ، لكن بالنسبة إلى Safari على Windows ، ستحتاج إلى تحديدها يدويًا.

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

يمكن تنفيذ المصادقة في التطبيقات الحديثة باستخدام Passport.js وحزم جلسات العمل السريعة ، وكذلك Auth0 SDK.

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

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

كلمة السر البعثرة

يوصي موقع OWASP بعدم استخدام آليات تجزئة كلمة المرور المضمنة في قاعدة البيانات. لهذا ، من الأفضل استخدام حزم مثل Argon2 و PBKDF2 و ccrypt و bcrypt. في ممارستي ، أستخدم Argon2 - وهذا عبارة عن غلاف لخوارزميات GCC و PGP / GPG ، وما إلى ذلك ، لكنه يتطلب منك أولاً تثبيت حزمة GCC. نظام الاستخدام Argon2:

 1.  GCC >= 4.8 install $ brew install gcc 

 2.     - $ npm install -g node-gyp 

 3.   Argon2 $ npm install argon2 

 4.   import * as ARGON from 'argon2'; ARGON.generateSalt().then( (salt: string) => {  ARGON.hash('some-user-password', salt)    .then((hash : string) => {       console.log('Successfully created Argon2 hash:', hash);       // TODO: store the hash in the user database  }); }); argon2.verify( 'previously-created-argon-hash-here', 'some-user-password').then(() => {  console.log('Successful password supplied!');  // TODO: log the user in }).catch(() => {  console.log('Invalid password supplied!'); }); -here، 4.   import * as ARGON from 'argon2'; ARGON.generateSalt().then( (salt: string) => {  ARGON.hash('some-user-password', salt)    .then((hash : string) => {       console.log('Successfully created Argon2 hash:', hash);       // TODO: store the hash in the user database  }); }); argon2.verify( 'previously-created-argon-hash-here', 'some-user-password').then(() => {  console.log('Successful password supplied!');  // TODO: log the user in }).catch(() => {  console.log('Invalid password supplied!'); }); 

التشويش

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

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

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

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

تسجيل التهديدات والمراقبة

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

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

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

• بعد تثبيت npm i snyk —D التبعية وتحديد "snyk": صحيح في package.json ، قم بتشغيل:

 ./node_modules/.bin/snyk wizard --dev 

• في package.json إضافة البرامج النصية والإعدادات:

 { ... "scripts": {  ...  "test": "npm run test:snyk && npm run test:jest",  ...  "test:snyk": "snyk test --dev",  ...  "prepare": "npm run prepare:snyk",  "prepare:snyk": "snyk protect" }, "husky": {  "hooks": {   "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",   "pre-commit": "npm run test:snyk && npm run lint && npm run test:jest",   "pre-push": [    "npm run test:snyk",    "npm run lint",    "npm run test:jest",    "npm run build:production"   ],   ...  } }, "snyk": true } 

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

مراقبة التطبيق

في مجال الواجهة الأمامية ، أصبحت الأدوات راسخة بالفعل ؛ تتوفر أدوات لكل الأذواق لتسجيل ومراقبة جزء العميل. الأكثر شهرة هي ترقب ، TrackJS ، و InsightOps. خادم ترقب يمكن نشرها على الخوادم المادية. على سبيل المثال ، في مشروعينا استخدمنا خادمًا منفصلاً ، تم تكوينه بالكامل لتسجيل تشغيل التطبيقات. ذهبنا إلى URL وإسقاط جميع السجلات هناك. في حالة حدوث خطأ في التطبيق ، يتم لفه في كتلة try catch وإرساله إلى خادم Sentry عبر أساليب حزمة الغراب. كل شيء بسيط ومريح. إذا رأيت عناوين URL غامضة في Sentry لم تسجّلها ، وإذا رأيت زخارف أو رسائل غامضة ، فإنهم يحاولون اختراقك. في ممارستي ، حدث هذا بانتظام. على سبيل المثال ، كان أحد المشروعات - خدمة لتجاوز حاصرات الإعلانات ومضادات الفيروسات - يحاول باستمرار التصدي له ، وقم بالقضاء عليه.

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

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

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

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

قائمة بمصادر القراءة حول الموضوع:

www.owasp.org/index.php/Main_Page

tproger.ru/translations/webapp-security

صقور. حتى أسرع تطبيق صفحة واحدة: الأمن

Seacord، Robert C. The CERT C secure coding standard / Robert C. Seacord. - 2008

تشيتان كاراندي. تأمين تطبيقات العقدة - 2017

ستيفن بالمر. كشف مواطن الضعف في تطبيق الويب ، استغلال ، منع - 2011

روبرت شيمونسكي ، شون فيليب أوريانو. الهجمات من جانب العميل والدفاع - 2012

ماركوس بينتو ، دافيد شتوتارد. كتيب هاكر تطبيق الويب: العثور على العيوب الأمنية واستغلالها ، الإصدار الثاني - 2011

كارل دونا. تأمين تطبيق الويب Node.js - 2015