স্কিমফুল সেম-সাইট

'সেম-সাইট'-এর সংজ্ঞায় এখন ইউআরএল স্কিমও অন্তর্ভুক্ত হচ্ছে, তাই কোনো সাইটের HTTP এবং HTTPS সংস্করণের মধ্যকার লিঙ্কগুলো এখন ক্রস-সাইট রিকোয়েস্ট হিসেবে গণ্য হয়। যেখানে সম্ভব, সমস্যা এড়াতে ডিফল্টভাবে HTTPS-এ আপগ্রেড করুন অথবা SameSite অ্যাট্রিবিউটের কোন ভ্যালুগুলো প্রয়োজন, তার বিস্তারিত জানতে পড়তে থাকুন।

স্টিভেন বিংলার
Steven Bingler
GitHub
রোয়ান মেরেউড

স্কিমফুল সেম-সাইট একটি (ওয়েব)সাইটের সংজ্ঞা শুধু নিবন্ধনযোগ্য ডোমেইন থেকে পরিবর্তন করে স্কিম + নিবন্ধনযোগ্য ডোমেইনে নিয়ে আসে। আপনি 'সেম-সাইট' এবং 'সেম-অরিজিন' বোঝা অংশে আরও বিস্তারিত তথ্য এবং উদাহরণ খুঁজে পেতে পারেন।

সুখবরটি হলো: যদি আপনার ওয়েবসাইটটি ইতিমধ্যেই সম্পূর্ণরূপে HTTPS-এ আপগ্রেড করা থাকে, তাহলে আপনাকে কোনো কিছু নিয়ে চিন্তা করতে হবে না। আপনার জন্য কোনো কিছুই পরিবর্তন হবে না।

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

আপনি ক্রোম এবং ফায়ারফক্স উভয় ব্রাউজারেই পরীক্ষার জন্য এই পরিবর্তনগুলো সক্রিয় করতে পারেন।

  • Chrome 86 থেকে, about://flags/#schemeful-same-site সক্রিয় করুন। Chrome Status পৃষ্ঠায় অগ্রগতি ট্র্যাক করুন।
  • ফায়ারফক্স ৭৯ থেকে, about:config মাধ্যমে network.cookie.sameSite.schemeful কে true তে সেট করুন। Bugzilla ইস্যুটি ব্যবহার করে অগ্রগতির খোঁজ রাখুন।

কুকির জন্য ডিফল্ট হিসেবে SameSite=Lax এ পরিবর্তনের অন্যতম প্রধান কারণ ছিল ক্রস-সাইট রিকোয়েস্ট ফরজেরি (CSRF) থেকে সুরক্ষা প্রদান করা। তবে, অসুরক্ষিত HTTP ট্র্যাফিক এখনও নেটওয়ার্ক আক্রমণকারীদের জন্য কুকি বিকৃত করার একটি সুযোগ তৈরি করে, যা পরবর্তীতে সাইটের সুরক্ষিত HTTPS সংস্করণে ব্যবহৃত হবে। স্কিমগুলোর মধ্যে এই অতিরিক্ত ক্রস-সাইট সীমানা তৈরি করা এই ধরনের আক্রমণের বিরুদ্ধে আরও সুরক্ষা প্রদান করে।

সাধারণ ক্রস-স্কিম পরিস্থিতি

