நிர்வாக துணைக்களம் 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 குறையை நீக்காது. தனி ஹோஸ்ட் பெயர் உண்மையான மதிப்புள்ள உலாவி பக்க தனிமைப்படுத்தல் எல்லை, அது பாதுகாப்பற்ற குறியீடு இயக்கத்தை தடுப்பதற்கோ சேவையக பக்க கோரிக்கை பாதுகாப்பிற்கோ மாற்றாகாது. பிரிப்புக்குப் பின் பட்டியல் தெரிவதை விட குறுகியது: தனி தோற்றம், ஹோஸ்டுக்கு மட்டுமான குக்கிகள், ஒவ்வொரு மாற்றத்திலும் டோக்கன், அடையாளமாக நம்பாத நுழைவு வடிகட்டி, ஒவ்வொரு கோரிக்கைக்கும் தீர்மானிக்கப்படும் அனுமதி.