അഡ്മിൻ സബ്ഡൊമെയ്ൻ CSRF തടയുന്നില്ല: ലോഞ്ചിന് മുമ്പ് നാല് പരിശോധനകൾ

അഡ്മിൻ ഇന്റർഫേസ് admin.example.com ലേക്ക് മാറ്റുന്നത് യഥാർത്ഥ മെച്ചമാണ്: ഇത് അഡ്മിൻ കുക്കികളെ പൊതു പേജുകളിൽ നിന്ന് അകറ്റി നിർത്തുന്നു, രണ്ട് ആപ്ലിക്കേഷനുകൾക്കും വെവ്വേറെ കാഷ് നൽകുന്നു, കൂടുതൽ കർശനമായ നെറ്റ്വർക്ക് നയം ഒരു ഹോസ്റ്റ്നെയിമിലേക്ക് തിരിച്ചുവിടാൻ അനുവദിക്കുന്നു. എന്നാൽ അത് CSRF നിയന്ത്രണമല്ല, ലോഗിൻ ചെയ്ത അഡ്മിന്റെ മുന്നിൽ പൊതു സൈറ്റിന്റെ കോഡ് തുറന്നിടാൻ സുരക്ഷിതമാക്കുന്നുമില്ല. വേർതിരിക്കൽ ബ്രൗസർ അതിർത്തിയായി കാണുന്നതിനെ മാറ്റുന്നു, സെർവർ പരിശോധിക്കുന്നതിനെയല്ല, അതിനാൽ ജോലി തീർന്നു എന്ന് പറയുന്നതിന് മുമ്പ് ഈ നാല് പരിശോധനകൾ ചെയ്യുക.

ഒറിജിനും സൈറ്റും രണ്ട് വ്യത്യസ്ത വാക്കുകളായി വായിക്കുക

ഒറിജിൻ എന്നത് സ്കീം, ഹോസ്റ്റ്, പോർട്ട് എന്നിവയാണ്, അതിനാൽ https://www.example.com ഉം https://admin.example.com ഉം വ്യത്യസ്ത ഒറിജിനുകളാണ്. SameSite അർത്ഥത്തിൽ സൈറ്റ് എന്നത് സ്കീം കൂടെ രജിസ്ട്രർ ചെയ്യാവുന്ന ഡൊമെയ്നാണ്, അതിനാൽ ആ രണ്ട് ഹോസ്റ്റ്നെയിമുകളും സാധാരണയായി ഒരേ സൈറ്റാണ്. ആ വ്യത്യാസമാണ് മുഴുവൻ കെണി: SameSite ഗുണം സഹോദര സബ്ഡൊമെയ്നുകൾക്കിടയിൽ സഹായിക്കില്ല, കാരണം ബ്രൗസർ ആ അഭ്യർത്ഥനയെ സൈറ്റ് കടക്കുന്നതായി കണക്കാക്കുന്നേയില്ല. അഡ്മിൻ ഇന്റർഫേസ് യഥാർത്ഥത്തിൽ വേറെയായ രജിസ്ട്രർ ചെയ്യാവുന്ന ഡൊമെയ്നിലേക്ക്, ഉദാഹരണത്തിന് admin-example.net ലേക്ക് തിരിച്ചുവിടുക, അപ്പോൾ അഭ്യർത്ഥന യഥാർത്ഥത്തിൽ സൈറ്റ് കടക്കുന്നതാകും, അവിടെയാണ് SameSite=Lax അല്ലെങ്കിൽ Strict വിശ്വസിക്കാവുന്ന ജോലി തുടങ്ങുന്നത്.

അതിനെക്കുറിച്ച് യുക്തി പറയുന്നതിന് പകരം ബ്രൗസറിൽ പരീക്ഷിക്കുക.

