মেল্টডাউন/স্পেক্টার

Surma

ওভারভিউ

3রা জানুয়ারী প্রজেক্ট জিরো আধুনিক CPU-তে দুর্বলতা প্রকাশ করেছে যা একটি প্রক্রিয়া ব্যবহার করতে পারে (সবচেয়ে খারাপ) নির্বিচারে মেমরি পড়তে - সেই মেমরি সহ যা সেই প্রক্রিয়ার অন্তর্গত নয়। এই দুর্বলতার নাম দেওয়া হয়েছে স্পেকটার এবং মেল্টডাউন । ওয়েবকে সুরক্ষিত রাখতে সাহায্য করার জন্য Chrome কী করছে এবং ওয়েব ডেভেলপারদের তাদের নিজস্ব সাইটের জন্য কী করা উচিত?

TL; ডাঃ

ওয়েব ব্রাউজিং একজন ব্যবহারকারী হিসাবে, আপনি আপনার অপারেটিং সিস্টেম এবং আপনার ব্রাউজার আপডেট রাখা নিশ্চিত করা উচিত। উপরন্তু, Chrome ব্যবহারকারীরা সাইট আইসোলেশন সক্ষম করার বিষয়ে বিবেচনা করতে পারেন।

আপনি যদি একজন ওয়েব ডেভেলপার হন, তাহলে Chrome টিম পরামর্শ দেয় :

• যেখানে সম্ভব, SameSite এবং HTTPOnly কুকি বৈশিষ্ট্যগুলি ব্যবহার করে এবং document.cookie থেকে পড়া এড়ানোর মাধ্যমে রেন্ডারার প্রক্রিয়ার মেমরিতে প্রবেশ করা থেকে কুকিজকে আটকান৷
• আপনার MIME প্রকারগুলি সঠিক কিনা তা নিশ্চিত করুন এবং একটি X-Content-Type-Options: nosniff শিরোনাম নির্দিষ্ট করুন যাতে ব্যবহারকারী-নির্দিষ্ট বা সংবেদনশীল বিষয়বস্তু সহ যেকোনো URL-এর জন্য ক্রস-অরিজিন রিড ব্লকিং থেকে সর্বাধিক সুবিধা পেতে সাইট আইসোলেশন সক্ষম করা ব্যবহারকারীদের জন্য।
• সাইট আইসোলেশন সক্ষম করুন এবং এটি আপনার সাইটের জন্য সমস্যা সৃষ্টি করে কিনা তা Chrome টিমকে জানান ।

আপনি যদি ভাবছেন কেন এই পদক্ষেপগুলি সাহায্য করে, পড়ুন!

ঝুকি

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

মেল্টডাউন এবং স্পেকটার উভয়ই সম্ভাব্যভাবে একটি প্রক্রিয়াকে মেমরি পড়ার অনুমতি দেয় যা এটি সক্ষম হওয়ার কথা নয়। কখনও কখনও, বিভিন্ন সাইট থেকে একাধিক নথি Chrome-এ একটি প্রক্রিয়া ভাগ করে নিতে পারে৷ এটি ঘটতে পারে যখন একজন window.open , অথবা <a href="..." target="_blank"> , বা iframes ব্যবহার করে অন্যটি খুলবে৷ যদি কোনো ওয়েবসাইটে ব্যবহারকারী-নির্দিষ্ট ডেটা থাকে, তাহলে অন্য কোনো সাইট সেই ব্যবহারকারীর ডেটা পড়ার জন্য এই নতুন দুর্বলতাগুলি ব্যবহার করতে পারে।

প্রশমন

এই হুমকি প্রশমিত করার জন্য Chrome এবং V8 ইঞ্জিনিয়ারিং টিম একাধিক প্রচেষ্টা নিয়োজিত করছে৷

সাইট আইসোলেশন

আক্রমণকারী-নিয়ন্ত্রিত কোডের সাথে একটি প্রক্রিয়া ভাগ করে নেওয়া থেকে সংবেদনশীল ডেটা প্রতিরোধ করে স্পেকটারকে সফলভাবে শোষণের প্রভাব ব্যাপকভাবে হ্রাস করা যেতে পারে। ক্রোম টিম " সাইট আইসোলেশন " নামক এটি অর্জনের জন্য একটি বৈশিষ্ট্য নিয়ে কাজ করছে:

দ্রষ্টব্য: “ওয়েবসাইটগুলি সাধারণত ব্রাউজারের ভিতরে একে অপরের ডেটা অ্যাক্সেস করতে পারে না[...]। মাঝে মাঝে, এই কোডে নিরাপত্তা বাগগুলি পাওয়া যায় এবং ক্ষতিকারক ওয়েবসাইটগুলি অন্যান্য ওয়েবসাইট আক্রমণ করার জন্য এই নিয়মগুলিকে বাইপাস করার চেষ্টা করতে পারে৷ [...] সাইট আইসোলেশন এই ধরনের আক্রমণ সফল হওয়ার সম্ভাবনা কম করার জন্য প্রতিরক্ষার দ্বিতীয় লাইন অফার করে। এটি নিশ্চিত করে যে বিভিন্ন ওয়েবসাইটের পৃষ্ঠাগুলি সর্বদা বিভিন্ন প্রক্রিয়ার মধ্যে রাখা হয়, প্রতিটি একটি স্যান্ডবক্সে চলছে যা প্রক্রিয়াটিকে যা করার অনুমতি দেওয়া হয়েছে তা সীমিত করে। "

সাইট আইসোলেশন এখনও ডিফল্টরূপে সক্ষম করা হয়নি কারণ কয়েকটি পরিচিত সমস্যা রয়েছে এবং Chrome টিম যতটা সম্ভব ফিল্ড টেস্টিং করতে চায়৷ আপনি যদি একজন ওয়েব ডেভেলপার হন, তাহলে আপনার সাইট আইসোলেশন সক্ষম করা উচিত এবং আপনার সাইটটি কার্যকরী আছে কিনা তা পরীক্ষা করা উচিত। আপনি যদি এখন অপ্ট-ইন করতে চান, chrome://flags#enable-site-per-process সক্ষম করুন। আপনি যদি এমন একটি সাইট খুঁজে পান যা কাজ করে না, দয়া করে একটি বাগ ফাইল করে আমাদের সাহায্য করুন এবং উল্লেখ করুন যে আপনি সাইট আইসোলেশন সক্ষম করেছেন৷

ক্রস-সাইট ডকুমেন্ট ব্লকিং

দ্রষ্টব্য: এই নথিটি প্রকাশের পর, ক্রস-সাইট ডকুমেন্ট ব্লকিং-এর নাম পরিবর্তন করে ক্রস-অরিজিন রিড ব্লকিং করা হয়েছে। এই দুটি পদ একই ধারণার উল্লেখ করে।

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

একটি ওয়েবসাইট সার্ভার থেকে দুটি ধরণের ডেটার জন্য অনুরোধ করতে পারে: "ডকুমেন্টস" এবং "রিসোর্স"। এখানে, নথিগুলি হল HTML, XML, JSON, এবং পাঠ্য ফাইল৷ একটি ওয়েবসাইট তার নিজস্ব ডোমেন থেকে বা অনুমোদিত CORS হেডার সহ অন্যান্য ডোমেন থেকে নথি গ্রহণ করতে সক্ষম। সম্পদের মধ্যে ইমেজ, জাভাস্ক্রিপ্ট, সিএসএস এবং ফন্টের মতো জিনিস অন্তর্ভুক্ত থাকে। সম্পদ যে কোনো সাইট থেকে অন্তর্ভুক্ত করা যেতে পারে.

ক্রস-সাইট ডকুমেন্ট ব্লকিং নীতি একটি প্রক্রিয়াকে অন্য উৎস থেকে "ডকুমেন্টস" গ্রহণ করতে বাধা দেয় যদি:

1. তাদের একটি HTML, XML, JSON, বা টেক্সট/প্লেইন MIME টাইপ এবং
2. তাদের হয় একটি X-Content-Type-Options: nosniff HTTP প্রতিক্রিয়া শিরোনাম, অথবা একটি দ্রুত সামগ্রী বিশ্লেষণ (“ স্নিফিং ”) নিশ্চিত করে যে টাইপটি সঠিক
3. CORS স্পষ্টভাবে নথিতে অ্যাক্সেসের অনুমতি দেয় না

এই নীতি দ্বারা অবরুদ্ধ নথিগুলিকে খালি হিসাবে প্রক্রিয়াতে উপস্থাপন করা হয়, যদিও অনুরোধটি এখনও পটভূমিতে ঘটে।

উদাহরণস্বরূপ: কল্পনা করুন একজন আক্রমণকারী একটি <img> ট্যাগ তৈরি করছে যাতে সংবেদনশীল ডেটা সহ একটি JSON ফাইল রয়েছে, যেমন <img src="https://yourbank.com/balance.json"> । সাইট আইসোলেশন ছাড়া, JSON ফাইলের বিষয়বস্তু এটিকে রেন্ডারার প্রক্রিয়ার মেমরিতে নিয়ে যাবে, এই সময়ে রেন্ডারার লক্ষ্য করবে যে এটি একটি বৈধ ইমেজ ফরম্যাট নয় এবং একটি ছবি রেন্ডার করে না। স্পেকটারের সাথে, যাইহোক, এখন মেমরির সেই অংশটি সম্ভাব্যভাবে পড়ার একটি উপায় রয়েছে। ক্রস-সাইট ডকুমেন্ট ব্লক করা এই ফাইলের বিষয়বস্তুকে রেন্ডারার যে প্রক্রিয়ায় চলছে তার মেমরিতে প্রবেশ করা থেকে বাধা দেবে কারণ ক্রস-সাইট ডকুমেন্ট ব্লকিং দ্বারা MIME প্রকার ব্লক করা হয়েছে।

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

