Black Hat USA 2026 ರಲ್ಲಿ, ಸಂಶೋಧಕರು Cascading Style Sheets (CSS) ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮಾನವ ಬಳಕೆದಾರರಿಗೆ ಕಾಣಿಸದ ವಿಷಯಗಳನ್ನು AI-ಚಾಲಿತ ಇಮೇಲ್ ಏಜೆಂಟ್‌ಗಳು ಓದುವಂತೆ ಮಾಡಬಹುದು ಎಂದು ತೋರಿಸಿಕೊಟ್ಟಿದ್ದಾರೆ. ಈ ತಂತ್ರವು Outlook, Gmail, Yahoo ಮತ್ತು Proton ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಿತು, ಇದರಿಂದ ಏಜೆಂಟ್‌ಗಳು ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ಅಥೆಂಟಿಕೇಶನ್ ಟೋಕನ್‌ಗಳು ಮತ್ತು IP ವಿಳಾಸಗಳನ್ನು ಸೋರಿಕೆಯ ಮಾಡಬಹುದು (exfiltrate).

ಇಮೇಲ್ ಸುರಕ್ಷತೆಯಲ್ಲಿ CSS ಏಕೆ ಮುಖ್ಯ

ವರ್ಷಗಳಿಂದ ವೆಬ್‌ಮೇಲ್ ಪ್ರೊವೈಡರ್‌ಗಳು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ (stripping scripts), iframes ಗಳನ್ನು ಸ್ಯಾಂಡ್‌ಬಾಕ್ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು ಸಂದೇಶವು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುವ ಮೂಲಕ ದುಷ್ಟ HTML ವಿರುದ್ಧ ರಕ್ಷಣೆ ನೀಡುತ್ತಿದ್ದಾರೆ. ಈ ಕ್ರಮಗಳು JavaScript ಅಥವಾ ಎಂಬೆಡೆಡ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಸಾಂಪ್ರದಾಯಿಕ ದಾಳಿಗಳನ್ನು ತಡೆಯುತ್ತವೆ. ಆದರೆ, CSS ಅನ್ನು ಯಾವಾಗಲೂ ಹಾನಿಕಾರಕವಲ್ಲದ ಪ್ರೆಸೆಂಟೇಶನ್ ಕೋಡ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಅದರ ಸುಧಾರಿತ ಸೆಲೆಕ್ಟರ್‌ಗಳು—ಅಟ್ರಿಬ್ಯೂಟ್ ಸೆಲೆಕ್ಟರ್‌ಗಳು, ಕಂಟೇನರ್ ಕ್ವೇರಿಗಳು ಮತ್ತು ಇತ್ಯಾದಿ—ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಇಲ್ಲದೆ ಪೇಜ್ ಅನ್ನು DOM ರಚನೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಈ "ಹಾನಿಕಾರಕವಲ್ಲದ" ಸೆಲೆಕ್ಟರ್‌ಗಳು ಡೇಟಾ ಸೋರಿಕೆಗೆ ಸೈಡ್-ಚಾನೆಲ್ ಆಗಬಹುದು ಎಂದು Black Hat ಪ್ರದರ್ಶನಗಳು ಸಾಬೀತುಪಡಿಸಿವೆ. ಕೆಲವು ಗುಪ್ತ ಅಂಶಗಳು (hidden elements) ಇದ್ದಾಗ ಮಾತ್ರ ಅನ್ವಯವಾಗುವ ಸ್ಟೈಲ್ ನಿಯಮಗಳನ್ನು ರೂಪಿಸುವ ಮೂಲಕ, ದಾಳಿಕೋರರು ಪಠ್ಯವನ್ನು ಬಳಕೆದಾರರಿಗೆ ಕಾಣಿಸದಂತೆ ಮಾಡುತ್ತಾರೆ, ಆದರೆ AI ಏಜೆಂಟ್ ವಿಶ್ಲೇಷಿಸುವ (parse) ರೆಂಡರ್ ಮಾಡಲಾದ ಪೇಜ್‌ನಲ್ಲಿ ಅದು ಇರುತ್ತದೆ.

ದಾಳಿಗಳು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ

ಒಂದು ಪ್ರೂಫ್-ಆಫ್-ಕನ್ಸೆಪ್ಟ್ (proof-of-concept) ಸ್ವೀಕರಿಸುವವರಿಗೆ ಸಾಮಾನ್ಯವೆಂದು ಕಾಣುವ ಇಮೇಲ್ ಅನ್ನು ಕಳುಹಿಸಿತು. ಅದರೊಳಗೆ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಪಠ್ಯದ ಬಣ್ಣವನ್ನು ಹಿನ್ನೆಲೆಗೆ (background) ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಮಾಡುವ CSS ನಿಯಮಗಳು ಅಡಗಿದ್ದವು, ಇದು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅದನ್ನು ಮರೆಮಾಚಿತು (cloaking). ಮನುಷ್ಯರಿಗೆ ಆ ಪಠ್ಯ ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ, ಆದರೆ DOM ಅಥವಾ ಅಕ್ಸೆಸಿಬಿಲಿಟಿ ಟ್ರೀಯನ್ನು (accessibility tree) ಹೊರತೆಗೆಯುವ AI ಏಜೆಂಟ್ ದೃಶ್ಯ ಫಿಲ್ಟರ್ ಅನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಏಜೆಂಟ್ ಇಮೇಲ್ ಅನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಿದಾಗ, ಅದು ಮರೆಮಾಚಲಾದ ಪಠ್ಯವನ್ನು ಓದಿತು ಮತ್ತು ಅದನ್ನು URL ಫ್ರಾಗ್ಮೆಂಟ್‌ನಲ್ಲಿ (URL fragment)—ಅಂದರೆ ಬ್ರೌಸರ್‌ಗಳು ಪೇಜ್ ಲೋಡ್ ಮಾಡುವಾಗ ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುವ ವೆಬ್ ವಿಳಾಸದ ಭಾಗದಲ್ಲಿ—ಪ್ರಸಾರ ಮಾಡಿತು.

ಇನ್ನೊಂದು ರೂಪವು ಪರೋಕ್ಷ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ (indirect prompt injection) ಅನ್ನು ಬಳಸಿತು. ಇಮೇಲ್‌ನಲ್ಲಿ ಗುಪ್ತ Slack ಟೋಕನ್ ಇತ್ತು. CSS ಆ ಟೋಕನ್ ಅನ್ನು ಬಳಕೆದಾರರಿಗೆ ಕಾಣಿಸದಂತೆ ಮಾಡಿತು ಆದರೆ ಮಾರ್ಕಪ್‌ನಲ್ಲಿ ಇರಿಸಿತು. ಇಮೇಲ್‌ನಲ್ಲಿ ಅಡಗಿರುವ ಸೂಚನೆಗಳನ್ನು ಪಾಲಿಸಲು ತರಬೇತಿ ಪಡೆದ AI ಏಜೆಂಟ್, ಆ ಟೋಕನ್ ಅನ್ನು ಕಮಾಂಡ್ ಎಂದು ಅರ್ಥೈಸಿಕೊಂಡಿತು ಮತ್ತು ಅದನ್ನು ದಾಳಿಕೋರರ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಿತು.

ಎರಡೂ ದಾಳಿಗಳು ಜನಪ್ರಿಯ ಪ್ರೊವೈಡರ್‌ಗಳ ವಿರುದ್ಧ ಯಶಸ್ವಿಯಾದವು, ಇದು ದೌರ್ಬಲ್ಯವು CSS ಅನ್ನು ರೆಂಡರ್ ಮಾಡುವ ಮೂಲಭೂತ ವಿಧಾನದಿಂದ ಉದ್ಭವಿಸುತ್ತದೆ ಹೊರತು ಯಾವುದೇ ಒಂದೇ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಅನುಷ್ಠಾನದಿಂದಲ್ಲ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

AI ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು ಮಾನವ ಓದುಗರು