আগে, কোনো ওয়েবসাইটের বিভিন্ন স্কিমের সংস্করণের মধ্যে যাতায়াত করার সময় (যেমন, http ://site.example থেকে https ://site.example-এ লিঙ্ক করার সময়) SameSite=Strict কুকি পাঠানো যেত। এখন এটিকে একটি ক্রস-সাইট নেভিগেশন হিসেবে গণ্য করা হয়, যার ফলে SameSite=Strict কুকি ব্লক করা হবে।

কোনো সাইটের অসুরক্ষিত HTTP সংস্করণ থেকে সুরক্ষিত HTTPS সংস্করণে লিঙ্ক অনুসরণ করার মাধ্যমে একটি ক্রস-স্কিম নেভিগেশন চালু হয়। SameSite=Strict কুকি ব্লক করা হয়েছে, SameSite=Lax এবং SameSite=None; সুরক্ষিত কুকি অনুমোদিত।
HTTP থেকে HTTPS-এ ক্রস-স্কিম নেভিগেশন।
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ অবরুদ্ধ ⛔ অবরুদ্ধ
SameSite=Lax ✓ অনুমোদিত ✓ অনুমোদিত
SameSite=None;Secure ✓ অনুমোদিত ⛔ অবরুদ্ধ

উপ-সম্পদ লোড করা হচ্ছে

সম্পূর্ণ HTTPS-এ আপগ্রেড করার কাজ চলাকালীন, এখানে আপনার করা যেকোনো পরিবর্তনকে শুধুমাত্র একটি অস্থায়ী সমাধান হিসেবে বিবেচনা করা উচিত।

সাবরিসোর্সের উদাহরণ হলো ছবি, আইফ্রেম এবং XHR বা Fetch ব্যবহার করে করা নেটওয়ার্ক অনুরোধ।

পূর্বে, কোনো পৃষ্ঠায় একটি ক্রস-স্কিম সাবরিসোর্স লোড করলে SameSite=Strict বা SameSite=Lax কুকি পাঠানো বা সেট করা যেত। এখন এটিকে অন্য যেকোনো থার্ড-পার্টি বা ক্রস-সাইট সাবরিসোর্সের মতোই বিবেচনা করা হয়, যার অর্থ হলো যেকোনো SameSite=Strict বা SameSite=Lax কুকি ব্লক করা হবে।

এছাড়াও, ব্রাউজার যদি কোনো সুরক্ষিত পৃষ্ঠায় অসুরক্ষিত স্কিম থেকে রিসোর্স লোড করার অনুমতিও দেয়, তবুও এই অনুরোধগুলিতে সমস্ত কুকি ব্লক করা হবে, কারণ থার্ড-পার্টি বা ক্রস-সাইট কুকির জন্য Secure ) প্রয়োজন।

সাইটের সুরক্ষিত HTTPS সংস্করণ থেকে কোনো রিসোর্স অসুরক্ষিত HTTP সংস্করণে অন্তর্ভুক্ত করার ফলে সৃষ্ট একটি ক্রস-স্কিম সাবরিসোর্স। SameSite=Strict এবং SameSite=Lax কুকি ব্লক করা হয়েছে, এবং SameSite=None; সুরক্ষিত কুকি অনুমোদিত।
একটি HTTP পেজ, যা HTTPS-এর মাধ্যমে একটি ক্রস-স্কিম সাবরিসোর্স অন্তর্ভুক্ত করে।
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ অবরুদ্ধ ⛔ অবরুদ্ধ
SameSite=Lax ⛔ অবরুদ্ধ ⛔ অবরুদ্ধ
SameSite=None;Secure ✓ অনুমোদিত ⛔ অবরুদ্ধ

একটি ফর্ম পোস্ট করা

আগে, একটি ওয়েবসাইটের বিভিন্ন স্কিমের সংস্করণের মধ্যে পোস্ট করার সময় SameSite=Lax বা SameSite=Strict দিয়ে সেট করা কুকি পাঠানো যেত। এখন এটিকে একটি ক্রস-সাইট POST হিসেবে গণ্য করা হয়—শুধুমাত্র SameSite=None কুকিই পাঠানো যাবে। আপনি এমন সাইটগুলিতে এই পরিস্থিতির সম্মুখীন হতে পারেন, যেগুলি ডিফল্টরূপে অসুরক্ষিত সংস্করণটি দেখায়, কিন্তু সাইন-ইন বা চেক-আউট ফর্ম জমা দেওয়ার পর ব্যবহারকারীদের সুরক্ষিত সংস্করণে আপগ্রেড করে দেয়।

সাবরিসোর্সের মতোই, যদি অনুরোধটি একটি সুরক্ষিত প্রেক্ষাপট (যেমন HTTPS) থেকে একটি অসুরক্ষিত প্রেক্ষাপটে (যেমন HTTP) করা হয়, তাহলে এই ধরনের অনুরোধগুলিতে সমস্ত কুকি ব্লক করা হবে, কারণ থার্ড-পার্টি বা ক্রস-সাইট কুকিগুলির জন্য Secure প্রয়োজন।

সাইটের অসুরক্ষিত HTTP সংস্করণের একটি ফর্ম সুরক্ষিত HTTPS সংস্করণে জমা দেওয়ার ফলে এটি একটি ক্রস-স্কিম ফর্ম সাবমিশন। SameSite=Strict এবং SameSite=Lax কুকি ব্লক করা হয়েছে, এবং SameSite=None; Secure কুকি অনুমোদিত।
HTTP থেকে HTTPS-এ ক্রস-স্কিম ফর্ম জমা দেওয়া।
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ অবরুদ্ধ ⛔ অবরুদ্ধ
SameSite=Lax ⛔ অবরুদ্ধ ⛔ অবরুদ্ধ
SameSite=None;Secure ✓ অনুমোদিত ⛔ অবরুদ্ধ