പൊതു സൈറ്റ് ലോഡ് ചെയ്യുക, ഡെവലപ്പർ ടൂളുകൾ തുറക്കുക, അഡ്മിൻ ഹോസ്റ്റിലേക്കുള്ള അഭ്യർത്ഥനയിൽ ബ്രൗസർ ഏത് കുക്കികൾ ചേർക്കുന്നു എന്ന് നോക്കുക. കുക്കിയിൽ Domain ഗുണമില്ലെങ്കിൽ അത് ഹോസ്റ്റിന് മാത്രമുള്ളതാണ്, സ്വന്തം പേരിൽ തുടരും; Domain=example.com ഉണ്ടെങ്കിൽ അത് ഓരോ സഹോദരനിലേക്കും പോകും, പുതിയ സബ്ഡൊമെയ്ൻ ആ കുക്കിക്ക് ഒന്നും തന്നില്ല.

പ്രതികരണം വായിക്കുന്നതും അഭ്യർത്ഥന അയക്കുന്നതും വേർതിരിക്കുക

ഒരേ ഒറിജിൻ നയം ഒറിജിനുകൾക്കിടയിൽ പ്രതികരണങ്ങൾ വായിക്കുന്നത് പരിമിതപ്പെടുത്തുന്നു. അത് അഭ്യർത്ഥന അയക്കുന്നത് തടയുന്നില്ല, ബ്രൗസറിന് ഇതിനകം ഉള്ള ക്രെഡൻഷ്യലുകൾ ഫോം കൊണ്ടുപോകുന്നതും തടയുന്നില്ല. ഫോം ഉള്ളടക്ക തരം അല്ലെങ്കിൽ സാധാരണ GET ഉള്ള ലളിതമായ അഭ്യർത്ഥന മുൻകൂർ പരിശോധനയില്ലാതെ എത്തുന്നു; പിന്നീട് CORS വിളിക്കുന്ന സ്ക്രിപ്റ്റിന് പ്രതികരണം വായിക്കാമോ എന്ന് തീരുമാനിക്കുന്നു. CSRF പൂർണ്ണമായും അയക്കുന്ന ഭാഗത്താണ്.

അതുകൊണ്ട് സ്ഥിതി മാറ്റുന്ന പ്രവർത്തനങ്ങൾക്ക് സെർവറിന് വ്യക്തമായ പരിശോധന വേണം. സെഷനുമായി ബന്ധിപ്പിച്ച സമന്വയ ടോക്കൺ, അല്ലെങ്കിൽ സെർവറിൽ താരതമ്യം ചെയ്യുന്ന ഇരട്ട സമർപ്പണ കുക്കി, ആ കേസ് മൂടുന്നു; Origin അല്ലെങ്കിൽ Referer താരതമ്യം രണ്ടാം ഗേറ്റായി ചേർക്കാൻ യോഗ്യമാണ്, പക്ഷേ ഒരേയൊരു ഗേറ്റായി അല്ല, കാരണം എല്ലാ അഭ്യർത്ഥനയും ആ തലക്കെട്ട് കൊണ്ടുപോകുന്നില്ല, എല്ലാ പ്രോക്സിയും അത് സൂക്ഷിക്കുന്നുമില്ല. CSRF തടയുന്നതിനുള്ള OWASP മാർഗ്ഗനിർദ്ദേശം SameSite നെ പല പാളികളിൽ ഒന്നായി കാണുന്നത് ഇതേ കാരണത്താലാണ്.

നെറ്റ്വർക്ക് ഗേറ്റ് യഥാർത്ഥത്തിൽ എന്ത് തെളിയിക്കുന്നു എന്ന് തീരുമാനിക്കുക