ಮನುಷ್ಯರು ತಮಗೆ ಕಾಣಿಸದ ಪಠ್ಯವನ್ನು ಸಹಜವಾಗಿಯೇ ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ; ಯಾವುದು ಮುಖ್ಯ ಎಂಬುದನ್ನು ತಿಳಿಸಲು ನಾವು ದೃಶ್ಯ ವಿನ್ಯಾಸವನ್ನು (visual layout) ನಂಬುತ್ತೇವೆ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, AI ಏಜೆಂಟ್‌ಗಳು ದೃಶ್ಯ ಸ್ಥಿತಿಯನ್ನು (visual state) ಲೆಕ್ಕಿಸದೆ ಪ್ರತಿಯೊಂದು ಅಂಶವನ್ನು ದಾಖಲಿಸುವ ರಾಗು DOM ಅಥವಾ ಅಕ್ಸೆಸಿಬಿಲಿಟಿ ಟ್ರೀಯನ್ನು ಆಧರಿಸಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. AI ಪೇಜ್ ಅನ್ನು ಓದಿದಾಗ, ಅದು "ನನಗೆ ಕಾಣಿಸದಿದ್ದರೆ, ನಾನು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತೇನೆ" ಎಂಬ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಆ ವ್ಯತ್ಯಾಸವು ಒಂದು ಅಂಧಾಕಾರದ ಬಿಂದುವನ್ನು (blind spot) ಸೃಷ್ಟಿಸುತ್ತದೆ: ಮಾನವ ಬಳಕೆಗಾಗಿ ನಿರ್ಮಿಸಲಾದ ಸ್ಯಾನಿಟೈಸೇಶನ್ ಪೈಪ್‌ಲೈನ್‌ಗಳು (sanitisation pipelines) ಸ್ವಯಂಚಾಲಿತ ಓದುಗರಿಗೆ ಇನ್ನು ಮುಂದೆ ಸುರಕ್ಷತೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.

ಈ ಸಮಸ್ಯೆ ಹೊಸ AI ದೋಷವಲ್ಲ. ಇದು ಹಳೆಯ ವೆಬ್ ದೋಷ—ಕೋಡ್ ಇಲ್ಲದೆ ಲೇಔಟ್ ಅನ್ನು ಪರಿಣಾಮಗೊಳಿಸುವ CSS ನ ಸಾಮರ್ಥ್ಯ—ಹೊಸ ರೀತಿಯ ಬಳಕೆದಾರರನ್ನು ಎದುರಿಸುತ್ತಿದೆ. ಇಮೇಲ್ ವಿಷಯವನ್ನು AI-ಚಾಲಿತ ಅಸಿಸ್ಟೆಂಟ್, ಸಮ್ಮರೈಸರ್ ಅಥವಾ ಕ್ಲಾಸಿಫೈಯರ್‌ಗೆ ಹಸ್ತಾಂತರಿಸುವ ಯಾವುದೇ ಸೇವೆ ಈಗ ಮನುಷ್ಯನಿಗೆ ಎಂದಿಗೂ ಕಾಣಿಸದ ಡೇಟಾದ ಮೇಲೆ ಅಸಿಸ್ಟೆಂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅಪಾಯವನ್ನು ಎದುರಿಸುತ್ತಿದೆ.

ರಕ್ಷಣೆಗಾಗಿ ಯಾರು ಜವಾಬ್ದಾರರು?

ಈ ದಾಳಿಗಳು ಅಧಿಕಾರ ವ್ಯಾಪ್ತಿಯ ಪ್ರಶ್ನೆಯನ್ನು ಎತ್ತುತ್ತವೆ. ವೆಬ್‌ಮೇಲ್ ಪ್ರೊವೈಡರ್‌ಗಳು ಮಾನವ ಬಳಕೆದಾರರನ್ನು ರಕ್ಷಿಸಲು ಈಗಾಗಲೇ HTML ಅನ್ನು ಕ್ಲೀನ್ ಮಾಡುತ್ತಾರೆ; ಬ್ರೌಸರ್‌ಗಳು ರೆಂಡರಿಂಗ್‌ಗಾಗಿ ಈಗಾಗಲೇ ಅದೇ ನಿಯಮಗಳನ್ನು ಜಾರಿಗೆ ತರುತ್ತಿವೆ. ಆದರೂ, ಆ ಮಾರ್ಕಪ್ ಅನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ AI ಬಗ್ಗೆ ಈ ಯಾವುದೇ ಪದರಗಳು ಪರಿಗಣಿಸುವುದಿಲ್ಲ. ಇಮೇಲ್ ಸೇವೆಯು ಹೆಚ್ಚು ಆಳವಾದ CSS ಸ್ಯಾನಿಟೈಸೇಶನ್ ಅನ್ನು ಸೇರಿಸಬೇಕೇ? ಬ್ರೌಸರ್‌ಗಳು ಅಂಶಗಳನ್ನು "ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಗೆ ಕಾಣಿಸದಂತೆ" ಗುರುತಿಸುವ ಫ್ಲಾಗ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಬೇಕೇ? ಅಥವಾ AI ಮಾರಾಟಗಾರರು ಪ್ರೊಸೆಸ್ ಮಾಡುವ ಮೊದಲು ಗುಪ್ತ ನೋಡ್‌ಗಳನ್ನು (hidden nodes) ಕೈಬಿಡುವ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬೇಕೇ?