আমি আমার সাইটটি কীভাবে পরীক্ষা করতে পারি?

ক্রোম এবং ফায়ারফক্সে ডেভেলপার টুলিং এবং মেসেজিং উপলব্ধ আছে।

ক্রোম ৮৬ থেকে, ডেভটুলস-এর ইস্যু ট্যাবে স্কিমফুল সেম-সাইট ইস্যুগুলো অন্তর্ভুক্ত থাকবে। আপনার সাইটের জন্য নিম্নলিখিত ইস্যুগুলো হাইলাইট করা দেখতে পারেন।

নেভিগেশন সংক্রান্ত সমস্যা:

  • একই সাইটের অনুরোধে কুকি পাঠানো অব্যাহত রাখতে সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত হন—এটি একটি সতর্কবার্তা যে ক্রোমের ভবিষ্যৎ সংস্করণে কুকি ব্লক করা হবে ।
  • একই সাইটের অনুরোধে কুকি পাঠাতে সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত হন—এটি একটি সতর্কবার্তা যে কুকিটি ব্লক করা হয়েছে ।

সাবরিসোর্স লোডিং সমস্যা:

  • "একই সাইটের সাবরিসোর্সগুলিতে কুকি পাঠানো চালিয়ে যেতে সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত হন" অথবা "একই সাইটের সাবরিসোর্সগুলি দ্বারা কুকি সেট করার অনুমতি দেওয়া চালিয়ে যেতে সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত হন"—এই সতর্কবার্তাগুলি জানায় যে ক্রোমের ভবিষ্যৎ কোনো সংস্করণে কুকিটি ব্লক করা হবে ।
  • "একই সাইটের সাবরিসোর্সগুলিতে কুকি পাঠানোর জন্য সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত হন" অথবা "একই সাইটের সাবরিসোর্সগুলি দ্বারা কুকি সেট করার অনুমতি দেওয়ার জন্য সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত হন"—এগুলো হলো কুকি ব্লক করা হয়েছে এমন সতর্কবার্তা। শেষের সতর্কবার্তাটি কোনো ফর্ম POST করার সময়েও দেখা যেতে পারে।

Schemeful Same-Site-এর জন্য টেস্টিং এবং ডিবাগিং টিপস -এ আরও বিস্তারিত তথ্য পাওয়া যাবে।

ফায়ারফক্স ৭৯ থেকে, about:config এর মাধ্যমে network.cookie.sameSite.schemeful কে true সেট করা হলে, কনসোলে স্কিমফুল সেম-সাইট সংক্রান্ত সমস্যার জন্য বার্তা প্রদর্শিত হবে। আপনি আপনার সাইটে নিম্নলিখিতটি দেখতে পারেন:

  • কুকি ` cookie_name শীঘ্রই http://site.example/ এর বিপরীতে একটি ক্রস-সাইট কুকি হিসাবে বিবেচিত হবে, কারণ স্কিমটি মেলে না।
  • কুকি ` cookie_name http://site.example/ এর বিপরীতে ক্রস-সাইট হিসেবে গণ্য করা হয়েছে , কারণ স্কিমটি মেলে না।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

আমার সাইটটি ইতিমধ্যেই সম্পূর্ণরূপে HTTPS-এ উপলব্ধ, তাহলে আমি আমার ব্রাউজারের DevTools-এ সমস্যা দেখতে পাচ্ছি কেন?

এমনটা হতে পারে যে আপনার কিছু লিঙ্ক এবং সাবরিসোর্স এখনও অনিরাপদ ইউআরএল-এর দিকে নির্দেশ করছে।

এই সমস্যাটি সমাধানের একটি উপায় হলো HTTP Strict-Transport-Security (HSTS) এবং includeSubDomain ডিরেক্টিভ ব্যবহার করা। HSTS ও includeSubDomain ব্যবহার করলে, আপনার কোনো পেজে ভুলবশত একটি অসুরক্ষিত লিঙ্ক থাকলেও ব্রাউজার স্বয়ংক্রিয়ভাবে তার পরিবর্তে সুরক্ষিত সংস্করণটি ব্যবহার করবে।

