ওয়েব ডেভেলপারদের জন্য সাইট আইসোলেশন

ম্যাথিয়াস বাইনেন্স

ডেস্কটপে Chrome 67-এ সাইট আইসোলেশন নামে একটি নতুন বৈশিষ্ট্য রয়েছে যা ডিফল্টরূপে সক্ষম । এই নিবন্ধটি ব্যাখ্যা করে যে সাইট আইসোলেশন কী, কেন এটি প্রয়োজনীয় এবং কেন ওয়েব ডেভেলপারদের এটি সম্পর্কে সচেতন হওয়া উচিত।

সাইট আইসোলেশন কি?

ইন্টারনেট হল বিড়ালের ভিডিও দেখার জন্য এবং অন্যান্য জিনিসের মধ্যে ক্রিপ্টোকারেন্সি ওয়ালেট পরিচালনা করার জন্য — কিন্তু আপনি fluffycats.example আপনার মূল্যবান ক্রিপ্টোকয়েনগুলিতে অ্যাক্সেস পেতে চান না! ভাগ্যক্রমে, ওয়েবসাইটগুলি সাধারণত একই-অরিজিন নীতির জন্য ব্রাউজারের ভিতরে একে অপরের ডেটা অ্যাক্সেস করতে পারে না। তবুও, দূষিত ওয়েবসাইটগুলি অন্য ওয়েবসাইটগুলিকে আক্রমণ করার জন্য এই নীতিটি বাইপাস করার চেষ্টা করতে পারে এবং মাঝে মাঝে, একই-অরিজিন নীতি প্রয়োগ করে ব্রাউজার কোডে নিরাপত্তা বাগগুলি পাওয়া যায়৷ Chrome টিমের লক্ষ্য যত দ্রুত সম্ভব এই ধরনের বাগগুলি ঠিক করা।

সাইট আইসোলেশন হল Chrome-এর একটি নিরাপত্তা বৈশিষ্ট্য যা এই ধরনের আক্রমণ সফল হওয়ার সম্ভাবনা কম করার জন্য একটি অতিরিক্ত প্রতিরক্ষা লাইন অফার করে। এটি নিশ্চিত করে যে বিভিন্ন ওয়েবসাইটের পৃষ্ঠাগুলি সর্বদা বিভিন্ন প্রক্রিয়ার মধ্যে রাখা হয়, প্রতিটি একটি স্যান্ডবক্সে চলছে যা প্রক্রিয়াটিকে যা করার অনুমতি দেওয়া হয়েছে তা সীমিত করে। এটি অন্যান্য সাইট থেকে নির্দিষ্ট ধরণের সংবেদনশীল ডেটা গ্রহণ থেকে প্রক্রিয়াটিকে ব্লক করে। ফলস্বরূপ, সাইট আইসোলেশনের সাথে অন্য সাইট থেকে ডেটা চুরি করার জন্য স্পেকটারের মতো অনুমানমূলক সাইড-চ্যানেল আক্রমণ ব্যবহার করা একটি দূষিত ওয়েবসাইটের পক্ষে অনেক বেশি কঠিন। Chrome টিম অতিরিক্ত এনফোর্সমেন্ট শেষ করার সাথে সাথে, সাইট আইসোলেশন সাহায্য করবে এমনকি যখন আক্রমণকারীর পৃষ্ঠা তার নিজস্ব প্রক্রিয়ায় কিছু নিয়ম ভঙ্গ করতে পারে।

সাইট আইসোলেশন কার্যকরভাবে অবিশ্বস্ত ওয়েবসাইটগুলির জন্য অন্য ওয়েবসাইটগুলিতে আপনার অ্যাকাউন্টগুলি থেকে তথ্য অ্যাক্সেস বা চুরি করা কঠিন করে তোলে৷ এটি বিভিন্ন ধরনের নিরাপত্তা বাগগুলির বিরুদ্ধে অতিরিক্ত সুরক্ষা প্রদান করে, যেমন সাম্প্রতিক মেল্টডাউন এবং স্পেকটার সাইড-চ্যানেল আক্রমণ ।

সাইট আইসোলেশন সম্পর্কে আরও বিস্তারিত জানার জন্য, Google নিরাপত্তা ব্লগে আমাদের নিবন্ধটি দেখুন।

