SharedArrayBuffer , performance.measureUserAgentSpecificMemory() এবং হাই রেজোলিউশন টাইমারের মতো শক্তিশালী ফিচারগুলো আরও ভালোভাবে ব্যবহারের জন্য কেন ক্রস-অরিজিন আইসোলেশন প্রয়োজন, তা জানুন।
ভূমিকা
“COOP এবং COEP ব্যবহার করে আপনার ওয়েবসাইটকে ‘ক্রস-অরিজিন আইসোলেটেড’ করা” শীর্ষক লেখায় আমরা ব্যাখ্যা করেছি কিভাবে COOP এবং COEP ব্যবহার করে ‘ক্রস-অরিজিন আইসোলেটেড’ অবস্থা গ্রহণ করতে হয়। এটি একটি সহায়ক নিবন্ধ যা ব্যাখ্যা করে কেন ব্রাউজারে শক্তিশালী বৈশিষ্ট্যগুলি সক্ষম করার জন্য ক্রস-অরিজিন আইসোলেশন প্রয়োজন।
পটভূমি
ওয়েব ‘সেম-অরিজিন পলিসি’র উপর নির্মিত: এটি একটি নিরাপত্তা বৈশিষ্ট্য যা ডকুমেন্ট এবং স্ক্রিপ্টগুলো কীভাবে অন্য অরিজিনের রিসোর্সের সাথে যোগাযোগ করতে পারে, তা সীমাবদ্ধ করে। এই নীতিটি ওয়েবসাইটগুলোর ক্রস-অরিজিন রিসোর্স অ্যাক্সেস করার পদ্ধতিকে সীমিত করে। উদাহরণস্বরূপ, https://a.example থেকে আসা কোনো ডকুমেন্টকে https://b.example এ হোস্ট করা ডেটা অ্যাক্সেস করতে বাধা দেওয়া হয়।
তবে, একই-উৎস নীতির কিছু ঐতিহাসিক ব্যতিক্রম রয়েছে। যেকোনো ওয়েবসাইট পারে:
- ক্রস-অরিজিন আইফ্রেম এম্বেড করুন
- ছবি বা স্ক্রিপ্টের মতো বিভিন্ন উৎস থেকে প্রাপ্ত রিসোর্স অন্তর্ভুক্ত করুন।
- DOM রেফারেন্স সহ ক্রস-অরিজিন পপআপ উইন্ডো খুলুন
ওয়েবকে যদি একেবারে গোড়া থেকে ডিজাইন করা যেত, তাহলে এই ব্যতিক্রমগুলোর অস্তিত্ব থাকত না। দুর্ভাগ্যবশত, ওয়েব কমিউনিটি যখন একটি কঠোর সেম-অরিজিন পলিসির মূল সুবিধাগুলো উপলব্ধি করল, ততক্ষণে ওয়েব ইতিমধ্যেই এই ব্যতিক্রমগুলোর ওপর নির্ভর করতে শুরু করেছিল।
এই ধরনের শিথিল সেম-অরিজিন পলিসির নিরাপত্তাজনিত পার্শ্বপ্রতিক্রিয়া দুটি উপায়ে সমাধান করা হয়েছিল। একটি উপায় ছিল ক্রস অরিজিন রিসোর্স শেয়ারিং (CORS) নামক একটি নতুন প্রোটোকল চালু করা, যার উদ্দেশ্য হলো সার্ভার যেন একটি নির্দিষ্ট অরিজিনের সাথে রিসোর্স শেয়ার করার অনুমতি দেয় তা নিশ্চিত করা। অন্য উপায়টি হলো ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রেখে ক্রস-অরিজিন রিসোর্সগুলিতে সরাসরি স্ক্রিপ্ট অ্যাক্সেস পরোক্ষভাবে বন্ধ করে দেওয়া। এই ধরনের ক্রস-অরিজিন রিসোর্সগুলিকে "ওপেক" রিসোর্স বলা হয়। উদাহরণস্বরূপ, এই কারণেই CanvasRenderingContext2D মাধ্যমে একটি ক্রস-অরিজিন ইমেজের পিক্সেল পরিবর্তন করার চেষ্টা ব্যর্থ হয়, যদি না ইমেজটিতে CORS প্রয়োগ করা হয়।
এই সমস্ত নীতিগত সিদ্ধান্ত একটি ব্রাউজিং কনটেক্সট গ্রুপের মধ্যে নেওয়া হচ্ছে।
দীর্ঘদিন ধরে, ব্রাউজারগুলোকে নিরাপদ রাখার জন্য CORS এবং অস্বচ্ছ রিসোর্সের সংমিশ্রণই যথেষ্ট ছিল। মাঝে মাঝে কিছু ব্যতিক্রমী পরিস্থিতি (যেমন JSON দুর্বলতা ) আবিষ্কৃত হতো এবং সেগুলোর জন্য প্যাচ করার প্রয়োজন পড়ত, কিন্তু সার্বিকভাবে ক্রস-অরিজিন রিসোর্সের মূল বাইটগুলোতে সরাসরি পঠন অ্যাক্সেসের অনুমতি না দেওয়ার নীতিটি সফল ছিল।
Spectre- এর মাধ্যমে এই সবকিছু বদলে গেছে, যা আপনার কোডের সাথে একই ব্রাউজিং কনটেক্সট গ্রুপে লোড হওয়া যেকোনো ডেটাকে সম্ভাব্য পাঠযোগ্য করে তোলে। নির্দিষ্ট কিছু অপারেশনের সময় পরিমাপ করে, আক্রমণকারীরা সিপিইউ ক্যাশের বিষয়বস্তু এবং তার মাধ্যমে প্রসেসের মেমরির বিষয়বস্তু অনুমান করতে পারে। এই ধরনের টাইমিং অ্যাটাক প্ল্যাটফর্মে বিদ্যমান লো-গ্র্যানুলারিটি টাইমার দিয়ে সম্ভব, কিন্তু হাই-গ্র্যানুলারিটি টাইমার, যেমন এক্সপ্লিসিট ( performance.now() এর মতো) এবং ইমপ্লিসিট ( SharedArrayBuffer এর মতো) উভয় প্রকার টাইমার দিয়ে একে আরও দ্রুত করা যায়। যদি evil.com একটি ক্রস-অরিজিন ইমেজ এমবেড করে, তবে তারা Spectre অ্যাটাক ব্যবহার করে এর পিক্সেল ডেটা পড়তে পারে, যা "অস্বচ্ছতা"-র উপর নির্ভরশীল সুরক্ষা ব্যবস্থাকে অকার্যকর করে তোলে।
আদর্শগতভাবে, সমস্ত ক্রস-অরিজিন অনুরোধ রিসোর্সটির মালিক সার্ভার দ্বারা সুস্পষ্টভাবে যাচাই করা উচিত। যদি রিসোর্স-মালিক সার্ভার এই যাচাইকরণ প্রদান না করে, তাহলে ডেটা কখনোই কোনো দুষ্কৃতকারীর ব্রাউজিং কনটেক্সট গ্রুপে পৌঁছাবে না, এবং ফলস্বরূপ একটি ওয়েব পেজ দ্বারা পরিচালিত যেকোনো স্পেক্টার আক্রমণের নাগালের বাইরে থাকবে। আমরা একে ক্রস-অরিজিন আইসোলেটেড স্টেট বলি। COOP+COEP ঠিক এই বিষয়টি নিয়েই কাজ করে।
একটি ক্রস-অরিজিন আইসোলেটেড অবস্থায়, অনুরোধকারী সাইটটিকে কম বিপজ্জনক বলে মনে করা হয় এবং এটি SharedArrayBuffer , performance.measureUserAgentSpecificMemory() এবং আরও ভালো নির্ভুলতার সাথে হাই-রেজোলিউশন টাইমারের মতো শক্তিশালী বৈশিষ্ট্যগুলোকে আনলক করে, যেগুলো অন্যথায় Spectre-এর মতো আক্রমণের জন্য ব্যবহার করা যেতে পারত। এটি document.domain পরিবর্তন করাও প্রতিরোধ করে।
ক্রস অরিজিন এমবেডার নীতি
ক্রস অরিজিন এমবেডার পলিসি (COEP) একটি ডকুমেন্টকে এমন কোনো ক্রস-অরিজিন রিসোর্স লোড করা থেকে বিরত রাখে, যার জন্য ডকুমেন্টটিকে (CORP বা CORS ব্যবহার করে) সুস্পষ্টভাবে অনুমতি দেওয়া হয়নি। এই ফিচারের মাধ্যমে, আপনি ঘোষণা করতে পারেন যে একটি ডকুমেন্ট এই ধরনের রিসোর্স লোড করতে পারবে না।
এই পলিসিটি সক্রিয় করতে, ডকুমেন্টটিতে নিম্নলিখিত HTTP হেডারটি যুক্ত করুন:
Cross-Origin-Embedder-Policy: require-corp
COEP-এর একটিমাত্র মান হলো require-corp । এটি এই নীতিটি প্রয়োগ করে যে, ডকুমেন্টটি শুধুমাত্র একই অরিজিন থেকে রিসোর্স লোড করতে পারবে, অথবা অন্য কোনো অরিজিন থেকে লোডযোগ্য হিসেবে স্পষ্টভাবে চিহ্নিত রিসোর্স লোড করতে পারবে।
অন্য অরিজিন থেকে রিসোর্স লোড করার জন্য, সেগুলোকে অবশ্যই ক্রস অরিজিন রিসোর্স শেয়ারিং (CORS) অথবা ক্রস অরিজিন রিসোর্স পলিসি (CORP) সমর্থন করতে হবে।
ক্রস অরিজিন রিসোর্স শেয়ারিং
যদি কোনো ক্রস অরিজিন রিসোর্স ক্রস অরিজিন রিসোর্স শেয়ারিং (CORS) সমর্থন করে, তাহলে আপনি COEP দ্বারা বাধাপ্রাপ্ত না হয়েই আপনার ওয়েব পেজে সেটি লোড করার জন্য crossorigin অ্যাট্রিবিউট ব্যবহার করতে পারেন।
<img src="https://third-party.example.com/image.jpg" crossorigin>
উদাহরণস্বরূপ, যদি এই ইমেজ রিসোর্সটি CORS হেডার সহ পরিবেশন করা হয়, তাহলে crossorigin অ্যাট্রিবিউটটি ব্যবহার করুন যাতে রিসোর্সটি ফেচ করার অনুরোধটি CORS মোড ব্যবহার করে। এটি CORS হেডার সেট না করা পর্যন্ত ইমেজটি লোড হওয়া থেকেও বিরত রাখে।
একইভাবে, আপনি fetch() মেথডের মাধ্যমে ক্রস-অরিজিন ডেটা ফেচ করতে পারেন, যার জন্য কোনো বিশেষ ব্যবস্থাপনার প্রয়োজন হয় না, যতক্ষণ পর্যন্ত সার্ভার সঠিক HTTP হেডারসহ সাড়া দেয়।
ক্রস অরিজিন রিসোর্স পলিসি
ক্রস অরিজিন রিসোর্স পলিসি (CORP) মূলত আপনার রিসোর্সগুলোকে অন্য কোনো অরিজিন দ্বারা লোড হওয়া থেকে রক্ষা করার জন্য একটি ঐচ্ছিক ব্যবস্থা হিসেবে চালু করা হয়েছিল। COEP-এর প্রেক্ষাপটে, CORP নির্দিষ্ট করে দিতে পারে যে, কে একটি রিসোর্স লোড করতে পারবে সে বিষয়ে রিসোর্স মালিকের নীতি কী।
Cross-Origin-Resource-Policy হেডারটির তিনটি সম্ভাব্য মান রয়েছে:
Cross-Origin-Resource-Policy: same-site
যেসব রিসোর্সকে same-site হিসেবে চিহ্নিত করা হয়েছে, সেগুলো শুধুমাত্র একই সাইট থেকে লোড করা যাবে।
Cross-Origin-Resource-Policy: same-origin
যেসব রিসোর্সকে same-origin হিসেবে চিহ্নিত করা হয়েছে, সেগুলো শুধুমাত্র একই অরিজিন থেকে লোড করা যাবে।
Cross-Origin-Resource-Policy: cross-origin
যেসব রিসোর্স cross-origin হিসেবে চিহ্নিত করা আছে, সেগুলো যেকোনো ওয়েবসাইট থেকে লোড করা যায়। ( এই মানটি COEP-এর সাথে CORP স্পেসিফিকেশনে যোগ করা হয়েছিল।)
ক্রস অরিজিন ওপেনার নীতি
ক্রস অরিজিন ওপেনার পলিসি (COOP) আপনাকে একটি টপ-লেভেল উইন্ডোকে অন্যান্য ডকুমেন্ট থেকে বিচ্ছিন্ন রাখতে সাহায্য করে। এটি অন্যান্য ডকুমেন্টগুলোকে একটি ভিন্ন ব্রাউজিং কনটেক্সট গ্রুপে রাখে, যার ফলে তারা সরাসরি টপ-লেভেল উইন্ডোটির সাথে ইন্টারঅ্যাক্ট করতে পারে না। উদাহরণস্বরূপ, যদি COOP যুক্ত কোনো ডকুমেন্ট একটি পপ-আপ খোলে, তাহলে তার window.opener প্রপার্টি null হবে। এছাড়াও, ওপেনারটির রেফারেন্সের .closed প্রপার্টি true রিটার্ন করবে।
Cross-Origin-Opener-Policy হেডারটির তিনটি সম্ভাব্য মান রয়েছে:
Cross-Origin-Opener-Policy: same-origin
যেসব ডকুমেন্টকে same-origin হিসেবে চিহ্নিত করা হয়েছে, সেগুলো সেইসব ‘same-origin’ ডকুমেন্টের সাথে একই ব্রাউজিং কনটেক্সট গ্রুপ শেয়ার করতে পারে, যেগুলোকেও স্পষ্টভাবে same-origin হিসেবে চিহ্নিত করা হয়েছে।
Cross-Origin-Opener-Policy: same-origin-allow-popups
same-origin-allow-popups সহ একটি শীর্ষ-স্তরের ডকুমেন্ট তার সেই সমস্ত পপআপের রেফারেন্স ধরে রাখে যেগুলি হয় COOP সেট করে না অথবা unsafe-none COOP সেট করে আইসোলেশন থেকে বেরিয়ে আসে।
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none হলো ডিফল্ট বিকল্প এবং এটি ডকুমেন্টটিকে তার ওপেনারের ব্রাউজিং কনটেক্সট গ্রুপে যুক্ত করার অনুমতি দেয়, যদি না ওপেনারটির নিজের same-origin COOP থাকে।
সারসংক্ষেপ
আপনি যদি SharedArrayBuffer , performance.measureUserAgentSpecificMemory() বা আরও ভালো নির্ভুলতার সাথে উচ্চ রেজোলিউশনের টাইমারের মতো শক্তিশালী ফিচারগুলিতে নিশ্চিত অ্যাক্সেস চান, তাহলে মনে রাখবেন যে আপনার ডকুমেন্টে require-corp ভ্যালু সহ COEP এবং same-origin ভ্যালু সহ COOP উভয়ই ব্যবহার করতে হবে। এর যেকোনো একটির অনুপস্থিতিতে, ব্রাউজার ঐ শক্তিশালী ফিচারগুলিকে নিরাপদে চালু করার জন্য পর্যাপ্ত আইসোলেশনের নিশ্চয়তা দেবে না। self.crossOriginIsolated true রিটার্ন করছে কিনা তা পরীক্ষা করে আপনি আপনার পেজের অবস্থা নির্ধারণ করতে পারেন।
COOP এবং COEP ব্যবহার করে আপনার ওয়েবসাইটকে 'ক্রস-অরিজিন আইসোলেটেড' করার ধাপগুলো জানুন।