એડમિન સબડોમેન 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 ખામી દૂર કરતું નથી. અલગ હોસ્ટનામ બ્રાઉઝર-બાજુની અલગતા સીમા છે જેનું સાચું મૂલ્ય છે, અને તે અસુરક્ષિત કોડ ચલાવવાના નિવારણ કે સર્વર-બાજુની વિનંતી સુરક્ષાનો વિકલ્પ નથી. વિભાજન પછી યાદી દેખાય તેના કરતાં ટૂંકી છે: અલગ ઓરિજિન, ફક્ત-હોસ્ટ કૂકીઝ, દરેક ફેરફાર પર ટોકન, ઓળખ તરીકે ન વિશ્વાસ કરવાપાત્ર પ્રવેશ ફિલ્ટર, અને પ્રત્યેક વિનંતી માટે નક્કી થતું ઓથોરાઇઝેશન.