যদি আমি HTTPS-এ আপগ্রেড করতে না পারি তাহলে কী হবে?

আপনার ব্যবহারকারীদের সুরক্ষার জন্য আমরা আপনার সাইটটিকে সম্পূর্ণরূপে HTTPS-এ আপগ্রেড করার জন্য জোরালোভাবে সুপারিশ করলেও, যদি আপনি নিজে তা করতে না পারেন, তবে আপনার হোস্টিং প্রোভাইডারের সাথে কথা বলে দেখুন তারা এই বিকল্পটি দিতে পারে কিনা। আপনি যদি সেলফ-হোস্ট করেন, তাহলে লেটস এনক্রিপ্ট (Let's Encrypt) একটি সার্টিফিকেট ইনস্টল এবং কনফিগার করার জন্য বেশ কিছু টুল সরবরাহ করে। এছাড়াও, আপনি আপনার সাইটটিকে একটি CDN বা অন্য কোনো প্রক্সির পেছনে সরিয়ে নেওয়ার বিষয়টিও খতিয়ে দেখতে পারেন, যা HTTPS সংযোগ প্রদান করতে সক্ষম।

যদি তাতেও সম্ভব না হয়, তাহলে প্রভাবিত কুকিগুলোর SameSite সুরক্ষা শিথিল করার চেষ্টা করুন।

  • যেসব ক্ষেত্রে শুধুমাত্র SameSite=Strict কুকি ব্লক করা হচ্ছে, সেখানে আপনি সুরক্ষা কমিয়ে Lax করতে পারেন।
  • যেসব ক্ষেত্রে Strict এবং Lax উভয় প্রকার কুকিই ব্লক করা হচ্ছে এবং আপনার কুকিগুলো কোনো সুরক্ষিত URL-এ পাঠানো হচ্ছে (বা সেখান থেকে সেট করা হচ্ছে), সেক্ষেত্রে আপনি সুরক্ষা কমিয়ে None এ নামিয়ে আনতে পারেন।
    • আপনি যে URL-এ কুকি পাঠাচ্ছেন (বা সেট করছেন) সেটি যদি অসুরক্ষিত হয়, তাহলে এই সমাধানটি কাজ করবে না । এর কারণ হলো, SameSite=None বিকল্পটির জন্য কুকিতে Secure অ্যাট্রিবিউট থাকা আবশ্যক, যার অর্থ হলো কোনো অসুরক্ষিত সংযোগের মাধ্যমে সেই কুকিগুলো পাঠানো বা সেট করা যায় না। এই ক্ষেত্রে, আপনার সাইটটি HTTPS-এ আপগ্রেড না করা পর্যন্ত আপনি সেই কুকিটি অ্যাক্সেস করতে পারবেন না।
    • মনে রাখবেন, এটি কেবল অস্থায়ী, কারণ অবশেষে থার্ড-পার্টি কুকি সম্পূর্ণরূপে বন্ধ করে দেওয়া হবে।

আমি যদি SameSite অ্যাট্রিবিউট নির্দিষ্ট না করে থাকি, তাহলে এটি আমার কুকিগুলোকে কীভাবে প্রভাবিত করবে?

SameSite অ্যাট্রিবিউট ছাড়া কুকিগুলোকে এমনভাবে বিবেচনা করা হয় যেন সেগুলোতে SameSite=Lax নির্দিষ্ট করা আছে এবং এই কুকিগুলোর ক্ষেত্রেও একই ক্রস-স্কিম আচরণ প্রযোজ্য। উল্লেখ্য যে, অনিরাপদ মেথডের জন্য অস্থায়ী ব্যতিক্রমটি এখনও প্রযোজ্য, আরও তথ্যের জন্য Chromium SameSite FAQ-তে Lax + POST প্রতিকার অংশটি দেখুন।

ওয়েবসকেটগুলো কীভাবে প্রভাবিত হয়?

WebSocket সংযোগগুলোকেও একই-সাইট সংযোগ হিসেবে বিবেচনা করা হবে, যদি সেগুলোর নিরাপত্তা পৃষ্ঠাটির নিরাপত্তার সমান হয়।

একই-সাইট:

  • https:// wss:// সংযোগ
  • http:// ws:// সংযোগ

ক্রস-সাইট:

  • http:// wss:// সংযোগ
  • https:// ws:// সংযোগ