അഡ്മിൻ ഹോസ്റ്റിന് മുന്നിൽ VPN എക്സിറ്റ് അനുമതി പട്ടിക നല്ല നിയന്ത്രണവും ദുർബലമായ ഐഡന്റിറ്റി അവകാശവാദവുമാണ്. അഭ്യർത്ഥന VPN നൽകുന്ന വിലാസത്തിൽ നിന്ന് വന്നു എന്ന് അത് തെളിയിക്കുന്നു, ആ എക്സിറ്റിലുള്ള എല്ലാവർക്കും അത് പങ്കിടാം, അതിന് പിന്നിൽ ഏത് വ്യക്തിയോ ഉപകരണമോ ഉണ്ടെന്ന് ഒന്നും പറയുന്നുമില്ല. അതിനെ പ്രവേശന ഫിൽട്ടറായി കാണുക, ഐഡന്റിറ്റി പരിശോധനയായി അല്ല.

അഭ്യർത്ഥന നിലവിലെ പരിശോധനകളിൽ നിന്ന് അതിനെ സ്വതന്ത്രമായി നിർത്തുക. പട്ടിക ആക്രമണകാരിക്കും സ്ഥിതി മാറ്റുന്ന അന്തിമ പോയിന്റിനും ഇടയിലുള്ള ഒരേയൊരു കാര്യമാണെങ്കിൽ, തെറ്റായി ക്രമീകരിച്ച ഒരു റൂട്ട്, ഒരു split-tunnel ക്ലയന്റ്, അല്ലെങ്കിൽ കടം വാങ്ങിയ ഒരു ലാപ്ടോപ്പ് എന്നിവ നിയന്ത്രണം പൂർണ്ണമായി നീക്കും.

പ്രതീക്ഷിക്കുന്ന ശ്രേണികൾക്ക് പുറത്തുനിന്നുള്ള നിരസിക്കലുകളും രേഖപ്പെടുത്തുക. അവയുടെ വർദ്ധനവ് നിങ്ങൾ ഇപ്പോൾ നിർമ്മിച്ച അതിർത്തി ആരോ പരിശോധിക്കുന്നു എന്നതിന്റെ ഏറ്റവും ഉപയോഗപ്രദമായ സൂചനയാണ്, മൗനം ഫിൽട്ടറിൽ ഒന്നും എത്തുന്നില്ല എന്നതിന്റെ സൂചനയും.

കുക്കികളും ലോഗിനും അനുമതിയും വ്യക്തമായി നിലനിർത്തുക

കുക്കിയുടെ വ്യാപ്തി ഫലത്തിന്റെ ഭൂരിഭാഗവും തീരുമാനിക്കുന്നു. പാരന്റ് ഡൊമെയ്ൻ കുക്കി അഡ്മിൻ ഹോസ്റ്റിലേക്ക് അയക്കുന്നു, അതിനാൽ പൊതു സൈറ്റിലെ സ്ക്രിപ്റ്റ് കുത്തിവയ്പ്പ് അഡ്മിന്റെ സെഷൻ ഉപയോഗിച്ച് പ്രവർത്തിക്കാം; ഹോസ്റ്റിന് മാത്രമുള്ള കുക്കിക്ക് അത് സാധ്യമല്ല. ഹോസ്റ്റിന് മാത്രമുള്ള രൂപം തിരഞ്ഞെടുക്കുക, Secure ഗുണം ചേർക്കുക, പ്ലാറ്റ്ഫോം പിന്തുണയ്ക്കുന്നിടത്ത് __Host- പൂർവ്വപദം ഉപയോഗിക്കുക, കാരണം ആ പൂർവ്വപദത്തിന് Secure, Path=/ എന്നിവയും Domain ഗുണമില്ലായ്മയും ആവശ്യമാണ്. കുക്കി ജാര് അല്ല, പ്രതികരണ തലക്കെട്ട് വായിക്കുക: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, Domain ഗുണമില്ലാതെ. Domain ഉള്ള __Host- കുക്കി ബ്രൗസർ ഉപേക്ഷിക്കുന്നു, അതിനാൽ സഹോദര ഹോസ്റ്റുകളിൽ ഇപ്പോഴും കാണുന്ന കുക്കി പൂർവ്വപദം ഒരിക്കലും പ്രയോഗിച്ചിട്ടില്ല എന്നതിന്റെ തെളിവാണ്.

