মডার্ন ওয়েব নির্দেশিকা এখন স্টেবল! বিশেষজ্ঞদের দ্বারা যাচাই করা ওয়েব ডেভেলপমেন্টের পেশাদার পদ্ধতির মাধ্যমে আপনার কোডিং এজেন্ট আপগ্রেড করুন। ঘোষণাটি পড়ুন।

আপনার পছন্দের ভাষায় কন্টেন্ট অনুবাদ করতে Google তার AI প্রযুক্তি ব্যবহার করে। AI-এর মাধ্যমে করা অনুবাদে ভুল থাকতে পারে।

স্যান্ডবক্স করা IFrame-এ নিরাপদে চালান

Mike West

আজকের ওয়েবে একটি সমৃদ্ধ অভিজ্ঞতা তৈরি করার জন্য প্রায় অনিবার্যভাবে এমন কম্পোনেন্ট এবং কন্টেন্ট এম্বেড করতে হয় যার উপর আপনার কোনও প্রকৃত নিয়ন্ত্রণ নেই। থার্ড-পার্টি উইজেট এনগেজমেন্ট বাড়াতে পারে এবং সামগ্রিক ব্যবহারকারীর অভিজ্ঞতায় গুরুত্বপূর্ণ ভূমিকা পালন করে। ব্যবহারকারীর তৈরি করা কন্টেন্ট কখনও কখনও সাইটের নিজস্ব কন্টেন্টের চেয়েও বেশি গুরুত্বপূর্ণ হয়। কোনওটিই না করা কোনও বিকল্প নয়, তবে দুটিই আপনার সাইটে Something Bad™ হওয়ার ঝুঁকি বাড়িয়ে দেয়। আপনার এম্বেড করা প্রতিটি উইজেট -- প্রতিটি বিজ্ঞাপন, প্রতিটি সোশ্যাল মিডিয়া উইজেট -- ক্ষতিকর উদ্দেশ্য নিয়ে আক্রমণ করার সম্ভাব্য ভেক্টর:

কন্টেন্ট নিরাপত্তা নীতি (CSP) আপনাকে স্ক্রিপ্ট ও অন্যান্য কন্টেন্টের বিশেষভাবে বিশ্বস্ত সোর্সকে হোয়াইটলিস্ট করার ক্ষমতা প্রদান করে এই দুই ধরনের কন্টেন্টের সাথে সম্পর্কিত ঝুঁকি কমাতে সাহায্য করতে পারে। এটি সঠিক দিকে একটি বড় পদক্ষেপ, তবে এটি লক্ষণীয় যে বেশিরভাগ CSP নির্দেশাবলী যে সুরক্ষা প্রদান করে তা বাইনারি: রিসোর্সটি অনুমোদিত, অথবা এটি নয়। এমন সময় আসে যখন এটি বলা উপযোগী হবে যে "আমি নিশ্চিত নই যে আমি আসলে এই কন্টেন্টের সোর্সকে বিশ্বাস করি, কিন্তু এটি খুব সুন্দর! এটি এম্বেড করো প্লিজ, ব্রাউজার, তবে এটি যেন আমার সাইটকে ভেঙে না দেয়।"

সবচেয়ে কম প্রিভিলেজ

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

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

iframe এলিমেন্টের sandbox অ্যাট্রিবিউট ফ্রেম করা কন্টেন্টের উপর বিধিনিষেধ আরও কঠোর করার জন্য আমাদের যা প্রয়োজন তা প্রদান করে। আমরা ব্রাউজারকে নির্দেশ দিতে পারি যাতে এটি কম-প্রিভিলেজ পরিবেশে নির্দিষ্ট ফ্রেমের কন্টেন্ট লোড করে, যা শুধুমাত্র প্রয়োজনীয় কাজের জন্য প্রয়োজনীয় ক্ষমতার সাবসেটকে অনুমতি দেয়।

Twust, but verify

Twitter-এর "টুইট" বোতাম হল এমন একটি ফাংশনের দারুণ উদাহরণ যা স্যান্ডবক্সের মাধ্যমে আপনার সাইটে আরও নিরাপদে এম্বেড করা যেতে পারে। Twitter আপনাকে iframe-এর মাধ্যমে বোতাম এম্বেড করার অনুমতি দেয়, যার কোড নিচে দেওয়া হল:

<iframe src="https://platform.twitter.com/widgets/tweet_button.html"
        style="border: 0; width:130px; height:20px;"></iframe>

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

স্যান্ডবক্সিং হোয়াইটলিস্টের ভিত্তিতে কাজ করে। আমরা প্রথমে সম্ভাব্য সব অনুমতি সরিয়ে দিই এবং তারপর স্যান্ডবক্সের কনফিগারেশনে নির্দিষ্ট ফ্ল্যাগ যোগ করে আলাদা আলাদা ক্ষমতা আবার চালু করি। Twitter উইজেটের জন্য, আমরা জাভাস্ক্রিপ্ট, পপ-আপ, ফর্ম জমা দেওয়া এবং twitter.com-এর কুকি চালু করার সিদ্ধান্ত নিয়েছি। আমরা iframe-এ sandbox অ্যাট্রিবিউট যোগ করে এটি করতে পারি, যার ভ্যালু হবে:

<iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
    src="https://platform.twitter.com/widgets/tweet_button.html"
    style="border: 0; width:130px; height:20px;"></iframe>

এইটুকুই। আমরা ফ্রেমটিকে তার প্রয়োজনীয় সমস্ত ক্ষমতা দিয়েছি এবং ব্রাউজার এটিকে এমন কোনও বিশেষাধিকার অ্যাক্সেস করতে অস্বীকার করবে যা আমরা sandbox অ্যাট্রিবিউটের ভ্যালুর মাধ্যমে স্পষ্টভাবে প্রদান করিনি।

ক্ষমতার উপর গ্র্যানুলার কন্ট্রোল

আমরা উপরের উদাহরণে সম্ভাব্য কয়েকটি স্যান্ডবক্সিং ফ্ল্যাগ দেখেছি, এখন আসুন অ্যাট্রিবিউটের অভ্যন্তরীণ কাজগুলি আরও একটু বিস্তারিতভাবে জেনে নিই।

খালি স্যান্ডবক্স অ্যাট্রিবিউট সহ কোনও আইফ্রেম থাকলে, ফ্রেম করা ডকুমেন্টটি সম্পূর্ণভাবে স্যান্ডবক্স করা হবে এবং এটি নিম্নলিখিত বিধিনিষেধের অধীন হবে:

ফ্রেম করা ডকুমেন্টে জাভাস্ক্রিপ্ট কাজ করবে না। এর মধ্যে শুধু স্ক্রিপ্ট ট্যাগের মাধ্যমে স্পষ্টভাবে লোড করা জাভাস্ক্রিপ্টই অন্তর্ভুক্ত নয়, ইনলাইন ইভেন্ট হ্যান্ডলার এবং javascript: URL-ও অন্তর্ভুক্ত। এর অর্থ হল, noscript ট্যাগে থাকা কন্টেন্ট এমনভাবে দেখানো হবে যেন ব্যবহারকারী নিজেই স্ক্রিপ্ট বন্ধ করে দিয়েছেন।
ফ্রেম করা ডকুমেন্টটি একটি অনন্য অরিজিনে লোড করা হয়েছে, যার অর্থ হল সমস্ত একই-অরিজিন চেক ব্যর্থ হবে; অনন্য অরিজিন অন্য কোনও অরিজিনের সাথে মেলে না, এমনকি নিজেদের সাথেও নয়। অন্যান্য প্রভাবের মধ্যে, এর অর্থ হল যে কোনও অরিজিনের কুকি বা অন্য কোনও স্টোরেজ মেকানিজমে (DOM স্টোরেজ, ইন্ডেক্স করা DB ইত্যাদি) স্টোর করা ডেটাতে ডকুমেন্টের অ্যাক্সেস নেই।
ফ্রেম করা ডকুমেন্ট নতুন উইন্ডো বা ডায়ালগ তৈরি করতে পারবে না (যেমন, window.open বা target="_blank"-এর মাধ্যমে)।
ফর্ম জমা দেওয়া যাবে না।
প্লাগ-ইন লোড হবে না।
ফ্রেম করা ডকুমেন্ট শুধুমাত্র নিজেকে নেভিগেট করতে পারে, তার টপ-লেভেল পেরেন্টকে নয়। window.top.location সেট করলে ব্যতিক্রম হবে এবং target="_top" সহ লিঙ্কে ক্লিক করলে কোনও প্রভাব পড়বে না।
অটোমেটিক ট্রিগার হওয়া ফিচার (অটোফোকাস করা ফর্ম এলিমেন্ট, অটোমেটিক চলতে থাকা ভিডিও ইত্যাদি) ব্লক করা হয়।
পয়েন্টার লক পাওয়া যায়নি।
iframes-এ seamless অ্যাট্রিবিউট উপেক্ষা করা হয়েছে, ফ্রেম করা ডকুমেন্টে এটি রয়েছে।

