ASP.NET Core + SPA में JWT का आदान-प्रदान करने का सुरक्षित तरीका

प्रविष्टि

JWT प्रमाणीकरण (JSON वेब टोकन) सर्वर और क्लाइंट के बीच एक समान वर्दी, सुसंगत प्रमाणीकरण और प्रमाणीकरण तंत्र है। JWT का लाभ यह है कि यह हमें राज्य को कम प्रबंधित करने की अनुमति देता है और अच्छी तरह से मापता है। यह आश्चर्य की बात नहीं है कि इसकी मदद से प्राधिकरण और प्रमाणीकरण आधुनिक वेब अनुप्रयोगों में तेजी से उपयोग किया जाता है।

JWT के साथ एप्लिकेशन विकसित करते समय, अक्सर यह सवाल उठता है: टोकन को स्टोर करने की अनुशंसा कहां और कैसे की जाती है? यदि हम एक वेब एप्लिकेशन विकसित कर रहे हैं, तो हमारे पास दो सबसे आम विकल्प हैं:

• HTML5 वेब संग्रहण (लोकलस्टोरेज या सेशनस्टोरेज)
  
• कुकीज़
  

इन विधियों की तुलना करते हुए, हम कह सकते हैं कि वे दोनों क्लाइंट के ब्राउज़र में मूल्यों को संग्रहीत करते हैं, दोनों ही कुंजी-मूल्य वाले जोड़े के नियमित भंडारण का उपयोग करने और उनका प्रतिनिधित्व करने में काफी आसान हैं। अंतर भंडारण वातावरण में है।

वेब संग्रहण (लोकलस्टोरेज / सेशनस्टोरेज) उसी डोमेन में जावास्क्रिप्ट के माध्यम से सुलभ है। इसका मतलब यह है कि आपके एप्लिकेशन के किसी भी जावास्क्रिप्ट कोड का उपयोग वेब स्टोरेज तक है, और यह क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों के लिए भेद्यता बनाता है। स्टोरेज इंजन के रूप में, वेब स्टोरेज स्टोरेज और शेयरिंग के दौरान आपके डेटा को सुरक्षित करने का कोई तरीका नहीं देता है। हम इसका उपयोग केवल उस सहायक डेटा के लिए कर सकते हैं जिसे हम अपडेट (F5) या टैब को बंद करते समय रखना चाहते हैं: स्थिति और पृष्ठ संख्या, फ़िल्टर आदि।

टोकन को ब्राउज़र कुकीज़ के माध्यम से भी प्रेषित किया जा सकता है। HttpOnly ध्वज के साथ उपयोग किए जाने वाले कुकीज़ XSS प्रभावित नहीं हैं । httpOnly केवल सर्वर पर कुकीज़ को पढ़ने, लिखने और हटाने के लिए एक ध्वज है। वे क्लाइंट पर जावास्क्रिप्ट के माध्यम से सुलभ नहीं होंगे, इसलिए क्लाइंट को टोकन के बारे में नहीं पता होगा, और सर्वर साइड पर प्राधिकरण पूरी तरह से संसाधित होगा।

हम यह सुनिश्चित करने के लिए एक सुरक्षित ध्वज भी सेट कर सकते हैं कि कुकीज़ केवल HTTPS के माध्यम से प्रेषित हों। इन फायदों को देखते हुए, मेरी पसंद कुकीज़ पर गिर गई।

यह लेख एसपीए के साथ संयोजन में ASP.NET कोर वेब एप में httpOnly सुरक्षित कुकीज़ + JSON वेब टोकन का उपयोग करके प्रमाणीकरण और प्रमाणीकरण को लागू करने के दृष्टिकोण का वर्णन करता है। विकल्प पर विचार किया जाता है जिसमें सर्वर और क्लाइंट अलग-अलग मूल में होते हैं।

अपने स्थानीय विकास पर्यावरण की स्थापना

HTTPS के माध्यम से क्लाइंट-सर्वर रिश्तों को सही ढंग से कॉन्फ़िगर और डीबग करने के लिए, मैं दृढ़ता से अनुशंसा करता हूं कि आप तुरंत स्थानीय विकास वातावरण को कॉन्फ़िगर करें ताकि क्लाइंट और सर्वर दोनों में HTTPS कनेक्शन हो।

यदि आप इसे सही तरीके से नहीं करते हैं और HTTPS कनेक्शन के बिना संबंध बनाने का प्रयास करते हैं, तो भविष्य में कई शानदार विवरण सामने आएंगे, जिसके बिना HTTPS के साथ उत्पादन में सुरक्षित कुकीज़ और अतिरिक्त सुरक्षित-नीतियां सही तरीके से काम नहीं करेंगी।