പിന്നീട് അനുമതി സെർവറിൽ, ഓരോ അഭ്യർത്ഥനയ്ക്കും, ഓരോ അഡ്മിൻ അന്തിമ പോയിന്റിലും നിലനിർത്തുക, ലോഗിൻ സമയത്ത് മാത്രമല്ല. അനുവദിച്ച നെറ്റ്വർക്കിൽ നിന്നുള്ള അഭ്യർത്ഥനയും ഇപ്പോഴും ഐഡന്റിറ്റി സ്ഥിരീകരിക്കപ്പെടുകയും അത് ആവശ്യപ്പെടുന്ന പ്രവർത്തനത്തിന് അധികാരം നൽകപ്പെടുകയും വേണം; ഹോസ്റ്റ്നെയിം ഒരു പ്രവർത്തകനല്ല. പൊതു, അഡ്മിൻ ആപ്ലിക്കേഷനുകൾ ലോഗിൻ പ്രവാഹമോ സെഷൻ സംഭരണിയോ പങ്കിടുന്നുവെങ്കിൽ ആ ബന്ധം എഴുതിവയ്ക്കുക, കാരണം പൊതു സൈറ്റിലെ തകരാറിൽ നിന്ന് അഡ്മിൻ പ്രവർത്തനത്തിലേക്കുള്ള ഏറ്റവും ചെറിയ വഴി അതാണ്.

വേർതിരിച്ചതിന് ശേഷം അതിർത്തി വീണ്ടും പരിശോധിക്കുക

സന്തോഷകരമായ വഴി മാത്രമല്ല, നെഗറ്റീവ് പരീക്ഷണങ്ങളും നടത്തുക: ടോക്കണില്ലാത്ത സൈറ്റ് കടക്കുന്ന ഫോം നിരസിക്കപ്പെടണം, മറ്റൊരു സെഷനിലെ ടോക്കണും നിരസിക്കപ്പെടണം, ഒരു GET ഉം സ്ഥിതി മാറ്റരുത്. ഡെവലപ്പർ ടൂളുകളിൽ കുക്കി ഗുണങ്ങൾ പരിശോധിക്കുക, പൊരുത്തപ്പെടാത്ത അഭ്യർത്ഥനയിൽ Origin പരിശോധന പ്രവർത്തിക്കുന്നു എന്ന് ഉറപ്പാക്കുക, ഫിൽട്ടർ പ്രവർത്തിക്കുന്നത് കാണാൻ VPN ശ്രേണിക്ക് പുറത്തുനിന്ന് അഡ്മിൻ ഹോസ്റ്റ് പരീക്ഷിക്കുക.

ഇവയൊന്നും അഡ്മിൻ ആപ്ലിക്കേഷന്റെ ഉള്ളിലെ XSS വീഴ്ച നീക്കുന്നില്ല. വേറിട്ട ഹോസ്റ്റ്നെയിം യഥാർത്ഥ മൂല്യമുള്ള ബ്രൗസർ വശത്തെ ഒറ്റപ്പെടുത്തൽ അതിർത്തിയാണ്, അത് സുരക്ഷിതമല്ലാത്ത കോഡ് പ്രവർത്തിപ്പിക്കുന്നത് തടയുന്നതിനോ സെർവർ വശത്തെ അഭ്യർത്ഥന സംരക്ഷണത്തിനോ പകരമല്ല. വേർതിരിച്ചതിന് ശേഷം പട്ടിക കാണുന്നതിനേക്കാൾ ചെറുതാണ്: വേറിട്ട ഒറിജിൻ, ഹോസ്റ്റിന് മാത്രമുള്ള കുക്കികൾ, ഓരോ മാറ്റത്തിനും ടോക്കൺ, ഐഡന്റിറ്റിയായി വിശ്വസിക്കാത്ത പ്രവേശന ഫിൽട്ടർ, ഓരോ അഭ്യർത്ഥനയ്ക്കും തീരുമാനിക്കുന്ന അനുമതി.