এটি অত্যন্ত কঠোর এবং সম্পূর্ণ স্যান্ডবক্সড iframe-এ লোড করা ডকুমেন্ট সত্যিই খুব কম ঝুঁকি তৈরি করে। অবশ্যই, এটি খুব বেশি মূল্যবান কিছু করতে পারে না: আপনি কিছু স্ট্যাটিক কন্টেন্টের জন্য সম্পূর্ণ স্যান্ডবক্স থেকে মুক্তি পেতে পারেন, তবে বেশিরভাগ সময় আপনি জিনিসগুলি একটু শিথিল করতে চাইবেন।

প্লাগ-ইন ছাড়া, এইসব বিধিনিষেধের প্রতিটি স্যান্ডবক্স অ্যাট্রিবিউটের ভ্যালুতে ফ্ল্যাগ যোগ করে তুলে নেওয়া যেতে পারে। স্যান্ডবক্স করা ডকুমেন্ট কখনও প্লাগ-ইন চালাতে পারে না, কারণ প্লাগ-ইন হল আনস্যান্ডবক্স করা নেটিভ কোড, তবে অন্য সবকিছুই ফেয়ার গেম:

allow-forms ফর্ম জমা দেওয়ার অনুমতি দেয়।
allow-popups পপ-আপ (শক!) দেখানোর অনুমতি দেয়।
allow-pointer-lock (অবাক করা!) পয়েন্টার লক করার অনুমতি দেয়।
allow-same-origin ডকুমেন্টকে তার উৎস বজায় রাখতে দেয়; https://example.com/ থেকে লোড করা পৃষ্ঠাগুলি সেই উৎসের ডেটাতে অ্যাক্সেস বজায় রাখবে।
allow-scripts জাভাস্ক্রিপ্ট এক্সিকিউশনের অনুমতি দেয় এবং ফিচার অটোমেটিক ট্রিগার করারও অনুমতি দেয় (কারণ জাভাস্ক্রিপ্টের মাধ্যমে এগুলি প্রয়োগ করা সহজ)।
allow-top-navigation টপ-লেভেল উইন্ডো নেভিগেট করার মাধ্যমে ডকুমেন্টকে ফ্রেম থেকে বেরিয়ে আসার অনুমতি দেয়।

এগুলি মনে রেখে, আমরা মূল্যায়ন করতে পারি যে কেন আমরা উপরের Twitter-এর উদাহরণে স্যান্ডবক্সিং ফ্ল্যাগের নির্দিষ্ট সেটটি পেয়েছি:

allow-scripts প্রয়োজন, কারণ ফ্রেমে লোড করা পৃষ্ঠাটি ব্যবহারকারীর ইন্টার‍্যাকশন ম্যানেজ করার জন্য কিছু জাভাস্ক্রিপ্ট রান করে।
allow-popups প্রয়োজন, কারণ বোতামটি নতুন উইন্ডোতে টুইট করার ফর্ম পপ-আপ করে।
allow-forms প্রয়োজন, কারণ টুইট করার ফর্ম জমা দেওয়ার যোগ্য হতে হবে।
allow-same-origin প্রয়োজন, কারণ তা না হলে twitter.com-এর কুকি অ্যাক্সেস করা যাবে না এবং ব্যবহারকারী ফর্ম পোস্ট করার জন্য লগ-ইন করতে পারবেন না।

একটি গুরুত্বপূর্ণ বিষয় হল, কোনও ফ্রেমে প্রয়োগ করা স্যান্ডবক্সিং ফ্ল্যাগ, স্যান্ডবক্সে তৈরি করা যেকোনও উইন্ডো বা ফ্রেমের ক্ষেত্রেও প্রযোজ্য হয়। এর অর্থ হল, ফ্রেমের স্যান্ডবক্সে আমাদের allow-forms যোগ করতে হবে, যদিও ফর্মটি শুধুমাত্র ফ্রেম পপ-আপ করা উইন্ডোতে থাকে।

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

