Safari MCP ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಒಂದು ಆಟೊಮೇಷನ್ ಟೂಲ್, ಡೆವಲಪರ್ನ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಟ್ಯಾಬ್ ಅನ್ನು ಓದುತ್ತಿದ್ದಾಗಲೇ ಅದನ್ನು ಮುಚ್ಚುವಿಕೆಗೆ ಕಾರಣವಾಯಿತು. ಈ ಘಟನೆಯು, AI-ಚಾಲಿತ ಏಜೆಂಟ್ಗಳು ತಮಗೆ ಸೇರದ ಯಾವುದೇ ಟ್ಯಾಬ್ಗಳನ್ನು ಮುಟ್ಟದಂತೆ ತಡೆಯಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ 'ಗಾರ್ಡ್'ನಲ್ಲಿ (guard) ಅಡಗಿರುವ ದೋಷವನ್ನು ಬಯಲಿಗೆಳೆಯಿತು. ಅಲ್ಲದೆ, "safe-by-default" ವರ್ಗಗಳು ಹೇಗೆ ಹೊರೆಯಾಗಬಹುದು ಎಂಬುದನ್ನು ಇದು ತೋರಿಸಿಕೊಟ್ಟಿದೆ.
ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಗಾರ್ಡ್—ಅದು ವಿಫಲವಾಗುವವರೆಗೆ
ಈ ಟೂಲ್ ತಾನು ರಚಿಸುವ ಪ್ರತಿಯೊಂದು ಟ್ಯಾಬ್ಗೆ ಒಂದು ಆಂತರಿಕ ಗುರುತನ್ನು (internal identifier) ನೀಡುತ್ತದೆ. ಏಜೆಂಟ್ ಯಾವುದೇ ಕಮಾಂಡ್ ನೀಡುವ ಮೊದಲು, ಗಾರ್ಡ್ ಆ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ; ಒಂದು ವೇಳೆ ಆ ಗುರುತು ಇಲ್ಲದಿದ್ದರೆ, ಗಾರ್ಡ್ ಯಾವುದೇ ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಲು ನಿರಾಕರಿಸುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಏಜೆಂಟ್ ತಾನು ತೆರೆಯದ ಪುಟವನ್ನು ಓದದಂತೆ ಗಾರ್ಡ್ ತಡೆದಿತು—ಇದು ಅದರ ವಿನ್ಯಾಸದ ಉದ್ದೇಶವೇ ಆಗಿತ್ತು.
ಒಂದು ಫಾರ್ಮ್ ಅನ್ನು ಭರ್ತಿ ಮಾಡುವಾಗ, ಪುಟವು ಬೇರೆ ಡೊಮೇನ್ಗೆ ರಿಡೈರೆಕ್ಟ್ (redirect) ಆಯಿತು. ಈ ರಿಡೈರೆಕ್ಟ್ನಿಂದಾಗಿ ಆ ಗುರುತು ಅಳಿಸಿಹೋಯಿತು ಮತ್ತು ಟ್ಯಾಬ್ ಯಾವುದೇ ಲೇಬಲ್ ಇಲ್ಲದೆ ಉಳಿಯಿತು. ಗಾರ್ಡ್ ಆ ಗುರುತು ಇಲ್ಲದಿರುವುದನ್ನು ಗಮನಿಸಿ, "ನನಗೆ ಮಾಲೀಕತ್ವವನ್ನು (ownership) ಖಚಿತಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಈ ಟ್ಯಾಬ್ ಅನ್ನು ಓದುವುದಿಲ್ಲ" ಎಂದು ವರದಿ ಮಾಡಿತು. ಆ ಕ್ಷಣದಲ್ಲಿ, ಸುರಕ್ಷತಾ ತಪಾಸಣೆಯು ಉದ್ದೇಶಿತ ರೀತಿಯಲ್ಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು.
ಮಿತಿ ಮೀರಿ ಹೋದ ಕ್ಲೀನಪ್ ಕೋಡ್ (cleanup code)
ನಂತರ, ಗುರುತು ಇಲ್ಲದ ಅನಾಥ ಟ್ಯಾಬ್ಗಳನ್ನು (orphaned tabs) ಮುಚ್ಚಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಮ್ಯಾನುಯಲ್ ಕ್ಲೀನಪ್ ರೂಟೀನ್ (manual cleanup routine) ಬಂದಿತು. ಈ ರೂಟೀನ್ ಮಾಲೀಕತ್ವವನ್ನು ಮೊದಲು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳದೆ, ಟೂಲ್ಗೆ "ಒಂದು ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚಿ" ಎಂದು ಕೇಳಿತು. ಆ ಟ್ಯಾಬ್ ತನ್ನದೇ ಎಂದು ಗಾರ್ಡ್ ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ, ಟೂಲ್ ತನ್ನ ಡಿಫಾಲ್ಟ್ ಕ್ರಮಕ್ಕೆ (default action) ಮರಳಿತು: "ಪ್ರಸ್ತುತ ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚಿ" (close the current tab). ಆದರೆ ಆ ಪ್ರಸ್ತುತ ಟ್ಯಾಬ್ ಡೆವಲಪರ್ ಓದುತ್ತಿದ್ದ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಆಗಿತ್ತು, ಅನಾಥ ಟ್ಯಾಬ್ ಆಗಿರಲಿಲ್ಲ.
ಇದರ ಪರಿಣಾಮವಾಗಿ, ಒಂದು ಸುರಕ್ಷತಾ ಮಾರ್ಗವು (safety path) ವಿಫಲವಾಗಿ, ಅನಿರೀಕ್ಷಿತವಾಗಿ ವಿನಾಶಕಾರಿ ಕಾರ್ಯಾಚರಣೆಗೆ (destructive operation) ಕಾರಣವಾಯಿತು.
"ಮಾಲೀಕತ್ವವಿಲ್ಲ" ಎನ್ನುವುದನ್ನು ಅನುಮತಿಯೆಂದು ಪರಿಗಣಿಸಿದ ಮೂರು ಪದರಗಳು
- ಕಮಾಂಡ್ ವರ್ಗೀಕರಣ (Command categorisation) – ಕಮಾಂಡ್ಗಳನ್ನು ಗುಂಪು ಮಾಡುವ ಪಟ್ಟಿಯಲ್ಲಿ
close_tabಅನ್ನು "tab management" ಎಂಬ ವಿಶಾಲವಾದ ವರ್ಗದ ಅಡಿಯಲ್ಲಿ ಇರಿಸಲಾಗಿತ್ತು. "list tabs" ನಂತಹ ಇತರ ಕಮಾಂಡ್ಗಳು ಕೇವಲ ಮಾಹಿತಿಯನ್ನು ಓದುತ್ತವೆ என்பதால், ಆ ವರ್ಗದಲ್ಲಿರುವ ಎಲ್ಲವೂ ಹಾನಿಕಾರಕವಲ್ಲ ಎಂದು ಡೆವಲಪರ್ ಭಾವಿಸಿದ್ದರು.close_tabವನ್ನು ವಿನಾಶಕಾರಿ ಎಂದು ಎಲ್ಲಿಯೂ ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸಲಾಗಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ತನ್ನ ಪಕ್ಕದ ಕಮಾಂಡ್ಗಳ ಸುರಕ್ಷತೆಯನ್ನು ಪಡೆದುಕೊಂಡಿತು. - ಎಕ್ಸ್ಟೆನ್ಷನ್-ಮಟ್ಟದ ನೀತಿ (Extension-level policy) – ಎಲ್ಲಾ ಬ್ರೌಸರ್ ಕ್ರಿಯೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ Safari ಎಕ್ಸ್ಟೆನ್ಷನ್, ಸೆಷನ್ (session) ಯಾವುದನ್ನೂ ಮಾಲೀಕತ್ವದಲ್ಲಿ ಹೊಂದಿಲ್ಲದಿದ್ದಾಗ ಯಾವುದೇ ಕಾರ್ಯಾಚರಣೆಗೆ ಅವಕಾಶ ನೀಡಿತು. ಈ ನಿಯಮವು ಕೇವಲ ಓದುವಿಕೆಗೆ (read-only) ಮಾತ್ರ ಉಪಯುಕ್ತವಾಗಿರಬಹುದು, ಆದರೆ ಇದು
close_tabಅನ್ನು ಯಾವುದೇ ಮೂಲದ ಪರಿಶೀಲನೆ (provenance check) ಇಲ್ಲದೆ ಕಾರ್ಯಗತಗೊಳಿಸಲು ದಾರಿ ಮಾಡಿಕೊಟ್ಟಿತು. - ತರ್ಕದ ಅಸಮತೋಲನ (Logic mismatch) – ಕ್ಲೀನಪ್ ರೂಟೀನ್ ಒಂದು ಟ್ಯಾಬ್ನ ಮಾಲೀಕತ್ವದ ಫ್ಲಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿತು, ಆದರೆ ನಂತರ ಬ್ರೌಸರ್ "ಪ್ರಸ್ತುತ" (current) ಎಂದು ವರದಿ ಮಾಡಿದ ಟ್ಯಾಬ್ ಮೇಲೆ ಕ್ಲೋಸ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಕರೆ ಮಾಡಿತು. ಈ ಅಸಮತೋಲನದಿಂದಾಗಿ, ಗುರುತನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಗಾರ್ಡ್ ವಿಫಲವಾದರೂ, ಕ್ಲೋಸ್ ಕಮಾಂಡ್ ತಪ್ಪಾದ ಗುರಿಯತ್ತ ಸಾಗಿತು.
ಪ್ರತಿಯೊಂದು ಪದರವೂ "ಮಾಲೀಕತ್ವ ದಾಖಲಾಗಿಲ್ಲ" ಎಂದರೆ "ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸುರಕ್ಷಿತ" ಎಂದು ಭಾವಿಸಿತು, ಮತ್ತು ಇವೆಲ್ಲವೂ ಸೇರಿ ಯಾವುದೇ ಅಧಿಕಾರದ ಪುರಾವೆಯಿಲ್ಲದೆ ಟ್ಯಾಬ್ ಮುಚ್ಚುವ ಕಮಾಂಡ್ ಅನ್ನು ಚಲಾಯಿಸಿದವು.
ಪರಿಹಾರ: ವಿನಾಶಕಾರಿ ಕ್ರಿಯೆಗಳಿಗೆ ಮಾಲೀಕತ್ವದ ಪುರಾವೆ ಕಡ್ಡಾಯ
ಪರಿಷ್ಕೃತ ತರ್ಕವು ಓದುವಿಕೆಗೆ ಸಂಬಂಧಿಸಿದ ಮಾರ್ಗಗಳನ್ನು ವಿನಾಶಕಾರಿ ಮಾರ್ಗಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಈಗ, close_tab ಕಮಾಂಡ್ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮೊದಲು, ಟೂಲ್ ಗುರಿ ಟ್ಯಾಬ್ಗಾಗಿ ಮಾನ್ಯವಾದ ಗುರುತನ್ನು (valid marker) ಪ್ರಸ್ತುತಪಡಿಸಬೇಕು. ಒಂದು ವೇಳೆ ಗುರುತು ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರಸ್ತುತ ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚುವ ಬದಲು ಕಮಾಂಡ್ ದೋಷವನ್ನು (error) ತೋರಿಸುತ್ತದೆ. ಗಾರ್ಡ್ ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಸಾಮಾನ್ಯ "ಏನಾದರೂ ಮಾಡಿ" ಎಂಬ ಹಂತಕ್ಕೆ ಮರಳುವುದಿಲ್ಲ.
ಈ ಬದಲಾವಣೆಯು ಗುರುತು ಇಲ್ಲದಿರುವುದನ್ನು "ಏನೂ ಮಾಡಬೇಕಿಲ್ಲ" ಅಥವಾ "ಮುಂದುವರಿಯಿರಿ" ಎಂದು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸುವ ಸಂದಿಗ್ಧತೆಯನ್ನು ಹೋಗಲಾಡಿಸುತ್ತದೆ. ಸ್ಪಷ್ಟವಾದ ವೈಫಲ್ಯವನ್ನು (explicit failure) ಉಂಟುಮಾಡುವ ಮೂಲಕ, ಟೂಲ್ ಬಳಕೆದಾರರ ಕೆಲಸವು ಅಕಸ್ಮಾತ್ ನಷ್ಟವಾಗದಂತೆ ರಕ್ಷಿಸುತ್ತದೆ.
ಡೆವಲಪರ್ಗಳು ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು
- ವರ್ಗದ ಹೆಸರು ಸುರಕ್ಷತೆಯನ್ನು ನಿರ್ಧರಿಸಲು ಬಿಡಬೇಡಿ – "tab management" ಎಂಬ ಲೇಬಲ್ ಅದರೊಳಗಿನ ಪ್ರತಿಯೊಂದು ಕಮಾಂಡ್ನ ಪರಿಣಾಮದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚವನ್ನು (ಓದುವಿಕೆ vs ವಿನಾಶ) ಕಮಾಂಡ್ ಪಕ್ಕದಲ್ಲೇ ದಾಖಲಿಸಿ.
- ಗಾರ್ಡ್ ಪರಿಸ್ಥಿತಿಗಳು ಕ್ರಿಯೆಯ ತೀವ್ರತೆಗೆ ಅನುಗುಣವಾಗಿರಲಿ – ಕೇವಲ ಓದುವ ವಿನಂತಿಗೆ ಸಾಕಾಗುವ ತಪಾಸಣೆಯು, ಡೇಟಾವನ್ನು ಅಳಿಸುವ ಕಮಾಂಡ್ಗೆ ಸಾಕಾಗುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಪರಿಣಾಮದ ವರ್ಗಕ್ಕೆ ಪ್ರತ್ಯೇಕ ವ್ಯಾಲಿಡೇಶನ್ ಪೈಪ್ಲೈನ್ಗಳನ್ನು ನಿರ್ಮಿಸಿ.
- ಅಸ್ಪಷ್ಟ ಡಿಫಾಲ್ಟ್ ಕ್ರಮಗಳನ್ನು (implicit fallbacks) ತಪ್ಪಿಸಿ – ಗಾರ್ಡ್ ಮಾಲೀಕತ್ವವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ, ಡಿಫಾಲ್ಟ್ ಗುರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಬದಲು ಕಾರ್ಯವನ್ನು ರದ್ದುಗೊಳಿಸುವುದು (abort) ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಮಾರ್ಗವಾಗಿದೆ. ಡಿಫಾಲ್ಟ್ ಕ್ರಮಗಳು privilege-escalation ಬಗ್ಗಳಿಗೆ ಸಾಮಾನ್ಯ ಮೂಲಗಳಾಗಿವೆ.
- ಪಕ್ಕದ ಕಮಾಂಡ್ಗಳ ಮೇಲಿನ ನಂಬಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ (Audit adjacency assumptions) – ಕಮಾಂಡ್ಗಳು ಒಂದಕ್ಕೊಂದು ಪಕ್ಕದಲ್ಲಿರುವ ಯಾವುದೇ ಪಟ್ಟಿ ಅಥವಾ ಮೆನುವನ್ನು ಪರಿಶೀಲಿಸಿ. ಕೋಡ್ ಸುರಕ್ಷತೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮರು-ಮೌಲ್ಯಮಾಪನ ಮಾಡದಿದ್ದರೆ, ಒಂದು ಸಾಮಾನ್ಯ ಕಮಾಂಡ್ ತನ್ನ ಪಕ್ಕದ ಕಮಾಂಡ್ಗಳ ಮೇಲಿರುವ ನಂಬಿಕೆಯನ್ನು ಪಡೆದುಕೊಳ್ಳಬಹುದು.
ಸಾರಾಂಶ
ಮಾಲೀಕತ್ವದ ಗಾರ್ಡ್ ಇಲ್ಲದಿರುವುದು ಕೇವಲ ಬಗ್ ಅಲ್ಲ; ಅದು ವಿನ್ಯಾಸದ ಕೊರತೆ (design gap). ಪ್ರತಿಯೊಂದು ವಿನಾಶಕಾರಿ ಕಮಾಂಡ್ ಅನ್ನು ಅಧಿಕಾರದ ಸ್ಪಷ್ಟ ಪುರಾವೆಯನ್ನು ಬಯಸುವ ಪ್ರತ್ಯೇಕ ಭದ್ರತಾ ಡೊಮೇನ್ ಎಂದು ಪರಿಗಣಿಸಿ, ಮತ್ತು "ಗುರುತು ಇಲ್ಲ" ಎನ್ನುವುದನ್ನು "ಮುಂದುವರಿಯಿರಿ" ಎಂದು ಎಂದಿಗೂ ಅರ್ಥೈಸಲು ಬಿಡಬೇಡಿ. ಆಗ ಮಾತ್ರ ಆಟೊಮೇಷನ್ ಟೂಲ್ಗಳು ತಾವು ನಿರ್ವಹಿಸಬೇಕಾದ ಟ್ಯಾಬ್ಗಳನ್ನು ರಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.