SharedArrayBuffer , performance.measureUserAgentSpecificMemory() এবং উন্নত রেজোলিউশন টাইমারের মতো শক্তিশালী বৈশিষ্ট্যগুলি ব্যবহার করার জন্য কেন ক্রস-অরিজিন আইসোলেশন প্রয়োজন তা জানুন।
ভূমিকা
COOP এবং COEP ব্যবহার করে আপনার ওয়েবসাইটকে "ক্রস-অরিজিন আইসোলেটেড" করার সময় আমরা ব্যাখ্যা করেছি কিভাবে COOP এবং COEP ব্যবহার করে "ক্রস-অরিজিন আইসোলেটেড" অবস্থায় গ্রহণ করা যায়। এটি একটি সহচর নিবন্ধ যা ব্যাখ্যা করে যে কেন ব্রাউজারে শক্তিশালী বৈশিষ্ট্যগুলি সক্ষম করতে ক্রস-অরিজিন আইসোলেশন প্রয়োজন৷
পটভূমি
ওয়েব একই-অরিজিন নীতির উপর নির্মিত: একটি সুরক্ষা বৈশিষ্ট্য যা সীমাবদ্ধ করে যে কীভাবে নথি এবং স্ক্রিপ্টগুলি অন্য উত্সের সংস্থানগুলির সাথে যোগাযোগ করতে পারে৷ এই নীতিটি ওয়েবসাইটগুলি ক্রস-অরিজিন রিসোর্স অ্যাক্সেস করার উপায়গুলিকে সীমাবদ্ধ করে। উদাহরণ স্বরূপ, https://a.example থেকে একটি নথিকে https://b.example এ হোস্ট করা ডেটা অ্যাক্সেস করা থেকে বাধা দেওয়া হয়েছে।
যাইহোক, একই-উৎস নীতির কিছু ঐতিহাসিক ব্যতিক্রম রয়েছে। যেকোনো ওয়েবসাইট করতে পারে:
- ক্রস-অরিজিন আইফ্রেমগুলি এম্বেড করুন
- ছবি বা স্ক্রিপ্টের মতো ক্রস-অরিজিন রিসোর্স অন্তর্ভুক্ত করুন
- একটি DOM রেফারেন্স সহ ক্রস-অরিজিন পপআপ উইন্ডো খুলুন
যদি ওয়েবটি স্ক্র্যাচ থেকে ডিজাইন করা যায় তবে এই ব্যতিক্রমগুলি বিদ্যমান থাকবে না। দুর্ভাগ্যবশত, যখন ওয়েব সম্প্রদায় একটি কঠোর একই-অরিজিন নীতির মূল সুবিধাগুলি উপলব্ধি করেছিল, ওয়েব ইতিমধ্যেই এই ব্যতিক্রমগুলির উপর নির্ভর করছিল৷
এই ধরনের একটি শিথিল একই-অরিজিন নীতির নিরাপত্তা পার্শ্ব-প্রতিক্রিয়া দুটি উপায়ে প্যাচ করা হয়েছিল। একটি উপায় ছিল ক্রস অরিজিন রিসোর্স শেয়ারিং (CORS) নামক একটি নতুন প্রোটোকল প্রবর্তনের মাধ্যমে যার উদ্দেশ্য হল সার্ভার একটি প্রদত্ত উত্সের সাথে একটি সংস্থান ভাগ করে নেওয়ার অনুমতি দেয় তা নিশ্চিত করা৷ অন্য উপায় হল পশ্চাদগামী সামঞ্জস্য রক্ষা করে ক্রস-অরিজিন রিসোর্সে সরাসরি স্ক্রিপ্ট অ্যাক্সেস অপসারণ করা। এই ধরনের ক্রস-অরিজিন সম্পদকে "অস্বচ্ছ" সম্পদ বলা হয়। উদাহরণস্বরূপ, এই কারণেই একটি ক্রস-অরিজিন ছবির পিক্সেলগুলি CanvasRenderingContext2D মাধ্যমে ব্যবহার করা ব্যর্থ হয় যদি না ছবিতে CORS প্রয়োগ করা হয়৷
এই সমস্ত নীতিগত সিদ্ধান্তগুলি একটি ব্রাউজিং প্রসঙ্গ গোষ্ঠীর মধ্যে ঘটছে৷
দীর্ঘ সময়ের জন্য, CORS এবং অস্বচ্ছ সংস্থানগুলির সমন্বয় ব্রাউজারগুলিকে নিরাপদ করার জন্য যথেষ্ট ছিল৷ কখনও কখনও প্রান্তের ক্ষেত্রে (যেমন JSON দুর্বলতাগুলি ) আবিষ্কৃত হয়েছিল, এবং প্যাচ করার প্রয়োজন ছিল, কিন্তু সামগ্রিকভাবে ক্রস-অরিজিন সংস্থানগুলির কাঁচা বাইটগুলিতে সরাসরি পড়ার অ্যাক্সেসের অনুমতি না দেওয়ার নীতিটি সফল হয়েছিল৷
এই সবই Specter এর সাথে পরিবর্তিত হয়েছে, যা আপনার কোড সম্ভাব্যভাবে পাঠযোগ্য হিসাবে একই ব্রাউজিং প্রসঙ্গ গোষ্ঠীতে লোড করা যেকোনো ডেটা করে। নির্দিষ্ট অপারেশনের সময় পরিমাপ করে, আক্রমণকারীরা সিপিইউ ক্যাশের বিষয়বস্তু অনুমান করতে পারে এবং এর মাধ্যমে প্রক্রিয়ার মেমরির বিষয়বস্তু অনুমান করতে পারে। প্ল্যাটফর্মে বিদ্যমান লো-গ্রানুলারিটি টাইমারগুলির সাথে এই ধরনের টাইমিং আক্রমণ সম্ভব, কিন্তু উচ্চ-গ্র্যানুলারিটি টাইমারগুলির সাথে গতি বাড়ানো যেতে পারে, উভয়ই স্পষ্ট (যেমন performance.now() ) এবং অন্তর্নিহিত (যেমন SharedArrayBuffer s)। যদি evil.com একটি ক্রস-অরিজিন ইমেজ এম্বেড করে, তাহলে তারা তার পিক্সেল ডেটা পড়ার জন্য একটি স্পেকটার আক্রমণ ব্যবহার করতে পারে, যা "অস্বচ্ছতার" উপর নির্ভরশীল সুরক্ষাগুলিকে অকার্যকর করে তোলে।
আদর্শভাবে, সমস্ত ক্রস-অরিজিন অনুরোধগুলি সেই সার্ভারের দ্বারা স্পষ্টভাবে যাচাই করা উচিত যা সম্পদের মালিক। যদি রিসোর্স-মালিকানাধীন সার্ভার দ্বারা যাচাইকরণ প্রদান করা না হয়, তবে ডেটা কখনই এটিকে কোনও দুষ্ট অভিনেতার ব্রাউজিং প্রসঙ্গ গোষ্ঠীতে পরিণত করবে না এবং তাই ওয়েব পৃষ্ঠায় যে কোনও স্পেকটার আক্রমণ করা যেতে পারে তার নাগালের বাইরে থাকবে। আমরা একে ক্রস-অরিজিন আইসোলেটেড স্টেট বলি। COOP+COEP সম্পর্কে ঠিক এটাই।
একটি ক্রস-অরিজিন বিচ্ছিন্ন অবস্থার অধীনে, অনুরোধকারী সাইটটিকে কম বিপজ্জনক হিসাবে বিবেচনা করা হয় এবং এটি শক্তিশালী বৈশিষ্ট্যগুলি যেমন SharedArrayBuffer , performance.measureUserAgentSpecificMemory() এবং উচ্চ রেজোলিউশন টাইমারগুলিকে আরও ভাল নির্ভুলতার সাথে আনলক করে যা অন্যথায় স্পেকটার-এর মতো আক্রমণের জন্য ব্যবহার করা যেতে পারে। এটি document.domain পরিবর্তন করতেও বাধা দেয়।
ক্রস অরিজিন এমবেডার নীতি
ক্রস অরিজিন এমবেডার পলিসি (COEP) একটি নথিকে এমন কোনও ক্রস-অরিজিন সংস্থান লোড হতে বাধা দেয় যা স্পষ্টভাবে নথির অনুমতি দেয় না (CORP বা CORS ব্যবহার করে)। এই বৈশিষ্ট্যের সাহায্যে, আপনি ঘোষণা করতে পারেন যে একটি নথি এই ধরনের সংস্থানগুলি লোড করতে পারে না।
এই নীতিটি সক্রিয় করতে, নথিতে নিম্নলিখিত HTTP শিরোনামটি যুক্ত করুন:
Cross-Origin-Embedder-Policy: require-corp
require-corp কীওয়ার্ড হল COEP-এর জন্য একমাত্র স্বীকৃত মান। এটি নীতিটি প্রয়োগ করে যে নথিটি শুধুমাত্র একই উত্স থেকে সংস্থানগুলি লোড করতে পারে বা অন্য উত্স থেকে লোডযোগ্য হিসাবে স্পষ্টভাবে চিহ্নিত সংস্থানগুলিকে লোড করতে পারে৷
অন্য উৎস থেকে সম্পদ লোড করার জন্য, তাদের হয় ক্রস অরিজিন রিসোর্স শেয়ারিং (CORS) বা ক্রস অরিজিন রিসোর্স পলিসি (CORP) সমর্থন করতে হবে।
ক্রস অরিজিন রিসোর্স শেয়ারিং
যদি একটি ক্রস অরিজিন রিসোর্স ক্রস অরিজিন রিসোর্স শেয়ারিং (CORS) সমর্থন করে, তাহলে আপনি COEP দ্বারা অবরুদ্ধ না হয়ে এটিকে আপনার ওয়েব পেজে লোড করতে crossorigin অ্যাট্রিবিউট ব্যবহার করতে পারেন।
<img src="https://third-party.example.com/image.jpg" crossorigin>
উদাহরণস্বরূপ, যদি এই চিত্র সম্পদটি CORS শিরোনামগুলির সাথে পরিবেশিত হয়, তাহলে crossorigin বৈশিষ্ট্যটি ব্যবহার করুন যাতে সংস্থানটি আনার অনুরোধটি CORS মোড ব্যবহার করে। এটি CORS হেডার সেট না করা পর্যন্ত ছবিটি লোড হতে বাধা দেয়।
একইভাবে, আপনি fetch() পদ্ধতির মাধ্যমে ক্রস অরিজিন ডেটা আনতে পারেন, যার জন্য বিশেষ হ্যান্ডলিং প্রয়োজন হয় না যতক্ষণ না সার্ভার সঠিক HTTP শিরোনাম দিয়ে সাড়া দেয়।
ক্রস অরিজিন রিসোর্স পলিসি
ক্রস অরিজিন রিসোর্স পলিসি (সিওআরপি) মূলত একটি অপ্ট-ইন হিসাবে প্রবর্তিত হয়েছিল আপনার সংস্থানগুলিকে অন্য উত্স দ্বারা লোড হওয়া থেকে রক্ষা করার জন্য। 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 হিসাবে চিহ্নিত৷
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 ব্যবহার করে আপনার ওয়েবসাইটকে "ক্রস-অরিজিন আইসোলেটেড" করে এটি বাস্তবায়নের পদক্ষেপগুলি শিখুন৷