ক্রস-অরিজিন রিড ব্লকিং

এমনকি যখন সমস্ত ক্রস-সাইট পৃষ্ঠাগুলিকে পৃথক প্রক্রিয়ার মধ্যে রাখা হয়, তখনও পৃষ্ঠাগুলি বৈধভাবে কিছু ক্রস-সাইট সাবরিসোর্স যেমন ইমেজ এবং জাভাস্ক্রিপ্টের জন্য অনুরোধ করতে পারে। একটি ক্ষতিকারক ওয়েব পৃষ্ঠা আপনার ব্যাঙ্ক ব্যালেন্সের মতো সংবেদনশীল ডেটা সহ একটি JSON ফাইল লোড করতে একটি <img> উপাদান ব্যবহার করতে পারে:

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

সাইট আইসোলেশন ছাড়া, JSON ফাইলের বিষয়বস্তু রেন্ডারার প্রক্রিয়ার মেমরিতে পরিণত হবে, এই সময়ে রেন্ডারার লক্ষ্য করবে যে এটি একটি বৈধ ইমেজ ফরম্যাট নয় এবং একটি ইমেজ রেন্ডার করে না। কিন্তু, আক্রমণকারী তখন স্পেকটারের মতো দুর্বলতাকে কাজে লাগিয়ে স্মৃতির সেই অংশটিকে সম্ভাব্যভাবে পড়তে পারে।

<img> ব্যবহার করার পরিবর্তে, আক্রমণকারী মেমরিতে সংবেদনশীল ডেটা কমিট করতে <script> ব্যবহার করতে পারে:

<script src="https://your-bank.example/balance.json"></script>

ক্রস-অরিজিন রিড ব্লকিং, বা CORB হল একটি নতুন নিরাপত্তা বৈশিষ্ট্য যা balance.json এর বিষয়বস্তুকে MIME প্রকারের উপর ভিত্তি করে রেন্ডারার প্রসেস মেমরির মেমরিতে প্রবেশ করতে বাধা দেয়।

আসুন CORB কীভাবে কাজ করে তা ভেঙে দেওয়া যাক। একটি ওয়েবসাইট একটি সার্ভার থেকে দুই ধরনের সম্পদের জন্য অনুরোধ করতে পারে:

  1. HTML, XML, বা JSON নথির মতো ডেটা সংস্থান
  2. মিডিয়া রিসোর্স যেমন ছবি, জাভাস্ক্রিপ্ট, সিএসএস, বা ফন্ট

একটি ওয়েবসাইট তার নিজস্ব উত্স থেকে বা অন্যান্য উত্স থেকে ডেটা সংস্থান গ্রহণ করতে সক্ষম হয় অনুমতিমূলক CORS শিরোনাম যেমন Access-Control-Allow-Origin: * । অন্যদিকে, মিডিয়া সংস্থানগুলি যে কোনও উত্স থেকে অন্তর্ভুক্ত করা যেতে পারে, এমনকি অনুমতিমূলক CORS শিরোনাম ছাড়াই৷

CORB রেন্ডারার প্রক্রিয়াটিকে একটি ক্রস-অরিজিন ডেটা রিসোর্স (যেমন HTML, XML, বা JSON) পেতে বাধা দেয় যদি:

  • রিসোর্সটিতে একটি X-Content-Type-Options: nosniff হেডার
  • CORS স্পষ্টভাবে রিসোর্সে অ্যাক্সেসের অনুমতি দেয় না

যদি ক্রস-অরিজিন ডেটা রিসোর্সে X-Content-Type-Options: nosniff হেডার সেট না থাকে, CORB এটি HTML, XML, বা JSON কিনা তা নির্ধারণ করতে প্রতিক্রিয়া বডিটি স্নিফ করার চেষ্টা করে। এটি প্রয়োজনীয় কারণ কিছু ওয়েব সার্ভার ভুল কনফিগার করা হয়েছে এবং চিত্রগুলিকে text/html হিসাবে পরিবেশন করা হয়েছে, উদাহরণস্বরূপ।