বিশেষাধিকার পৃথকীকরণ

থার্ড-পার্টি কন্টেন্ট স্যান্ডবক্সিং করার মাধ্যমে তাদের অবিশ্বাসযোগ্য কোড কম-প্রিভিলেজ এনভায়রনমেন্টে রান করালে তা থেকে স্পষ্টতই সুবিধা পাওয়া যায়। কিন্তু তোমার নিজের কোডের কী হবে? আপনি নিজেকে বিশ্বাস করেন, তাই তো? তাহলে স্যান্ডবক্সিং নিয়ে চিন্তা করার কী আছে?

আমি এই প্রশ্নটি ঘুরিয়ে করতে চাই: আপনার কোডের যদি প্লাগ-ইনের প্রয়োজন না হয়, তাহলে প্লাগ-ইনে অ্যাক্সেস দেবেন কেন? সবচেয়ে ভালো ক্ষেত্রে, এটি এমন একটি বিশেষ সুবিধা যা আপনি কখনও ব্যবহার করেন না, সবচেয়ে খারাপ ক্ষেত্রে এটি আক্রমণকারীদের জন্য একটি সম্ভাব্য ভেক্টর যা তাদের সিস্টেমে প্রবেশ করতে সাহায্য করে। প্রত্যেকের কোডে বাগ থাকে এবং কার্যত প্রতিটি অ্যাপ্লিকেশনই কোনও না কোনও উপায়ে শোষণযোগ্য। আপনার নিজের কোড স্যান্ডবক্স করার অর্থ হল, কোনও আক্রমণকারী আপনার অ্যাপ্লিকেশনকে সফলভাবে ধ্বংস করলেও, তাকে অ্যাপ্লিকেশনের উৎসে সম্পূর্ণ অ্যাক্সেস দেওয়া হবে না; তারা শুধুমাত্র অ্যাপ্লিকেশনটি যা করতে পারে তা করতে পারবে। এখনও খারাপ, কিন্তু যতটা খারাপ হতে পারত ততটা নয়।

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

`eval()` নিরাপদে স্যান্ডবক্স করা হচ্ছে

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

Evalbox হল একটি দারুণ অ্যাপ্লিকেশন যা একটি স্ট্রিং নেয় এবং জাভাস্ক্রিপ্ট হিসেবে সেটির মূল্যায়ন করে। দারুণ, তাই না? ঠিক সেটাই যার জন্য আপনি এত বছর ধরে অপেক্ষা করছেন। এটি অবশ্যই একটি বিপজ্জনক অ্যাপ্লিকেশন, কারণ নির্বিচারে জাভাস্ক্রিপ্ট চালানোর অনুমতি দেওয়ার অর্থ হল যে কোনও এবং সমস্ত ডেটা যা একটি অরিজিন অফার করে তা দখল করার জন্য প্রস্তুত। আমরা Bad Things™ ঘটার ঝুঁকি কমাব, এটি নিশ্চিত করে যে কোডটি একটি স্যান্ডবক্সের মধ্যে কার্যকর করা হয়েছে, যা এটিকে কিছুটা নিরাপদ করে তোলে। আমরা ফ্রেমের কন্টেন্ট থেকে শুরু করে কোডের ভিতর থেকে বাইরে পর্যন্ত কাজ করব:

<!-- frame.html -->
<!DOCTYPE html>
<html>
    <head>
    <title>Evalbox's Frame</title>
    <script>
        window.addEventListener('message', function (e) {
        var mainWindow = e.source;
        var result = '';
        try {
            result = eval(e.data);
        } catch (e) {
            result = 'eval() threw an exception.';
        }
        mainWindow.postMessage(result, event.origin);
        });
    </script>
    </head>
</html>

ফ্রেমের মধ্যে, আমাদের কাছে একটি ন্যূনতম ডকুমেন্ট আছে যা window অবজেক্টের message ইভেন্টে হুক করে তার প্যারেন্ট থেকে মেসেজ শোনে। যখনই পেরেন্ট iframe-এর কন্টেন্টে postMessage এক্সিকিউট করে, এই ইভেন্ট ট্রিগার হবে, যা আমাদের পেরেন্ট যে স্ট্রিং এক্সিকিউট করতে চায়, তাতে আমাদের অ্যাক্সেস দেবে।

