ಅಡ್ಮಿನ್ ಉಪಡೊಮೇನ್ 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 ದೋಷವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ಪ್ರತ್ಯೇಕ ಹೋಸ್ಟ್ ಹೆಸರು ನಿಜವಾದ ಮೌಲ್ಯವಿರುವ ಬ್ರೌಸರ್-ಬದಿಯ ಪ್ರತ್ಯೇಕತಾ ಗಡಿ, ಮತ್ತು ಅದು ಅಸುರಕ್ಷಿತ ಕೋಡ್ ಚಾಲನೆಯ ತಡೆಗಟ್ಟುವಿಕೆ ಅಥವಾ ಸರ್ವರ್-ಬದಿಯ ವಿನಂತಿ ರಕ್ಷಣೆಗೆ ಪರ್ಯಾಯವಲ್ಲ. ವಿಭಜನೆಯ ನಂತರ ಪಟ್ಟಿ ಕಾಣುವುದಕ್ಕಿಂತ ಚಿಕ್ಕದಾಗಿದೆ: ಪ್ರತ್ಯೇಕ ಮೂಲ, ಹೋಸ್ಟ್‌ಗೆ ಮಾತ್ರ ಕುಕಿಗಳು, ಪ್ರತಿ ಬದಲಾವಣೆಗೆ ಟೋಕನ್, ಗುರುತಿನಂತೆ ನಂಬದ ಪ್ರವೇಶ ಫಿಲ್ಟರ್, ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಗೆ ನಿರ್ಧರಿಸುವ ಅನುಮತಿ.