CORB নীতি দ্বারা অবরুদ্ধ ডেটা সংস্থানগুলিকে খালি হিসাবে প্রক্রিয়ার কাছে উপস্থাপন করা হয়, যদিও অনুরোধটি এখনও পটভূমিতে ঘটে। ফলস্বরূপ, একটি দূষিত ওয়েব পৃষ্ঠার ক্রস-সাইট ডেটা চুরি করার প্রক্রিয়ার মধ্যে টানতে অসুবিধা হয়৷

সর্বোত্তম নিরাপত্তার জন্য এবং CORB থেকে উপকৃত হওয়ার জন্য, আমরা নিম্নলিখিতগুলি সুপারিশ করি:

  • সঠিক Content-Type হেডার দিয়ে প্রতিক্রিয়া চিহ্নিত করুন। (উদাহরণস্বরূপ, HTML সংস্থানগুলিকে text/html , JSON MIME প্রকারের JSON সংস্থান এবং XML MIME প্রকারের সাথে XML সংস্থান হিসাবে পরিবেশন করা উচিত)।
  • X-Content-Type-Options: nosniff হেডার ব্যবহার করে স্নিফিং থেকে অপ্ট আউট করুন। এই শিরোনামটি ছাড়া, টাইপটি সঠিক কিনা তা নিশ্চিত করার জন্য ক্রোম একটি দ্রুত সামগ্রী বিশ্লেষণ করে, কিন্তু যেহেতু জাভাস্ক্রিপ্ট ফাইলগুলির মতো জিনিসগুলিকে ব্লক করা এড়াতে প্রতিক্রিয়াগুলিকে অনুমতি দেওয়ার ক্ষেত্রে এটি ত্রুটি করে, তাই আপনি ইতিবাচকভাবে সঠিক জিনিসটি করাই ভাল নিজেকে

আরও বিশদ বিবরণের জন্য, ওয়েব ডেভেলপারদের জন্য CORB নিবন্ধ বা আমাদের গভীরভাবে CORB ব্যাখ্যাকারী পড়ুন।

কেন ওয়েব ডেভেলপারদের সাইট আইসোলেশন সম্পর্কে যত্ন নেওয়া উচিত?

বেশিরভাগ ক্ষেত্রে, সাইট আইসোলেশন হল পর্দার পিছনের একটি ব্রাউজার বৈশিষ্ট্য যা সরাসরি ওয়েব ডেভেলপারদের কাছে প্রকাশ করা হয় না। উদাহরণস্বরূপ, শেখার জন্য কোনও নতুন ওয়েব-উন্মুক্ত API নেই। সাধারণভাবে, সাইট আইসোলেশনের সাথে বা ছাড়া চলাকালীন ওয়েব পৃষ্ঠাগুলি পার্থক্য বলতে সক্ষম হবে না।

যাইহোক, এই নিয়মের কিছু ব্যতিক্রম আছে। সাইট আইসোলেশন সক্ষম করার ফলে কিছু সূক্ষ্ম পার্শ্ব-প্রতিক্রিয়া আসে যা আপনার ওয়েবসাইটকে প্রভাবিত করতে পারে। আমরা পরিচিত সাইট আইসোলেশন সমস্যাগুলির একটি তালিকা বজায় রাখি, এবং আমরা নীচের সবচেয়ে গুরুত্বপূর্ণ বিষয়গুলি বিশদভাবে বর্ণনা করি৷

পূর্ণ-পৃষ্ঠার বিন্যাস আর সিঙ্ক্রোনাস নয়

সাইট আইসোলেশনের সাথে, পূর্ণ-পৃষ্ঠার বিন্যাসটি আর সিঙ্ক্রোনাস হওয়ার নিশ্চয়তা দেয় না, যেহেতু একটি পৃষ্ঠার ফ্রেমগুলি এখন একাধিক প্রক্রিয়া জুড়ে ছড়িয়ে পড়তে পারে। এটি পৃষ্ঠাগুলিকে প্রভাবিত করতে পারে যদি তারা ধরে নেয় যে লেআউট পরিবর্তন অবিলম্বে পৃষ্ঠার সমস্ত ফ্রেমে প্রচারিত হয়।

উদাহরণ স্বরূপ, আসুন fluffykittens.example নামে একটি ওয়েবসাইট বিবেচনা করি যা social-widget.example এ হোস্ট করা একটি সামাজিক উইজেটের সাথে যোগাযোগ করে :

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