হ্যান্ডলারে, আমরা ইভেন্টের source অ্যাট্রিবিউট নিই, যা হল মূল উইন্ডো। আমরা এই তথ্য ব্যবহার করে আমাদের কঠোর পরিশ্রমের ফলাফল ব্যাক-আপ করব। তারপর আমরা কঠিন কাজগুলি করব, আমাদের দেওয়া ডেটা eval()-এ পাস করার মাধ্যমে। এই কলটি একটি ট্রাই ব্লকে র‍্যাপ করা হয়েছে, কারণ স্যান্ডবক্স করা iframe-এর মধ্যে নিষিদ্ধ অপারেশন ঘন ঘন DOM ব্যতিক্রম তৈরি করবে; আমরা সেগুলি ধরব এবং পরিবর্তে একটি বন্ধুত্বপূর্ণ ত্রুটি মেসেজ রিপোর্ট করব। অবশেষে, আমরা মূল উইন্ডোতে ফলাফল পোস্ট করি। এটি খুবই সহজ ব্যাপার।

প্যারেন্টও একইভাবে সহজ। আমরা কোডের জন্য textarea এবং এক্সিকিউশনের জন্য button সহ একটি ছোট UI তৈরি করব এবং আমরা স্যান্ডবক্স করা iframe-এর মাধ্যমে frame.html-এ পুল করব, যা শুধুমাত্র স্ক্রিপ্ট এক্সিকিউশনের অনুমতি দেবে:

<textarea id='code'></textarea>
<button id='safe'>eval() in a sandboxed frame.</button>
<iframe sandbox='allow-scripts'
        id='sandboxed'
        src='frame.html'></iframe>

এখন আমরা এক্সিকিউশনের জন্য সবকিছু কানেক্ট করব। প্রথমে, আমরা iframe থেকে উত্তর শুনব এবং আমাদের ব্যবহারকারীদের কাছে তা alert() করব। সম্ভবত একটি আসল অ্যাপ্লিকেশন কম বিরক্তিকর কিছু করবে:

window.addEventListener('message',
    function (e) {
        // Sandboxed iframes which lack the 'allow-same-origin'
        // header have "null" rather than a valid origin. This means you still
        // have to be careful about accepting data via the messaging API you
        // create. Check that source, and validate those inputs!
        var frame = document.getElementById('sandboxed');
        if (e.origin === "null" &amp;&amp; e.source === frame.contentWindow)
        alert('Result: ' + e.data);
    });

এরপর, আমরা button-এ ক্লিক করার জন্য একটি ইভেন্ট হ্যান্ডলার হুক আপ করব। ব্যবহারকারী ক্লিক করলে, আমরা textarea-এর বর্তমান কন্টেন্ট নিয়ে নেব এবং সেগুলি এক্সিকিউট করার জন্য ফ্রেমে পাস করব:

function evaluate() {
    var frame = document.getElementById('sandboxed');
    var code = document.getElementById('code').value;
    // Note that we're sending the message to "*", rather than some specific
    // origin. Sandboxed iframes which lack the 'allow-same-origin' header
    // don't have an origin which you can target: you'll have to send to any
    // origin, which might alow some esoteric attacks. Validate your output!
    frame.contentWindow.postMessage(code, '*');
}

document.getElementById('safe').addEventListener('click', evaluate);

সহজ, তাই না? আমরা খুব সহজ একটি মূল্যায়ন API তৈরি করেছি এবং আমরা নিশ্চিত যে মূল্যায়ন করা কোডের কাছে কুকি বা DOM স্টোরেজের মতো সংবেদনশীল তথ্যের অ্যাক্সেস নেই। একইভাবে, মূল্যায়ন করা কোড প্লাগ-ইন লোড করতে, নতুন উইন্ডো পপ-আপ করতে বা অন্যান্য বিরক্তিকর বা ক্ষতিকর অ্যাক্টিভিটি করতে পারে না।

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

