At Black Hat USA 2026, গবেষকরা দেখিয়েছেন যে Cascading Style Sheets (CSS)-কে অস্ত্র হিসেবে ব্যবহার করে AI-চালিত ইমেল এজেন্টদের এমন সব বিষয় পড়তে বাধ্য করা সম্ভব যা মানুষের কাছে অদৃশ্য। এই কৌশলটি Outlook, Gmail, Yahoo এবং Proton-কে ফাঁকি দিয়ে এজেন্টদের মাধ্যমে পাসওয়ার্ড, অথেন্টিকেশন টোকেন এবং IP অ্যাড্রেস চুরি করতে সক্ষম।
ইমেল নিরাপত্তায় CSS কেন গুরুত্বপূর্ণ
বহু বছর ধরে ওয়েবমেইল প্রদানকারীরা স্ক্রিপ্ট সরিয়ে ফেলা (stripping scripts), iframes-কে স্যান্ডবক্স করা এবং একটি মেসেজ কী করতে পারে তার সীমা নির্ধারণের মাধ্যমে ক্ষতিকারক HTML থেকে সুরক্ষা দিয়ে আসছে। এই ব্যবস্থাগুলো JavaScript বা এমবেডেড অবজেক্টের ওপর নির্ভরশীল ক্লাসিক আক্রমণগুলোকে থামিয়ে দেয়। তবে, CSS-কে সবসময়ই ক্ষতিকারক নয় এমন একটি প্রেজেন্টেশন কোড হিসেবে বিবেচনা করা হয়েছে। এর উন্নত সিলেক্টর—যেমন attribute selectors, container queries এবং অন্যান্য—কোনো স্ক্রিপ্টিং ছাড়াই একটি পেজকে DOM কাঠামোর সাথে প্রতিক্রিয়া জানাতে সাহায্য করে।
Black Hat-এর ডেমো প্রমাণ করেছে যে এই "ক্ষতিহীন" সিলেক্টরগুলো ডেটা লিক করার একটি সাইড-চ্যানেল (side-channel) হয়ে উঠতে পারে। নির্দিষ্ট কিছু লুকানো এলিমেন্ট থাকলে কেবল তখনই প্রযোজ্য হবে এমন স্টাইল রুল তৈরি করার মাধ্যমে আক্রমণকারীরা টেক্সটকে ব্যবহারকারীর কাছে অদৃশ্য করে ফেলে, কিন্তু রেন্ডার করা পেজে তা থেকে যায় যা একটি AI এজেন্ট পার্স (parse) করে।
আক্রমণগুলো কীভাবে কাজ করে
একটি প্রুফ-অফ-কনসেপ্টে এমন একটি ইমেল পাঠানো হয়েছিল যা প্রাপকের কাছে সাধারণ মনে হয়েছিল। এর ভেতরে লুকানো ছিল CSS রুলস, যা নির্দিষ্ট টেক্সটের রঙ ব্যাকগ্রাউন্ডের সাথে মিলিয়ে দিয়ে সেটিকে কার্যত ঢেকে (cloaking) ফেলেছিল। একজন মানুষ কখনোই সেই টেক্সট দেখতে পায় না, কিন্তু একটি AI এজেন্ট যা DOM বা accessibility tree এক্সট্র্যাক্ট করে, সে কোনো ভিজ্যুয়াল ফিল্টার প্রয়োগ করে না। যখন এজেন্টটি ইমেলটি প্রসেস করে, তখন সে সেই লুকানো টেক্সটটি পড়ে ফেলে এবং একটি URL fragment-এর মাধ্যমে তা পাঠিয়ে দেয়—যা সাধারণত ব্রাউজার পেজ লোড করার সময় উপেক্ষা করে।
আরেকটি ভেরিয়েন্ট ছিল ইনডাইরেক্ট প্রম্পট ইনজেকশন (indirect prompt injection)। ইমেলটিতে একটি লুকানো Slack টোকেন ছিল। CSS টোকেনটিকে ব্যবহারকারীর কাছে অদৃশ্য করে রেখেছিল কিন্তু মার্কআপে তা রেখে দিয়েছিল। AI এজেন্ট, যা ইমেলে থাকা নির্দেশাবলী অনুসরণ করার জন্য প্রশিক্ষিত, সেই টোকেনটিকে একটি কমান্ড হিসেবে ব্যাখ্যা করে এবং সেটি আক্রমণকারীর সার্ভারে পাঠিয়ে দেয়।
উভয় আক্রমণই জনপ্রিয় প্রোভাইডারদের বিরুদ্ধে সফল হয়েছে, যা প্রমাণ করে যে এই দুর্বলতাটি CSS রেন্ডার করার মৌলিক পদ্ধতির কারণে তৈরি হয়েছে, কোনো একটি নির্দিষ্ট প্ল্যাটফর্মের বাস্তবায়নের কারণে নয়।
AI এজেন্ট বনাম মানুষের পাঠকদের তুলনা
মানুষ সহজাতভাবেই এমন টেক্সট উপেক্ষা করে যা তারা দেখতে পায় না; আমরা ভিজ্যুয়াল লেআউটের ওপর বিশ্বাস করি। অন্যদিকে, AI এজেন্টগুলো র (raw) DOM বা একটি accessibility tree-র ওপর ভিত্তি করে কাজ করে যা ভিজ্যুয়াল স্টেট নির্বিশেষে প্রতিটি এলিমেন্ট রেকর্ড করে। যখন একটি AI কোনো পেজ পড়ে, তখন সে "যদি আমি এটি দেখতে না পাই, তবে আমি এটি উপেক্ষা করব" — এই নিয়মটি মেনে চলে না। এই অমিল একটি অন্ধস্থান (blind spot) তৈরি করে: মানুষের ব্যবহারের জন্য তৈরি করা স্যানিটাইজেশন পাইপলাইনগুলো স্বয়ংক্রিয় পাঠকদের জন্য আর নিরাপত্তার নিশ্চয়তা দেয় না।
সমস্যাটি কোনো নতুন AI ত্রুটি নয়। এটি একটি পুরনো ওয়েব ত্রুটি—কোড ছাড়াই লেআউট পরিবর্তন করার CSS-এর ক্ষমতা—যা একটি নতুন ধরনের ব্যবহারকারীর মুখোমুখি হয়েছে। যে কোনো পরিষেবা যা ইমেল কন্টেন্ট কোনো AI-চালিত অ্যাসিস্ট্যান্ট, সামারাইজার বা ক্লাসিফায়ারের কাছে হস্তান্তর করে, তারা এখন এই ঝুঁকির সম্মুখীন যে অ্যাসিস্ট্যান্ট এমন ডেটা নিয়ে কাজ করতে পারে যা একজন মানুষ কখনোই দেখবে না।
প্রতিরক্ষার জন্য কে দায়ী?
এই আক্রমণগুলো একটি এখতিয়ারগত (jurisdictional) প্রশ্ন উত্থাপন করে। ওয়েবমেইল প্রদানকারীরা ইতিমধ্যে মানুষের সুরক্ষার জন্য HTML পরিষ্কার করে; ব্রাউজারগুলো রেন্ডারিংয়ের জন্য ইতিমধ্যে একই নিয়ম প্রয়োগ করে। তবুও, এই স্তরগুলোর কোনটিই পরবর্তী ধাপের (downstream) AI-এর কথা বিবেচনা করে না যা একই মার্কআপ পার্স করবে। ইমেল পরিষেবার কি আরও গভীর CSS স্যানিটাইজেশন যোগ করা উচিত? ব্রাউজারগুলোর কি এমন কোনো ফ্ল্যাগ প্রকাশ করা উচিত যা এলিমেন্টগুলোকে "স্ক্রিপ্টের কাছে অদৃশ্য" হিসেবে চিহ্নিত করবে? নাকি AI ভেন্ডরদের এমন ফিল্টার তৈরি করতে হবে যা প্রসেসিং করার আগে লুকানো নোডগুলোকে বাদ দিয়ে দেবে?
AI-চালিত ইমেল টুল তৈরি করা সিকিউরিটি টিমগুলোকে ইনবক্সে পৌঁছানো HTML-এর পাশাপাশি সম্পূর্ণ রেন্ডারিং পাইপলাইন অডিট করার পরামর্শ দেওয়া হচ্ছে। এর মানে হলো CSS প্রয়োগ করার পর DOM পরীক্ষা করা, accessibility tree পরিদর্শন করা এবং মানুষের চোখে দৃশ্যমান নয় এমন যেকোনো কন্টেন্ট স্পষ্টভাবে সরিয়ে ফেলা বা ফ্ল্যাগ করা।
পরবর্তীতে কী লক্ষ্য রাখতে হবে
- ভেন্ডর টেস্টিং (Vendor testing) – AI ভেন্ডরদের তাদের টেস্ট সুইটে বাস্তব জগতের CSS অ্যাটাক ভেক্টর অন্তর্ভুক্ত করার কথা প্রত্যাশা করা হচ্ছে। ওয়েবের ত্রিশ বছরের দুর্বলতা গবেষণা রয়েছে; AI এজেন্টের মাত্র কয়েক বছর।
যদি একটি AI অ্যাসিস্ট্যান্টকে কেবল CSS দিয়ে টেক্সট লুকিয়ে বিভ্রান্ত করে ক্রেডেনশিয়াল (credentials) ফাঁস করানো সম্ভব হয়, তবে আজকের ইনবক্স রক্ষাকারী নিরাপত্তা মডেলটি আর যথেষ্ট নয়। ডেভেলপার, প্রদানকারী এবং নিয়ন্ত্রক সংস্থাগুলোকে যেকোনো স্বয়ংক্রিয় ব্যবহারকারীর জন্য কেবল র (raw) HTML নয়, বরং রেন্ডার করা পেজকেই নিরাপত্তার সীমানা হিসেবে বিবেচনা করতে হবে। লুকানো টেক্সটের সমস্যাটি আমাদের মনে করিয়ে দেয় যে, যে প্রযুক্তি একসময় কেবল "স্টাইলিং"-এর জন্য ব্যবহৃত হতো, তা ডেটা চুরির মাধ্যম হয়ে উঠতে পারে। প্রতিরক্ষার পরবর্তী ঢেউকে CSS-কে কেবল একটি ভিজ্যুয়াল সহায়তা হিসেবে নয়, বরং একটি সম্ভাব্য অ্যাটাক সারফেস (attack surface) হিসেবে চিনতে হবে।