প্রথমে, সোশ্যাল উইজেটের <iframe> এর প্রস্থ 123 পিক্সেল। কিন্তু তারপর, FluffyKittens পৃষ্ঠাটি প্রস্থকে 456 পিক্সেল (ট্রিগারিং লেআউট) এ পরিবর্তন করে এবং সামাজিক উইজেটে একটি বার্তা পাঠায়, যার নিম্নলিখিত কোড রয়েছে:

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

যখনই সামাজিক উইজেট postMessage API-এর মাধ্যমে একটি বার্তা পায়, তখন এটি তার মূল <html> উপাদানটির প্রস্থ লগ করে।

কোন প্রস্থ মান লগ পায়? ক্রোম সাইট আইসোলেশন সক্ষম করার আগে, উত্তরটি ছিল 456 । document.documentElement.clientWidth অ্যাক্সেস করা লেআউটকে বাধ্য করে, যা Chrome সক্রিয় সাইট আইসোলেশনের আগে সিঙ্ক্রোনাস হতো। যাইহোক, সাইট আইসোলেশন সক্ষম হলে, ক্রস-অরিজিন সোশ্যাল উইজেট রি-লেআউট এখন একটি পৃথক প্রক্রিয়ায় অ্যাসিঙ্ক্রোনাসভাবে ঘটে। যেমন, উত্তরটি এখন 123 হতে পারে, অর্থাৎ পুরানো width মান।

যদি একটি পৃষ্ঠা একটি ক্রস-অরিজিন <iframe> এর আকার পরিবর্তন করে এবং তারপরে একটি postMessage পাঠায়, সাইট আইসোলেশনের সাথে বার্তা গ্রহণ করার সময় গ্রহীতা ফ্রেমটি তার নতুন আকারটি নাও জানতে পারে। আরও সাধারণভাবে, এটি পৃষ্ঠাগুলি ভেঙে ফেলতে পারে যদি তারা ধরে নেয় যে লেআউট পরিবর্তন অবিলম্বে পৃষ্ঠার সমস্ত ফ্রেমে প্রচারিত হয়।

এই বিশেষ উদাহরণে, একটি আরও শক্তিশালী সমাধান প্যারেন্ট ফ্রেমে width নির্ধারণ করবে এবং <iframe> এ একটি resize ইভেন্ট শুনে সেই পরিবর্তন সনাক্ত করবে।

আনলোড হ্যান্ডলার আরো প্রায়ই সময় শেষ হতে পারে

যখন একটি ফ্রেম নেভিগেট বা বন্ধ হয়ে যায়, তখন পুরানো নথির পাশাপাশি এতে এমবেড করা যেকোন সাবফ্রেম নথিগুলি তাদের unload হ্যান্ডলার চালায়। যদি নতুন নেভিগেশন একই রেন্ডারার প্রক্রিয়ায় ঘটে (যেমন একই-অরিজিন নেভিগেশনের জন্য), পুরানো নথির unload হ্যান্ডলার এবং এর সাবফ্রেমগুলি নতুন নেভিগেশনকে কমিট করার অনুমতি দেওয়ার আগে ইচ্ছাকৃতভাবে দীর্ঘ সময়ের জন্য চলতে পারে।

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

এই পরিস্থিতিতে, সমস্ত ফ্রেমের unload হ্যান্ডলারগুলি খুব নির্ভরযোগ্য।

যাইহোক, সাইট আইসোলেশন ছাড়াও কিছু প্রধান ফ্রেম নেভিগেশন ক্রস-প্রক্রিয়া, যা আনলোড হ্যান্ডলারের আচরণকে প্রভাবিত করে। উদাহরণস্বরূপ, যদি আপনি ঠিকানা বারে URL টাইপ করে old.example থেকে new.example এ নেভিগেট করেন, new.example নেভিগেশন একটি নতুন প্রক্রিয়ায় ঘটে। old.example এবং এর সাবফ্রেমগুলির জন্য আনলোড হ্যান্ডলারগুলি new.example পৃষ্ঠাটি দেখানোর পরে, পটভূমিতে old.example প্রক্রিয়ায় চলে এবং পুরানো আনলোড হ্যান্ডলারগুলি একটি নির্দিষ্ট সময়সীমার মধ্যে শেষ না হলে বন্ধ হয়ে যায় ৷ কারণ আনলোড হ্যান্ডলারগুলি সময় শেষ হওয়ার আগে শেষ নাও করতে পারে, আনলোড আচরণ কম নির্ভরযোগ্য।