তবে মনে রাখবেন, পেরেন্টের মতো একই উৎস থেকে আসা ফ্রেম করা কন্টেন্ট নিয়ে কাজ করার সময় আপনাকে খুব সতর্ক থাকতে হবে। https://example.com/-এর কোনও পৃষ্ঠা যদি একই অরিজিনের অন্য কোনও পৃষ্ঠাকে স্যান্ডবক্সের মাধ্যমে ফ্রেম করে যার মধ্যে allow-same-origin এবং allow-scripts ফ্ল্যাগ, দুটিই থাকে, তাহলে ফ্রেম করা পৃষ্ঠাটি পেরেন্ট পর্যন্ত পৌঁছাতে পারে এবং স্যান্ডবক্স অ্যাট্রিবিউট সম্পূর্ণভাবে সরিয়ে দিতে পারে।

আপনার স্যান্ডবক্সে খেলুন

স্যান্ডবক্সিং এখন আপনার জন্য বিভিন্ন ব্রাউজারে উপলভ্য: Firefox 17+, IE10+ এবং Chrome লেখার সময় (caniuse, অবশ্যই, একটি আপ-টু-ডেট সহায়তা টেবিল আছে)। আপনার অন্তর্ভুক্ত করা iframes-এ sandbox অ্যাট্রিবিউট প্রয়োগ করলে, আপনি তাদের দেখানো কন্টেন্টকে নির্দিষ্ট কিছু বিশেষাধিকার দিতে পারবেন, শুধুমাত্র সেইসব বিশেষাধিকার যা কন্টেন্ট সঠিকভাবে কাজ করার জন্য প্রয়োজনীয়। এটি আপনাকে থার্ড-পার্টি কন্টেন্ট অন্তর্ভুক্ত করার সাথে সম্পর্কিত ঝুঁকি কমানোর সুযোগ দেয়, যা কন্টেন্ট নিরাপত্তা নীতি-র মাধ্যমে ইতিমধ্যেই যা সম্ভব তার চেয়েও বেশি।

এছাড়াও, স্যান্ডবক্সিং হল একটি শক্তিশালী কৌশল যা কোনও চতুর আক্রমণকারী আপনার নিজের কোডের ত্রুটিগুলি কাজে লাগাতে পারবে এমন ঝুঁকি কমায়। একটি মনোলিথিক অ্যাপ্লিকেশনকে স্যান্ডবক্স করা পরিষেবার সেটে আলাদা করার মাধ্যমে, প্রতিটি পরিষেবা স্বয়ংসম্পূর্ণ কার্যকারিতার একটি ছোট অংশের জন্য দায়ী থাকে। এর ফলে আক্রমণকারীরা শুধুমাত্র নির্দিষ্ট ফ্রেমের কন্টেন্টই নয়, তাদের কন্ট্রোলারকেও আপস করতে বাধ্য হবে। এটি অনেক বেশি কঠিন কাজ, বিশেষ করে যেহেতু কন্ট্রোলারের স্কোপ অনেক বেশি কমানো যেতে পারে। বাকি কোডের জন্য ব্রাউজারের সাহায্য চাইলে, আপনি নিরাপত্তা-সম্পর্কিত প্রচেষ্টা সেই কোড অডিট করার জন্য ব্যয় করতে পারেন।

তবে এর অর্থ এই নয় যে স্যান্ডবক্সিং হল ইন্টারনেটে নিরাপত্তা সংক্রান্ত সমস্যার সম্পূর্ণ সমাধান। এটি বিবিধ প্রতিরোধ ব্যবস্থা অফার করে এবং আপনার ব্যবহারকারীদের ক্লায়েন্টের উপর আপনার নিয়ন্ত্রণ না থাকলে, আপনি এখনও আপনার সব ব্যবহারকারীর জন্য ব্রাউজার সহায়তার উপর নির্ভর করতে পারবেন না (আপনার ব্যবহারকারীদের ক্লায়েন্টের উপর আপনার নিয়ন্ত্রণ থাকলে -- যেমন, একটি এন্টারপ্রাইজ এনভায়রনমেন্ট -- তাহলে তো কথাই নেই!)। কোনও একদিন… তবে আপাতত স্যান্ডবক্সিং হল আপনার প্রতিরক্ষা শক্তিশালী করার জন্য সুরক্ষার আরেকটি স্তর, এটি সম্পূর্ণ প্রতিরক্ষা নয় যার উপর আপনি সম্পূর্ণভাবে নির্ভর করতে পারেন। তবুও, লেয়ারগুলি চমৎকার। আমি এটি ব্যবহার করার সাজেশন দিচ্ছি।