অনেক ওয়েব অ্যাপ্লিকেশনে ব্যবহারকারী-নিয়ন্ত্রিত কন্টেন্ট প্রদর্শন করার প্রয়োজন হয়। এটি ব্যবহারকারীর আপলোড করা ছবি (যেমন, প্রোফাইল ফটো) দেখানোর মতো সহজ হতে পারে, অথবা ব্যবহারকারী-নিয়ন্ত্রিত এইচটিএমএল (HTML) রেন্ডার করার মতো জটিলও হতে পারে (যেমন, একটি ওয়েব ডেভেলপমেন্ট টিউটোরিয়াল)। এই কাজটি নিরাপদে করা সবসময়ই কঠিন ছিল, তাই আমরা এমন সহজ অথচ নিরাপদ সমাধান খুঁজে বের করার চেষ্টা করেছি যা বেশিরভাগ ধরনের ওয়েব অ্যাপ্লিকেশনে প্রয়োগ করা যায়।
অবিশ্বস্ত বিষয়বস্তু বিচ্ছিন্ন করার প্রচলিত সমাধান
ব্যবহারকারী-নিয়ন্ত্রিত কন্টেন্ট নিরাপদে পরিবেশন করার ক্লাসিক সমাধান হলো স্যান্ডবক্স ডোমেইন ব্যবহার করা। এর মূল ধারণাটি হলো, যদি আপনার অ্যাপ্লিকেশনের প্রধান ডোমেইন example.com হয়, তবে আপনি সমস্ত অবিশ্বস্ত কন্টেন্ট exampleusercontent.com এ পরিবেশন করতে পারেন। যেহেতু এই দুটি ডোমেইন ক্রস-সাইট , তাই exampleusercontent.com এর কোনো ক্ষতিকর কন্টেন্ট example.com প্রভাবিত করতে পারে না। এই পদ্ধতিটি ছবি, ডাউনলোড এবং HTML সহ সব ধরনের অবিশ্বস্ত কন্টেন্ট নিরাপদে পরিবেশন করতে ব্যবহার করা যেতে পারে। যদিও ছবি বা ডাউনলোডের জন্য এটি ব্যবহার করা প্রয়োজনীয় মনে নাও হতে পারে, তবে এটি করলে কন্টেন্ট স্নিফিং থেকে ঝুঁকি এড়ানো যায়, বিশেষ করে পুরোনো ব্রাউজারগুলোতে। স্যান্ডবক্স ডোমেইনগুলো ইন্ডাস্ট্রিতে ব্যাপকভাবে ব্যবহৃত হয় এবং দীর্ঘদিন ধরে ভালোভাবে কাজ করে আসছে। কিন্তু, এগুলোর দুটি প্রধান অসুবিধা রয়েছে:
- অ্যাপ্লিকেশনগুলিতে প্রায়শই একজন ব্যবহারকারীর জন্য কন্টেন্ট অ্যাক্সেস সীমাবদ্ধ করার প্রয়োজন হয়, যার জন্য অথেন্টিকেশন এবং অথরাইজেশন বাস্তবায়ন করা আবশ্যক। যেহেতু স্যান্ডবক্স ডোমেইনগুলি ইচ্ছাকৃতভাবে মূল অ্যাপ্লিকেশন ডোমেইনের সাথে কুকি শেয়ার করে না, তাই এটি নিরাপদে করা খুব কঠিন। অথেন্টিকেশন সমর্থন করার জন্য, সাইটগুলিকে হয় ক্যাপাবিলিটি ইউআরএল (capability URLs)- এর উপর নির্ভর করতে হয়, অথবা স্যান্ডবক্স ডোমেইনের জন্য আলাদা অথেন্টিকেশন কুকি সেট করতে হয়। এই দ্বিতীয় পদ্ধতিটি আধুনিক ওয়েবে বিশেষভাবে সমস্যাজনক, যেখানে অনেক ব্রাউজার ডিফল্টরূপে ক্রস-সাইট কুকি সীমাবদ্ধ করে রাখে।
- যদিও ব্যবহারকারীর কন্টেন্ট মূল সাইট থেকে বিচ্ছিন্ন থাকে, এটি অন্যান্য ব্যবহারকারীর কন্টেন্ট থেকে বিচ্ছিন্ন থাকে না। এর ফলে ক্ষতিকর ব্যবহারকারীর কন্টেন্ট দ্বারা স্যান্ডবক্স ডোমেইনের অন্যান্য ডেটাকে আক্রমণ করার ঝুঁকি তৈরি হয় (উদাহরণস্বরূপ, একই-অরিজিন ডেটা পড়ার মাধ্যমে)।
এটিও উল্লেখ্য যে, স্যান্ডবক্স ডোমেইন ফিশিং ঝুঁকি কমাতে সাহায্য করে, কারণ রিসোর্সগুলো একটি বিচ্ছিন্ন ডোমেইনে স্পষ্টভাবে বিভক্ত থাকে।
ব্যবহারকারীর কন্টেন্ট পরিবেশনের আধুনিক সমাধান
সময়ের সাথে সাথে ওয়েব বিকশিত হয়েছে, এবং এখন অবিশ্বস্ত কন্টেন্ট পরিবেশন করার আরও সহজ ও নিরাপদ উপায় রয়েছে। এক্ষেত্রে বিভিন্ন পদ্ধতি রয়েছে, তাই আমরা গুগলে ব্যবহৃত দুটি সমাধানের রূপরেখা তুলে ধরব।
পদ্ধতি ১: নিষ্ক্রিয় ব্যবহারকারীর কন্টেন্ট পরিবেশন করা
যদি কোনো সাইটকে শুধুমাত্র নিষ্ক্রিয় ব্যবহারকারীর কন্টেন্ট (অর্থাৎ, যে কন্টেন্ট HTML বা JavaScript নয়, যেমন ছবি এবং ডাউনলোড) পরিবেশন করার প্রয়োজন হয়, তবে এখন একটি বিচ্ছিন্ন স্যান্ডবক্স ডোমেইন ছাড়াই এটি নিরাপদে করা যেতে পারে। এর জন্য দুটি মূল ধাপ রয়েছে:
- সর্বদা
Content-Typeহেডারটি এমন একটি সুপরিচিত MIME টাইপে সেট করুন যা সকল ব্রাউজার দ্বারা সমর্থিত এবং যাতে কোনো সক্রিয় কন্টেন্ট নেই। সন্দেহ থাকলে,application/octet-streamএকটি নিরাপদ বিকল্প। - এছাড়াও, ব্রাউজার যাতে রেসপন্সটিকে সম্পূর্ণরূপে আলাদা করতে পারে, তা নিশ্চিত করার জন্য সর্বদা রেসপন্স হেডার সেট করুন।
| প্রতিক্রিয়া হেডার | উদ্দেশ্য |
|---|---|
X-Content-Type-Options: nosniff | বিষয়বস্তু আড়িপাতা প্রতিরোধ করে |
Content-Disposition: attachment; filename="download" | রেন্ডারিংয়ের পরিবর্তে ডাউনলোড শুরু করে |
Content-Security-Policy: sandbox | কন্টেন্টকে এমনভাবে স্যান্ডবক্স করে যেন এটি একটি পৃথক ডোমেনে পরিবেশন করা হচ্ছে। |
Content-Security-Policy: default-src ‘none' | জাভাস্ক্রিপ্ট নির্বাহ (এবং যেকোনো সাবরিসোর্সের অন্তর্ভুক্তি) নিষ্ক্রিয় করে। |
Cross-Origin-Resource-Policy: same-site | পৃষ্ঠাটিকে একাধিক সাইটে অন্তর্ভুক্ত হওয়া থেকে বিরত রাখে। |
হেডারগুলোর এই সংমিশ্রণটি নিশ্চিত করে যে, রেসপন্সটি শুধুমাত্র আপনার অ্যাপ্লিকেশন দ্বারা একটি সাবরিসোর্স হিসেবে লোড করা যাবে, অথবা ব্যবহারকারী দ্বারা একটি ফাইল হিসেবে ডাউনলোড করা যাবে। অধিকন্তু, হেডারগুলো CSP স্যান্ডবক্স হেডার এবং default-src বিধিনিষেধের মাধ্যমে ব্রাউজারের বাগগুলোর বিরুদ্ধে একাধিক স্তরের সুরক্ষা প্রদান করে। সার্বিকভাবে, বর্ণিত এই ব্যবস্থাটি এই বিষয়ে উচ্চ মাত্রার নিশ্চয়তা দেয় যে, এইভাবে পরিবেশিত রেসপন্সগুলো ইনজেকশন বা আইসোলেশন দুর্বলতার কারণ হতে পারে না।
গভীর প্রতিরক্ষা
যদিও প্রস্তাবিত সমাধানটি XSS-এর বিরুদ্ধে সাধারণভাবে যথেষ্ট প্রতিরক্ষা ব্যবস্থা, তবুও নিরাপত্তার অতিরিক্ত স্তর প্রদানের জন্য আপনি আরও বেশ কিছু শক্তিশালীকরণ ব্যবস্থা প্রয়োগ করতে পারেন:
- IE11-এর সাথে সামঞ্জস্যের জন্য একটি
X-Content-Security-Policy: sandboxহেডার সেট করুন। - এন্ডপয়েন্টটিকে এমবেড করা থেকে ব্লক করতে একটি
Content-Security-Policy: frame-ancestors 'none'হেডার সেট করুন। - একটি বিচ্ছিন্ন সাবডোমেনে ব্যবহারকারীর কন্টেন্ট স্যান্ডবক্স করুন:
- একটি বিচ্ছিন্ন সাবডোমেনে ব্যবহারকারীর কন্টেন্ট পরিবেশন করা (যেমন গুগল
product.usercontent.google.comএর মতো ডোমেন ব্যবহার করে)। - ক্রস- অরিজিন আইসোলেশন সক্রিয় করতে
Cross-Origin-Opener-Policy: same-originএবংCross-Origin-Embedder-Policy: require-corpসেট করুন।
- একটি বিচ্ছিন্ন সাবডোমেনে ব্যবহারকারীর কন্টেন্ট পরিবেশন করা (যেমন গুগল
পদ্ধতি ২: সক্রিয় ব্যবহারকারীকে কন্টেন্ট পরিবেশন করা
ক্লাসিক স্যান্ডবক্স ডোমেইন পদ্ধতির দুর্বলতাগুলো ছাড়াই সক্রিয় কন্টেন্ট (যেমন, HTML বা SVG ছবি) নিরাপদে পরিবেশন করা সম্ভব।
সবচেয়ে সহজ উপায় হলো Content-Security-Policy: sandbox হেডারটি ব্যবহার করে ব্রাউজারকে রেসপন্সটি আলাদা করতে বলা। যদিও সব ওয়েব ব্রাউজার স্যান্ডবক্স ডকুমেন্টের জন্য প্রসেস আইসোলেশন প্রয়োগ করে না, ব্রাউজার প্রসেস মডেলের চলমান উন্নতি সম্ভবত এমবেডিং অ্যাপ্লিকেশন থেকে স্যান্ডবক্সড কন্টেন্টের পৃথকীকরণকে আরও উন্নত করবে। যদি SpectreJS এবং রেন্ডারার কম্প্রোমাইজ অ্যাটাক আপনার থ্রেট মডেলের বাইরে থাকে, তাহলে CSP স্যান্ডবক্স ব্যবহার করাই সম্ভবত একটি যথেষ্ট সমাধান। গুগলে, আমরা স্যান্ডবক্স ডোমেইনের ধারণাটিকে আধুনিকীকরণের মাধ্যমে এমন একটি সমাধান তৈরি করেছি যা অবিশ্বস্ত সক্রিয় কন্টেন্টকে সম্পূর্ণরূপে আলাদা করতে পারে। এর মূল ধারণাটি হলো:
- একটি নতুন স্যান্ডবক্স ডোমেইন তৈরি করুন যা পাবলিক সাফিক্স লিস্টে ( PSL) যুক্ত করা হয়েছে। উদাহরণস্বরূপ,
exampleusercontent.comPSL-এ যুক্ত করার মাধ্যমে, আপনি নিশ্চিত করতে পারেন যেfoo.exampleusercontent.comএবংbar.exampleusercontent.comক্রস-সাইট হবে এবং এর ফলে একে অপরের থেকে সম্পূর্ণ বিচ্ছিন্ন থাকবে। -
*.exampleusercontent.com/shimসাথে মিলে যাওয়া URL-গুলো একটি স্ট্যাটিক শিম ফাইলে রাউট করা হয়। এই শিম ফাইলটিতে একটি সংক্ষিপ্ত HTML এবং জাভাস্ক্রিপ্ট কোড থাকে, যাmessageইভেন্ট হ্যান্ডলার শোনে এবং প্রাপ্ত যেকোনো কন্টেন্ট রেন্ডার করে। - এটি ব্যবহার করার জন্য, প্রোডাক্টটি
$RANDOM_VALUE.exampleusercontent.com/shimএ একটি আইফ্রেম বা ডায়ালগ তৈরি করে এবং রেন্ডারিংয়ের জন্যpostMessageব্যবহার করে অবিশ্বস্ত কন্টেন্টটি শিম-এ পাঠায়। - রেন্ডার করা কন্টেন্টকে একটি ব্লবে রূপান্তরিত করে একটি স্যান্ডবক্সড আইফ্রেমের ভিতরে রেন্ডার করা হয়।
ক্লাসিক স্যান্ডবক্স ডোমেইন পদ্ধতির তুলনায়, এটি নিশ্চিত করে যে সমস্ত কন্টেন্ট একটি স্বতন্ত্র সাইটে সম্পূর্ণরূপে বিচ্ছিন্ন থাকে। এবং, রেন্ডার করার জন্য ডেটা পুনরুদ্ধারের কাজটি মূল অ্যাপ্লিকেশন দ্বারা পরিচালিত হওয়ায়, ক্যাপাবিলিটি ইউআরএল ব্যবহার করার আর প্রয়োজন হয় না।
উপসংহার
একসাথে, এই দুটি সমাধান googleusercontent.com এর মতো ক্লাসিক স্যান্ডবক্স ডোমেইন থেকে সরে এসে থার্ড-পার্টি কুকি ব্লক করার উপযোগী আরও সুরক্ষিত সমাধানে স্থানান্তরিত হওয়া সম্ভব করে তোলে। গুগলে, আমরা ইতোমধ্যেই অনেক প্রোডাক্টকে এই সমাধানগুলো ব্যবহার করার জন্য স্থানান্তরিত করেছি এবং আগামী বছরের জন্য আরও স্থানান্তরের পরিকল্পনা রয়েছে।