সাইট আইসোলেশনের সাথে, সমস্ত ক্রস-সাইট নেভিগেশন ক্রস-প্রসেসে পরিণত হয়, যাতে বিভিন্ন সাইটের নথি একে অপরের সাথে একটি প্রক্রিয়া ভাগ করে না। ফলস্বরূপ, উপরের পরিস্থিতি আরও ক্ষেত্রে প্রযোজ্য, এবং <iframe> s-এ আনলোড হ্যান্ডলারগুলির প্রায়শই উপরে বর্ণিত ব্যাকগ্রাউন্ড এবং টাইমআউট আচরণ থাকে।

সাইট আইসোলেশনের ফলে আরেকটি পার্থক্য হল আনলোড হ্যান্ডলারের নতুন সমান্তরাল ক্রম: সাইট আইসোলেশন ছাড়া, আনলোড হ্যান্ডলারগুলি ফ্রেম জুড়ে একটি কঠোর টপ-ডাউন অর্ডারে চলে। কিন্তু সাইট আইসোলেশনের সাথে, আনলোড হ্যান্ডলারগুলি বিভিন্ন প্রক্রিয়া জুড়ে সমান্তরালভাবে চলে।

এগুলি হল সাইট আইসোলেশন সক্ষম করার মৌলিক পরিণতি৷ Chrome টিম সাধারণ ব্যবহারের ক্ষেত্রে আনলোড হ্যান্ডলারগুলির নির্ভরযোগ্যতা উন্নত করার জন্য কাজ করছে, যেখানে সম্ভব। আমরা এমন বাগগুলি সম্পর্কেও সচেতন যেখানে সাবফ্রেম আনলোড হ্যান্ডলাররা এখনও নির্দিষ্ট বৈশিষ্ট্যগুলি ব্যবহার করতে সক্ষম নয় এবং সেগুলি সমাধান করার জন্য কাজ করছে৷

আনলোড হ্যান্ডলারদের জন্য একটি গুরুত্বপূর্ণ কেস হল সেশনের শেষে পিং পাঠানো। এটি সাধারণত নিম্নলিখিত হিসাবে করা হয়:

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});

এই পরিবর্তনের আলোকে আরও শক্তিশালী একটি ভাল পদ্ধতি হল এর পরিবর্তে navigator.sendBeacon ব্যবহার করা:

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

আপনার যদি অনুরোধের উপর আরও নিয়ন্ত্রণের প্রয়োজন হয়, আপনি ফেচ API-এর keepalive বিকল্পটি ব্যবহার করতে পারেন:

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

উপসংহার

সাইট আইসোলেশন প্রতিটি সাইটকে নিজস্ব প্রক্রিয়ায় বিচ্ছিন্ন করে অন্য ওয়েবসাইটগুলিতে আপনার অ্যাকাউন্ট থেকে তথ্য অ্যাক্সেস করা বা চুরি করা অবিশ্বস্ত ওয়েবসাইটগুলির পক্ষে কঠিন করে তোলে। এর অংশ হিসাবে, CORB সংবেদনশীল ডেটা সংস্থান রেন্ডারার প্রক্রিয়ার বাইরে রাখার চেষ্টা করে। উপরের আমাদের সুপারিশগুলি নিশ্চিত করে যে আপনি এই নতুন সুরক্ষা বৈশিষ্ট্যগুলি থেকে সর্বাধিক সুবিধা পান৷

অ্যালেক্স মোশচুক, চার্লি রেইস, জেসন মিলার, নাসকো ওসকভ, ফিলিপ ওয়ালটন, শুভি প্যানিকার এবং থমাস স্টেইনারকে ধন্যবাদ এই নিবন্ধটির একটি খসড়া সংস্করণ পড়ার জন্য এবং তাদের মতামত দেওয়ার জন্য।