আপনি যদি ক্রস-সাইট ডকুমেন্ট ব্লক করার চেষ্টা করতে চান, উপরে বর্ণিত সাইট আইসোলেশনে অপ্ট-ইন করুন।

SameSite কুকিজ

চলুন উপরের উদাহরণে ফিরে যাই: <img src="https://yourbank.com/balance.json"> । এটি শুধুমাত্র তখনই কাজ করে যখন yourbank.com একটি কুকি সংরক্ষণ করে থাকে যা ব্যবহারকারীকে স্বয়ংক্রিয়ভাবে লগ ইন করে৷ কুকিগুলি সাধারণত সমস্ত অনুরোধের জন্য সেই ওয়েবসাইটে পাঠানো হয় যা কুকি সেট করে — এমনকি যদি অনুরোধটি একটি <img> ট্যাগ ব্যবহার করে তৃতীয় পক্ষের দ্বারা করা হয়৷ SameSite কুকি হল একটি নতুন বৈশিষ্ট্য যা নির্দিষ্ট করে যে একটি কুকি শুধুমাত্র একই সাইট থেকে উদ্ভূত একটি অনুরোধের সাথে সংযুক্ত করা উচিত, তাই নাম। দুঃখের বিষয়, লেখার সময়, শুধুমাত্র Chrome এবং Firefox 58+ এই বৈশিষ্ট্যটিকে সমর্থন করে ।

HTTPOnly এবং document.cookie

যদি আপনার সাইটের কুকিজ শুধুমাত্র সার্ভার-সাইড ব্যবহার করা হয়, ক্লায়েন্ট জাভাস্ক্রিপ্ট দ্বারা নয়, তাহলে আপনি রেন্ডারার প্রক্রিয়ায় প্রবেশ করা থেকে কুকির ডেটা বন্ধ করতে পারেন। আপনি HTTPOnly কুকি অ্যাট্রিবিউট সেট করতে পারেন, যা ক্রোমের মতো সমর্থিত ব্রাউজারে ক্লায়েন্ট সাইড স্ক্রিপ্টের মাধ্যমে কুকি অ্যাক্সেস করা থেকে স্পষ্টভাবে বাধা দেয়। যদি HTTPOnly সেট করা সম্ভব না হয়, তাহলে একেবারে প্রয়োজনীয় না হলে document.cookie না পড়ে আপনি রেন্ডার করা প্রক্রিয়ায় কুকি ডেটা লোড করার এক্সপোজার সীমিত করতে সাহায্য করতে পারেন৷

rel="noopener" ব্যবহার করে বাহ্যিক লিঙ্ক খুলুন

আপনি যখন target="_blank" ব্যবহার করে অন্য পৃষ্ঠার সাথে লিঙ্ক করেন, খোলা পৃষ্ঠাটির আপনার window অবজেক্টে অ্যাক্সেস থাকে , আপনার পৃষ্ঠাটি একটি ভিন্ন URL-এ নেভিগেট করতে পারে এবং সাইট আইসোলেশন ছাড়া আপনার পৃষ্ঠার মতো একই প্রক্রিয়ায় থাকবে৷ আপনার পৃষ্ঠাকে আরও ভালভাবে সুরক্ষিত করতে, একটি নতুন উইন্ডোতে খোলা বাহ্যিক পৃষ্ঠাগুলির লিঙ্কগুলিতে সর্বদা rel="noopener" উল্লেখ করা উচিত।

উচ্চ-রেজোলিউশন টাইমার

মেল্টডাউন বা স্পেকটার ব্যবহার করতে, একজন আক্রমণকারীকে মেমরি থেকে একটি নির্দিষ্ট মান পড়তে কতক্ষণ সময় লাগে তা পরিমাপ করতে হবে। এই জন্য, একটি নির্ভরযোগ্য এবং সঠিক টাইমার প্রয়োজন.

ওয়েব প্ল্যাটফর্মটি অফার করে এমন একটি API হল performance.now() যা 5 মাইক্রোসেকেন্ডের জন্য সঠিক। একটি প্রশমন হিসাবে, সমস্ত প্রধান ব্রাউজারগুলি performance.now() এর রেজোলিউশন হ্রাস করেছে যাতে আক্রমণগুলি মাউন্ট করা কঠিন হয়৷

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

V8

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

ওয়েব নিরাপদ রাখা

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