অনেক ওয়েব অ্যাপ্লিকেশন ব্যবহারকারী-নিয়ন্ত্রিত সামগ্রী প্রদর্শন করতে হবে। এটি ব্যবহারকারীর আপলোড করা ছবি (উদাহরণস্বরূপ, প্রোফাইল ফটো) পরিবেশন করার মতো সহজ বা ব্যবহারকারী-নিয়ন্ত্রিত HTML (উদাহরণস্বরূপ, একটি ওয়েব ডেভেলপমেন্ট টিউটোরিয়াল) রেন্ডার করার মতো জটিল হতে পারে। এটি নিরাপদে করা সবসময়ই কঠিন ছিল, তাই আমরা সহজ, কিন্তু নিরাপদ সমাধান খুঁজে বের করার জন্য কাজ করেছি যা বেশিরভাগ ধরনের ওয়েব অ্যাপ্লিকেশনে প্রয়োগ করা যেতে পারে।
অবিশ্বস্ত কন্টেন্ট আলাদা করার জন্য ক্লাসিক সমাধান
নিরাপদে ব্যবহারকারী-নিয়ন্ত্রিত বিষয়বস্তু পরিবেশনের জন্য ক্লাসিক সমাধান হল স্যান্ডবক্স ডোমেন হিসাবে পরিচিত যা ব্যবহার করা। মূল ধারণা হল যে যদি আপনার অ্যাপ্লিকেশনের প্রধান ডোমেন হয় example.com , তাহলে আপনি exampleusercontent.com এ সমস্ত অবিশ্বস্ত সামগ্রী পরিবেশন করতে পারেন। যেহেতু এই দুটি ডোমেইন ক্রস-সাইট , তাই exampleusercontent.com এর কোনো ক্ষতিকারক বিষয়বস্তু example.com প্রভাবিত করতে পারে না।
এই পদ্ধতিটি ছবি, ডাউনলোড এবং এইচটিএমএল সহ সমস্ত ধরণের অবিশ্বস্ত সামগ্রী নিরাপদে পরিবেশন করতে ব্যবহার করা যেতে পারে। ছবি বা ডাউনলোডের জন্য এটি ব্যবহার করা প্রয়োজন বলে মনে না হলেও, এটি করা বিষয়বস্তু স্নিফিং থেকে ঝুঁকি এড়াতে সাহায্য করে, বিশেষ করে লিগ্যাসি ব্রাউজারগুলিতে।
স্যান্ডবক্স ডোমেনগুলি শিল্প জুড়ে ব্যাপকভাবে ব্যবহৃত হয় এবং দীর্ঘদিন ধরে ভাল কাজ করেছে। তবে, তাদের দুটি প্রধান নেতিবাচক দিক রয়েছে:
- অ্যাপ্লিকেশানগুলিকে প্রায়শই একক ব্যবহারকারীর জন্য সামগ্রী অ্যাক্সেস সীমাবদ্ধ করতে হয়, যার জন্য প্রমাণীকরণ এবং অনুমোদন প্রয়োগ করা প্রয়োজন। যেহেতু স্যান্ডবক্স ডোমেন উদ্দেশ্যমূলকভাবে মূল অ্যাপ্লিকেশন ডোমেনের সাথে কুকি ভাগ করে না, তাই এটি নিরাপদে করা খুব কঠিন। প্রমাণীকরণ সমর্থন করার জন্য, সাইটগুলিকে হয় সক্ষমতা URL এর উপর নির্ভর করতে হবে, অথবা তাদের স্যান্ডবক্স ডোমেনের জন্য পৃথক প্রমাণীকরণ কুকি সেট করতে হবে৷ এই দ্বিতীয় পদ্ধতিটি আধুনিক ওয়েবে বিশেষত সমস্যাযুক্ত যেখানে অনেক ব্রাউজার ক্রস-সাইট কুকিজ ডিফল্টরূপে সীমাবদ্ধ করে।
- ব্যবহারকারীর বিষয়বস্তু মূল সাইট থেকে বিচ্ছিন্ন হলেও, এটি অন্য ব্যবহারকারীর সামগ্রী থেকে বিচ্ছিন্ন নয়৷ এটি স্যান্ডবক্স ডোমেনের (উদাহরণস্বরূপ, একই-অরিজিন ডেটা পড়ার মাধ্যমে) ক্ষতিকারক ব্যবহারকারী সামগ্রীর অন্যান্য ডেটা আক্রমণ করার ঝুঁকি তৈরি করে।
এটাও লক্ষণীয় যে স্যান্ডবক্স ডোমেনগুলি ফিশিং ঝুঁকি কমাতে সাহায্য করে যেহেতু সম্পদগুলি স্পষ্টভাবে একটি বিচ্ছিন্ন ডোমেনে বিভক্ত।
ব্যবহারকারীর বিষয়বস্তু পরিবেশনের জন্য আধুনিক সমাধান
সময়ের সাথে সাথে ওয়েব বিকশিত হয়েছে, এবং এখন অবিশ্বস্ত সামগ্রী পরিবেশন করার জন্য আরও সহজ, আরও নিরাপদ উপায় রয়েছে৷ এখানে অনেকগুলি ভিন্ন পন্থা রয়েছে, তাই আমরা দুটি সমাধানের রূপরেখা দেব যা বর্তমানে Google এ ব্যাপকভাবে ব্যবহৃত হচ্ছে।
পদ্ধতি 1: নিষ্ক্রিয় ব্যবহারকারী সামগ্রী পরিবেশন করা
যদি একটি সাইট শুধুমাত্র নিষ্ক্রিয় ব্যবহারকারীর সামগ্রী (এটি এমন সামগ্রী যা 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 এর বিরুদ্ধে একটি সাধারণভাবে পর্যাপ্ত প্রতিরক্ষার প্রতিনিধিত্ব করে, সেখানে বেশ কয়েকটি অতিরিক্ত কঠোর ব্যবস্থা রয়েছে যা আপনি সুরক্ষার অতিরিক্ত স্তর সরবরাহ করতে প্রয়োগ করতে পারেন:
- একটি
X-Content-Security-Policy: sandboxহেডার। - একটি
Content-Security-Policy: frame-ancestors 'none'হেডার। - একটি বিচ্ছিন্ন সাবডোমেনে স্যান্ডবক্স ব্যবহারকারীর সামগ্রী এর দ্বারা:
- একটি বিচ্ছিন্ন সাবডোমেনে ব্যবহারকারীর সামগ্রী পরিবেশন করা (যেমন Google
product.usercontent.google.comএর মতো ডোমেন ব্যবহার করে)। -
Cross-Origin-Opener-Policy: same-originএবং ক্রস-অরিজিন-এমবেডার-নীতি: ক্রস-অরিজিন আইসোলেশন সক্ষম করতেCross-Origin-Embedder-Policy: require-corp।
- একটি বিচ্ছিন্ন সাবডোমেনে ব্যবহারকারীর সামগ্রী পরিবেশন করা (যেমন Google
পদ্ধতি 2: সক্রিয় ব্যবহারকারী সামগ্রী পরিবেশন করা
নিরাপদে সক্রিয় সামগ্রী পরিবেশন করা (উদাহরণস্বরূপ, HTML বা SVG ছবি) ক্লাসিক স্যান্ডবক্স ডোমেন পদ্ধতির দুর্বলতা ছাড়াই করা যেতে পারে।
সহজ বিকল্প হল Content-Security-Policy: sandbox শিরোনাম ব্রাউজারকে প্রতিক্রিয়া আলাদা করতে বলুন। যদিও সমস্ত ওয়েব ব্রাউজার বর্তমানে স্যান্ডবক্স নথিগুলির জন্য প্রক্রিয়া বিচ্ছিন্নতা প্রয়োগ করে না, ব্রাউজার প্রক্রিয়া মডেলগুলিতে চলমান পরিমার্জনগুলি এম্বেডিং অ্যাপ্লিকেশনগুলি থেকে স্যান্ডবক্সযুক্ত সামগ্রীর পৃথকীকরণকে উন্নত করতে পারে৷ যদি SpectreJS এবং রেন্ডারার আপস আক্রমণ আপনার হুমকি মডেলের বাইরে হয়, তাহলে CSP স্যান্ডবক্স ব্যবহার করা সম্ভবত একটি যথেষ্ট সমাধান।
Google-এ, আমরা একটি সমাধান তৈরি করেছি যা স্যান্ডবক্স ডোমেনের ধারণাকে আধুনিকীকরণ করে অবিশ্বস্ত সক্রিয় সামগ্রীকে সম্পূর্ণরূপে আলাদা করতে পারে৷ মূল ধারণা হল:
- একটি নতুন স্যান্ডবক্স ডোমেন তৈরি করুন যা সর্বজনীন প্রত্যয় তালিকায় যোগ করা হয়েছে। উদাহরণস্বরূপ, PSL-এ
exampleusercontent.comযোগ করে, আপনি নিশ্চিত করতে পারেন যেfoo.exampleusercontent.comএবংbar.exampleusercontent.comক্রস-সাইট এবং এইভাবে একে অপরের থেকে সম্পূর্ণ বিচ্ছিন্ন। -
*.exampleusercontent.com/shimএর সাথে মিলে যাওয়া ইউআরএলগুলিকে একটি স্ট্যাটিক শিম ফাইলে রাউট করা হয়েছে৷ এই শিম ফাইলটিতে একটি ছোট এইচটিএমএল এবং জাভাস্ক্রিপ্ট স্নিপেট রয়েছে যাmessageইভেন্ট হ্যান্ডলারের কথা শোনে এবং এটি প্রাপ্ত যেকোনো সামগ্রী রেন্ডার করে। - এটি ব্যবহার করার জন্য, পণ্যটি
$RANDOM_VALUE.exampleusercontent.com/shimএ একটি আইফ্রেম বা একটি পপআপ তৈরি করে এবং রেন্ডারিংয়ের জন্য শিমে অবিশ্বস্ত সামগ্রী পাঠাতেpostMessageব্যবহার করে। - রেন্ডার করা বিষয়বস্তু একটি ব্লবে রূপান্তরিত হয় এবং একটি স্যান্ডবক্সড আইফ্রেমের মধ্যে রেন্ডার করা হয়।
ক্লাসিক স্যান্ডবক্স ডোমেন পদ্ধতির তুলনায়, এটি নিশ্চিত করে যে সমস্ত সামগ্রী একটি অনন্য সাইটে সম্পূর্ণরূপে বিচ্ছিন্ন। এবং, রেন্ডার করা ডেটা পুনরুদ্ধারের সাথে মূল অ্যাপ্লিকেশন চুক্তি করে, সক্ষমতা URL ব্যবহার করার আর প্রয়োজন নেই।
উপসংহার
একসাথে, এই দুটি সমাধান googleusercontent.com এর মতো ক্লাসিক স্যান্ডবক্স ডোমেন থেকে আরও নিরাপদ সমাধানে স্থানান্তরিত করা সম্ভব করে যা তৃতীয়-পক্ষ কুকি ব্লকিংয়ের সাথে সামঞ্জস্যপূর্ণ। Google-এ, আমরা ইতিমধ্যেই এই সমাধানগুলি ব্যবহার করার জন্য অনেকগুলি পণ্য স্থানান্তর করেছি এবং আগামী বছরের জন্য আরও স্থানান্তরের পরিকল্পনা করেছি৷