AI-ಚಾಲಿತ ಇಮೇಲ್ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವ ಸೆಕ್ಯೂರಿಟಿ ತಂಡಗಳಿಗೆ ಇನ್‌ಬಾಕ್ಸ್‌ಗೆ ತಲುಪುವ HTML ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಸಂಪೂರ್ಣ ರೆಂಡರಿಂಗ್ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಆಡಿಟ್ ಮಾಡಲು ಸೂಚಿಸಲಾಗುತ್ತಿದೆ. ಅಂದರೆ CSS ಅನ್ವಯಿಸಿದ ನಂತರ DOM ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು, ಅಕ್ಸೆಸಿಬಿಲಿಟಿ ಟ್ರೀಯನ್ನು ತಪಾಸಣೆ ಮಾಡುವುದು ಮತ್ತು ಮಾನವ ಕಣ್ಣಿಗೆ ಕಾಣಿಸದ ಯಾವುದೇ ವಿಷಯವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೆಗೆದುಹಾಕುವುದು ಅಥವಾ ಫ್ಲಾಗ್ ಮಾಡುವುದು ಎಂದರ್ಥ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

  • ವೆಂಡರ್ ಟೆಸ್ಟಿಂಗ್ (Vendor testing) – AI ಮಾರಾಟಗಾರರು ತಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್‌ಗಳಲ್ಲಿ ನೈಜ ಪ್ರಪಂಚದ CSS ದಾಳಿ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಸೇರಿಸುವ ನಿರೀಕ್ಷೆಯಿದೆ. ವೆಬ್‌ಗೆ ಮೂವತ್ತು ವರ್ಷಗಳ ದೌರ್ಬಲ್ಯ ಸಂಶೋಧನೆಯಿದೆ; AI ಏಜೆಂಟ್‌ಗಳಿಗೆ ಕೇವಲ ಕೆಲವು ವರ್ಷಗಳಷ್ಟೇ ಇವೆ.

ಕೇವಲ CSS ಮೂಲಕ ಪಠ್ಯವನ್ನು ಮರೆಮಾಚುವ ಮೂಲಕ AI ಅಸಿಸ್ಟೆಂಟ್ ಅನ್ನು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಸೋರಿಕೆ ಮಾಡಲು ವಂಚಿಸಬಹುದು ಎಂದಾದರೆ, ಇಂದಿನ ಇನ್‌ಬಾಕ್ಸ್‌ಗಳನ್ನು ರಕ್ಷಿಸುವ ಸುರಕ್ಷತಾ ಮಾದರಿಯು ಇನ್ನು ಮುಂದೆ ಸಾಕಾಗುವುದಿಲ್ಲ. ಡೆವಲಪರ್‌ಗಳು, ಪ್ರೊವೈಡರ್‌ಗಳು ಮತ್ತು ನಿಯಂತ್ರಕರು ಕೇವಲ ರಾಗು HTML ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ರೆಂಡರ್ ಮಾಡಲಾದ ಪೇಜ್ ಅನ್ನು ಯಾವುದೇ ಸ್ವಯಂಚಾಲಿತ ಬಳಕೆದಾರರಿಗೆ ಸುರಕ್ಷತಾ ಗಡಿಯಾಗಿ ಪರಿಗಣಿಸಬೇಕು. "ಕೇವಲ ಸ್ಟೈಲಿಂಗ್" ಎಂದು ಕಡೆಗಣಿಸಲ್ಪಟ್ಟ ತಂತ್ರಜ್ಞಾನವು ಡೇಟಾ ಕಳ್ಳತನಕ್ಕೆ ಮಾಧ್ಯಮವಾಗಬಹುದು ಎಂದು ಗುಪ್ತ-ಪಠ್ಯದ ಸಮಸ್ಯೆ ನಮಗೆ ನೆನಪಿಸುತ್ತದೆ. ರಕ್ಷಣೆಯ ಮುಂದಿನ ಅಲೆ CSS ಅನ್ನು ಕೇವಲ ದೃಶ್ಯ ನೆರವು ಎಂದು ಪರಿಗಣಿಸದೆ, ಸಂಭಾವ್ಯ ದಾಳಿ ವಿಸ್ತೀರ್ಣವಾಗಿ (attack surface) ಗುರುತಿಸಬೇಕಾಗುತ್ತದೆ.