मैं ओएस विंडोज 10, सर्वर - एएसपी.नेट कोर, एसपीए - रिएक्ट पर एचटीटीपीएस को कॉन्फ़िगर करने का एक उदाहरण दिखाऊंगा।

आप प्रोजेक्ट बनाते समय HTTPS ध्वज के लिए कॉन्फ़िगर का उपयोग करके ASP.NET Core में HTTPS को कॉन्फ़िगर कर सकते हैं या यदि हम इसे बनाते समय ऐसा नहीं करते हैं, तो गुण में संगत विकल्प को सक्षम करें।

एसपीए को कॉन्फ़िगर करने के लिए, आपको "स्टार्ट" सेट करने के लिए स्क्रिप्ट को " HTTPS = true" पर संशोधित करना होगा। मेरा सेटअप इस प्रकार है:

'start': 'set HTTPS=true&&rimraf ./build&&react-scripts start' 

मैं आपको अन्य वातावरणों में विकास के माहौल के लिए HTTPS बनाने के लिए बनाने की सलाह देता हूं- create-react-app.dev/docs/use-https-in-development

ASP.NET कोर सर्वर को कॉन्फ़िगर करें

JWT सेटअप

इस मामले में, प्रलेखन से या किसी भी लेख से जेडब्ल्यूटी का सबसे आम कार्यान्वयन, अतिरिक्त सेटिंग्स options.RequireHttpsMetadata = true; साथ options.RequireHttpsMetadata = true; हमारे विकास का वातावरण HTTPS का उपयोग करता है:

ConfigureServices

 services.AddAuthentication(options => { options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultSignInScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options => { options.RequireHttpsMetadata = true; options.SaveToken = true; options.TokenValidationParameters = new TokenValidationParameters { //  .  }; }); 

एक CORS नीति को कॉन्फ़िगर करना

महत्वपूर्ण : AllowCredentials() नीति में AllowCredentials() होना चाहिए। XMLHttpRequest.withCredentials से अनुरोध प्राप्त करने और क्लाइंट को कुकी वापस भेजने के लिए यह आवश्यक है। इस पर और बाद में लिखा जाएगा। अन्य विकल्प परियोजना की जरूरतों के आधार पर कॉन्फ़िगर किए गए हैं।

यदि सर्वर और क्लाइंट एक ही मूल पर हैं, तो नीचे संपूर्ण कॉन्फ़िगरेशन की आवश्यकता नहीं है।

ConfigureServices

 services.AddCors(); 

कॉन्फ़िगर

 app.UseCors(x => x .WithOrigins("https://localhost:3000") //    SPA  .AllowCredentials() .AllowAnyMethod() .AllowAnyHeader()); 

कुकी नीति की स्थापना

सेना की नीति को httpOnly और सुरक्षित करने के लिए।

यदि संभव हो, तो MinimumSameSitePolicy = SameSiteMode.Strict; सेट MinimumSameSitePolicy = SameSiteMode.Strict; - यह एप्लिकेशन प्रकारों के लिए कुकी सुरक्षा में सुधार करता है जो क्रॉस-ऑरिजिनल अनुरोध प्रसंस्करण पर निर्भर नहीं होते हैं।

कॉन्फ़िगर

 app.UseCookiePolicy(new CookiePolicyOptions { MinimumSameSitePolicy = SameSiteMode.Strict, HttpOnly = HttpOnlyPolicy.Always, Secure = CookieSecurePolicy.Always }); 

सुरक्षित टोकन विनिमय का विचार

यह हिस्सा एक अवधारणा है। हम दो काम करने जा रहे हैं:

1. HTTPOnly और सुरक्षित झंडे का उपयोग करके HTTP अनुरोध में टोकन टॉस करें।
2. एक HTTP अनुरोध से क्लाइंट एप्लिकेशन प्राप्त करें और उसे सत्यापित करें।

ऐसा करने के लिए, हमें चाहिए:

• लॉग इन करते समय httpOnly कुकी में टोकन लिखें और लॉग इन करते समय इसे वहां से हटा दें।
• यदि कुकीज़ में एक टोकन है, तो प्रत्येक बाद के अनुरोध के HTTP हेडर में टोकन को प्रतिस्थापित करें।
• यदि कुकीज़ में कोई टोकन नहीं है, तो हेडर खाली होगा, और अनुरोध अधिकृत नहीं होगा।

middleware

आने वाले HTTP अनुरोध में टोकन डालने के लिए कस्टम मिडलवेयर को लागू करना मुख्य विचार है। उपयोगकर्ता प्राधिकरण के बाद, हम एक निश्चित कुंजी के तहत कुकी को बचाते हैं, उदाहरण के लिए: ".AspNetCore.Application.Id" । मैं एक ऐसे नाम की स्थापना करने की सलाह देता हूं, जिसका प्राधिकरण या टोकन से कोई लेना-देना नहीं है - इस मामले में, टोकन के साथ एक कुकी एस्पेनेटकोर एप्लिकेशन के लिए निरंतर किसी प्रकार की अनियंत्रित प्रणाली की तरह दिखाई देगी। इसलिए इस बात की अधिक संभावना है कि हमलावर कई सिस्टम चर को देखेगा और यह समझने के बिना कि कौन से प्राधिकरण तंत्र का उपयोग किया जाता है, आगे जाएगा। बेशक, अगर वह इस लेख को नहीं पढ़ता है और विशेष रूप से ऐसे स्थिरांक के लिए बाहर नहीं दिखता है।

इसके बाद, हमें आने वाले HTTP अनुरोधों में इस टोकन को सम्मिलित करना होगा। ऐसा करने के लिए, हम मिडलवेयर कोड की कुछ पंक्तियाँ लिखेंगे। यह एक HTTP पाइपलाइन के अलावा और कुछ नहीं है।



कॉन्फ़िगर

 app.Use(async (context, next) => { var token = context.Request.Cookies[".AspNetCore.Application.Id"]; if (!string.IsNullOrEmpty(token)) context.Request.Headers.Add("Authorization", "Bearer " + token); await next(); }); app.UseAuthentication(); 

हम इस तर्क को एक अलग मिडलवेयर सेवा में ले जा सकते हैं ताकि स्टार्टअप को बंद न किया जाए। विचार नहीं बदलेगा।

कुकीज़ में मान लिखने के लिए, हमें केवल प्राधिकरण तर्क में निम्नलिखित पंक्ति जोड़ने की आवश्यकता है:

 if (result.Succeeded) HttpContext.Response.Cookies.Append(".AspNetCore.Application.Id", token, new CookieOptions { MaxAge = TimeSpan.FromMinutes(60) }); 

हमारी कुकी-नीतियों का उपयोग करके, इन कुकीज़ को स्वचालित रूप से httpOnly और सुरक्षित के रूप में भेजा जाएगा। कुकी विकल्पों में उनकी नीति को फिर से परिभाषित करने की आवश्यकता नहीं है।

कुकी में, आप जीवन भर निर्दिष्ट करने के लिए MaxAge सेट कर सकते हैं। टोकन जारी करते समय JWT लाइफटाइम के साथ निर्दिष्ट करना उपयोगी है ताकि कुकी थोड़ी देर के बाद गायब हो जाए। कुकी की अन्य संपत्तियों को परियोजना की आवश्यकताओं के आधार पर कॉन्फ़िगर किया गया है।

अधिक सुरक्षा के लिए, मैं निम्नलिखित हेडर को मिडलवेयर में जोड़ने की सलाह देता हूं:

 context.Response.Headers.Add("X-Content-Type-Options", "nosniff"); context.Response.Headers.Add("X-Xss-Protection", "1"); context.Response.Headers.Add("X-Frame-Options", "DENY"); 

• X-Content-Type-Options हेडर का उपयोग MIME सूँघने की कमजोरियों से बचाने के लिए किया जाता है। यह भेद्यता तब हो सकती है जब कोई साइट उपयोगकर्ताओं को सामग्री डाउनलोड करने की अनुमति देती है, लेकिन उपयोगकर्ता एक निश्चित प्रकार की फ़ाइल को कुछ और के रूप में प्रदर्शित करता है। यह हमलावरों को क्रॉस-साइट स्क्रिप्टिंग स्क्रिप्ट निष्पादित करने या किसी वेबसाइट से समझौता करने की क्षमता दे सकता है।
• सभी आधुनिक ब्राउज़रों में बिल्ट-इन XSS फ़िल्टरिंग क्षमताएं हैं, जो पेज को पूरी तरह से हमारे सामने प्रदर्शित होने से पहले XSS भेद्यता को पकड़ने की कोशिश करते हैं। डिफ़ॉल्ट रूप से, वे ब्राउज़र में सक्षम होते हैं, लेकिन उपयोगकर्ता मुश्किल हो सकता है और उन्हें अक्षम कर सकता है। एक्स-एक्सएसएस-सुरक्षा हेडर का उपयोग करके, हम वास्तव में ब्राउज़र को बता सकते हैं कि उपयोगकर्ता ने जो किया है उसे अनदेखा करें और अंतर्निहित फ़िल्टर को लागू करें।
• एक्स-फ़्रेम-ऑप्शंस ब्राउज़र को बताता है कि यदि आपकी साइट को एक HTML फ्रेम के अंदर रखा गया है, तो कुछ भी प्रदर्शित न करें। अपने आप को क्लिकजैकिंग प्रयासों से बचाने की कोशिश करते समय यह बहुत महत्वपूर्ण है।

मैंने सभी सुर्खियों से दूर का वर्णन किया है। अधिक से अधिक वेब अनुप्रयोग सुरक्षा प्राप्त करने के बहुत सारे तरीके हैं। मैं आपको Securityheaders.com संसाधन से सुरक्षा जांच सूची पर ध्यान केंद्रित करने की सलाह देता हूं।

एसपीए ग्राहक सेटअप

जब क्लाइंट और सर्वर अलग-अलग मूल पर स्थित होते हैं, तो क्लाइंट पर अतिरिक्त कॉन्फ़िगरेशन भी आवश्यक है। आपको XMLHttpRequest.withCredentials का उपयोग करके प्रत्येक अनुरोध को लपेटना होगा।

मैंने अपने तरीकों को इस प्रकार लपेटा:

 import axios from "axios"; const api = axios.create({ baseURL: process.env.REACT_APP_API_URL }); api.interceptors.request.use(request => requestInterceptor(request)) const requestInterceptor = (request) => { request.withCredentials = true; return request; } export default api; 

हम किसी भी तरह से हमारे अनुरोध को कॉन्फ़िगर कर सकते हैं, मुख्य बात यह है कि withCredentials = true वहाँ है ।

XMLHttpRequest.withCredentials गुण निर्धारित करता है कि क्रॉस-डोमेन अनुरोधों को कुकीज़, प्राधिकरण हेडर या टीएलएस प्रमाणपत्र जैसे क्रेडेंशियल का उपयोग करके उत्पन्न किया जाना चाहिए या नहीं।

इस ध्वज का उपयोग यह निर्धारित करने के लिए भी किया जाता है कि प्रतिक्रिया में भेजे गए कुकीज़ को अनदेखा किया जाएगा या नहीं। किसी अन्य डोमेन से XMLHttpRequest इस अनुरोध को बनाने से पहले withCredentials ध्वज को सही पर सेट नहीं किया गया है, तो अपने स्वयं के डोमेन पर कुकी सेट नहीं कर सकता है।

दूसरे शब्दों में, यदि आप इस विशेषता को निर्दिष्ट नहीं करते हैं, तो हमारी कुकी ब्राउज़र द्वारा सहेजी नहीं जाएगी, अर्थात। हम कुकी को सर्वर पर वापस नहीं भेज पाएंगे, और सर्वर को JWT के साथ वांछित कुकी नहीं मिलेगी और हमारे HTTP पाइपलाइन में बियरर टोकन पर हस्ताक्षर नहीं करेगा।

यह सब किस लिए है?

ऊपर, मैंने टोकन के आदान-प्रदान के एक XSS- प्रतिरोधी तरीके का वर्णन किया। आइए, ऊपर जाएं और कार्यान्वित कार्यक्षमता के परिणाम को देखें।

यदि आप डेवलपर टूल में जाते हैं, तो हम प्रतिष्ठित झंडे httpOnly और सुरक्षित देखते हैं:



चलो क्रश-टेस्ट करते हैं, कुकीज़ को क्लाइंट से बाहर निकालने की कोशिश करते हैं:



हम '' देख रहे हैं, अर्थात् कुकीज़ दस्तावेज़ स्थान से सुलभ नहीं हैं, जो उन्हें स्क्रिप्ट के साथ पढ़ना असंभव बनाता है।

हम अतिरिक्त उपकरण या एक्सटेंशन की मदद से इन कुकीज़ को प्राप्त करने का प्रयास कर सकते हैं, लेकिन मैंने जो भी उपकरण आज़माए हैं, उन्हें दस्तावेज़ स्थान से मूल कार्यान्वयन कहा है।

डेमो प्रोजेक्ट

स्टार्टअप निर्देश README.MD में हैं

UPD: CSRF के खिलाफ संरक्षण

ASP.NET कोर सर्वर को कॉन्फ़िगर करें

मिडिलवेयर सेवाएं





ConfigureServices

 services.AddAntiforgery(options => { options.HeaderName = "x-xsrf-token"; }); services.AddMvc(); 

कॉन्फ़िगर

 app.UseAuthentication(); app.UseXsrfProtection(antiforgery); 

एसपीए सेटअप

के उपयोग

हमारे एपीआई विधियों की सुरक्षा के लिए, आपको नियंत्रक के लिए [AutoValidateAntiforgeryToken] विशेषता या विधि के लिए [ValidateAntiForgeryToken] जोड़ना होगा।