স্যান্ডবক্সযুক্ত আইফ্রেমে নিরাপদে খেলুন

Mike West

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

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

সর্বনিম্ন বিশেষাধিকার

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

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

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

টুইস্ট, কিন্তু যাচাই

টুইটারের "টুইট" বোতামটি কার্যকারিতার একটি দুর্দান্ত উদাহরণ যা একটি স্যান্ডবক্সের মাধ্যমে আপনার সাইটে আরও নিরাপদে এম্বেড করা যেতে পারে৷ টুইটার আপনাকে নিম্নলিখিত কোড সহ একটি আইফ্রেমের মাধ্যমে বোতামটি এম্বেড করতে দেয়:

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

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

স্যান্ডবক্সিং একটি সাদা তালিকার ভিত্তিতে কাজ করে। আমরা সমস্ত সম্ভাব্য অনুমতিগুলি সরিয়ে দিয়ে শুরু করি, এবং তারপর স্যান্ডবক্সের কনফিগারেশনে নির্দিষ্ট পতাকা যুক্ত করে স্বতন্ত্র ক্ষমতাগুলিকে আবার চালু করি৷ টুইটার উইজেটের জন্য, আমরা জাভাস্ক্রিপ্ট, পপআপ, ফর্ম জমা এবং 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 অ্যাট্রিবিউটের মানের মাধ্যমে স্পষ্টভাবে মঞ্জুর করিনি এমন কোনো সুযোগ-সুবিধার অ্যাক্সেস অস্বীকার করবে।

ক্ষমতার উপর দানাদার নিয়ন্ত্রণ

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

একটি খালি স্যান্ডবক্স বৈশিষ্ট্য সহ একটি iframe দেওয়া হলে, ফ্রেম করা নথিটি সম্পূর্ণরূপে স্যান্ডবক্স করা হবে, এটি নিম্নলিখিত বিধিনিষেধের সাপেক্ষে:

• জাভাস্ক্রিপ্ট ফ্রেমযুক্ত নথিতে কার্যকর হবে না। এটি শুধুমাত্র স্ক্রিপ্ট ট্যাগের মাধ্যমে স্পষ্টভাবে লোড করা JavaScript নয়, ইনলাইন ইভেন্ট হ্যান্ডলার এবং জাভাস্ক্রিপ্ট: URL গুলিও অন্তর্ভুক্ত করে৷ এর মানে হল যে নস্ক্রিপ্ট ট্যাগগুলিতে থাকা বিষয়বস্তু প্রদর্শিত হবে, ঠিক যেমন ব্যবহারকারী নিজেই স্ক্রিপ্ট অক্ষম করেছেন।
• ফ্রেম করা নথিটি একটি অনন্য মূলে লোড করা হয়েছে, যার অর্থ হল একই-অরিজিনের সমস্ত চেক ব্যর্থ হবে; অনন্য উত্সগুলি অন্য কোনও উত্সের সাথে মেলে না, এমনকি নিজেদেরও নয়৷ অন্যান্য প্রভাবগুলির মধ্যে, এর মানে হল যে ডকুমেন্টের কোনও মূলের কুকিজ বা অন্য কোনও স্টোরেজ মেকানিজম (DOM স্টোরেজ, ইনডেক্সড ডিবি, ইত্যাদি) সঞ্চিত ডেটাতে কোনও অ্যাক্সেস নেই।
• ফ্রেমযুক্ত নথিটি নতুন উইন্ডো বা ডায়ালগ তৈরি করতে পারে না (উদাহরণস্বরূপ 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 শীর্ষ-স্তরের উইন্ডোতে নেভিগেট করে নথিটিকে ফ্রেম থেকে বেরিয়ে আসতে দেয়।

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

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

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

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

বিশেষাধিকার বিচ্ছেদ

স্যান্ডবক্সিং তৃতীয় পক্ষের বিষয়বস্তু যাতে তাদের অবিশ্বস্ত কোড কম-সুবিধা পরিবেশে চালানোর জন্য মোটামুটি স্পষ্টতই উপকারী। কিন্তু আপনার নিজের কোড সম্পর্কে কি? আপনি নিজেকে বিশ্বাস করেন, তাই না? তাহলে স্যান্ডবক্সিং নিয়ে চিন্তা কেন?

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

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

নিরাপদে স্যান্ডবক্সিং eval()

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

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

<!-- 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" && 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/ এ একটি পৃষ্ঠা একই উত্সের অন্য একটি পৃষ্ঠাকে একটি স্যান্ডবক্সের সাথে ফ্রেম করে যাতে অনুমতি-একই-অরিজিন এবং অনুমতি-স্ক্রিপ্ট উভয়ই ফ্ল্যাগ অন্তর্ভুক্ত থাকে, তাহলে ফ্রেম করা পৃষ্ঠাটি অভিভাবকের কাছে পৌঁছাতে পারে এবং স্যান্ডবক্স বৈশিষ্ট্যটি সম্পূর্ণরূপে সরিয়ে ফেলতে পারে।

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

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

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

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

আরও পড়া

• " এইচটিএমএল 5 অ্যাপ্লিকেশনে বিশেষাধিকার বিচ্ছেদ " একটি আকর্ষণীয় কাগজ যা একটি ছোট কাঠামোর ডিজাইনের মাধ্যমে কাজ করে এবং তিনটি বিদ্যমান HTML5 অ্যাপে এর প্রয়োগ।

• স্যান্ডবক্সিং আরও বেশি নমনীয় হতে পারে যখন অন্য দুটি নতুন আইফ্রেম বৈশিষ্ট্যের সাথে মিলিত হয়: srcdoc , এবং seamless । আগেরটি আপনাকে HTTP অনুরোধের ওভারহেড ছাড়াই সামগ্রী সহ একটি ফ্রেম তৈরি করতে দেয় এবং পরবর্তীটি ফ্রেমযুক্ত সামগ্রীতে শৈলীকে প্রবাহিত করার অনুমতি দেয়। উভয়েরই এই মুহুর্তে মোটামুটি খারাপ ব্রাউজার সমর্থন রয়েছে (Chrome এবং WebKit nightlies)। কিন্তু ভবিষ্যতে একটি আকর্ষণীয় সমন্বয় হবে. আপনি, উদাহরণস্বরূপ, নিম্নলিখিত কোডের মাধ্যমে একটি নিবন্ধে স্যান্ডবক্স মন্তব্য করতে পারেন:

      <iframe sandbox seamless
              srcdoc="<p>This is a user's comment!
                         It can't execute script!
                         Hooray for safety!</p>"></iframe>