అడ్మిన్ సబ్‌డొమైన్ 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 లోపాన్ని తొలగించదు. ప్రత్యేక హోస్ట్ పేరు నిజమైన విలువ ఉన్న బ్రౌజర్-వైపు ఐసోలేషన్ సరిహద్దు, అది అసురక్షిత కోడ్ అమలును నిరోధించడానికి లేదా సర్వర్-వైపు అభ్యర్థన రక్షణకు ప్రత్యామ్నాయం కాదు. విభజన తర్వాత జాబితా కనిపించే దానికంటే చిన్నది: వేరే మూలం, హోస్ట్‌కే పరిమితమైన కుకీలు, ప్రతి మార్పుకు టోకెన్, గుర్తింపుగా నమ్మని ప్రవేశ వడపోత, ప్రతి అభ్యర్థనకు నిర్ణయించబడే అనుమతి.