কঠোর কন্টেন্ট সিকিউরিটি পলিসি (CSP) সহ ক্রস-সাইট স্ক্রিপ্টিং (XSS) প্রশমিত করুন

Lukas Weichselbaum

ক্রস-সাইট স্ক্রিপ্টিং (XSS) , অর্থাৎ কোনো ওয়েব অ্যাপে ক্ষতিকারক স্ক্রিপ্ট প্রবেশ করানোর ক্ষমতা, এক দশকেরও বেশি সময় ধরে সবচেয়ে বড় ওয়েব নিরাপত্তা দুর্বলতাগুলোর মধ্যে একটি হয়ে রয়েছে।

কন্টেন্ট সিকিউরিটি পলিসি (CSP) হলো নিরাপত্তার একটি অতিরিক্ত স্তর যা XSS প্রতিরোধে সাহায্য করে। একটি CSP কনফিগার করতে, একটি ওয়েব পেজে Content-Security-Policy HTTP হেডারটি যোগ করুন এবং এমন মান নির্ধারণ করুন যা নিয়ন্ত্রণ করে যে ইউজার এজেন্ট সেই পেজের জন্য কোন রিসোর্সগুলো লোড করতে পারবে।

এই পৃষ্ঠাটি ব্যাখ্যা করে যে, XSS প্রতিরোধ করার জন্য কীভাবে ননস বা হ্যাশ-ভিত্তিক CSP ব্যবহার করতে হয়; প্রচলিত হোস্ট-অ্যালাওলিস্ট-ভিত্তিক CSP-গুলোর পরিবর্তে, যা প্রায়শই পৃষ্ঠাটিকে XSS-এর ঝুঁকিতে ফেলে, কারণ বেশিরভাগ কনফিগারেশনেই সেগুলোকে বাইপাস করা যায়।

মূল পরিভাষা: ননস (nonce) হলো একটি র‍্যান্ডম সংখ্যা যা শুধুমাত্র একবার ব্যবহৃত হয় এবং এটি একটি <script> ট্যাগকে বিশ্বস্ত হিসেবে চিহ্নিত করতে ব্যবহার করা যায়।

মূল পরিভাষা: হ্যাশ ফাংশন হলো একটি গাণিতিক ফাংশন যা কোনো ইনপুট মানকে হ্যাশ নামক একটি সংকুচিত সাংখ্যিক মানে রূপান্তরিত করে। আপনি একটি ইনলাইন <script> ট্যাগকে বিশ্বস্ত হিসেবে চিহ্নিত করতে হ্যাশ (উদাহরণস্বরূপ, SHA-256 ) ব্যবহার করতে পারেন।

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

আপনার কেন কঠোর CSP ব্যবহার করা উচিত?

আপনার সাইটে যদি আগে থেকেই script-src www.googleapis.com মতো দেখতে কোনো CSP থাকে, তবে সম্ভবত সেটি ক্রস-সাইট আক্রমণের বিরুদ্ধে কার্যকর নয়। এই ধরনের CSP-কে allowlist CSP বলা হয়। এগুলোর জন্য অনেক বেশি কাস্টমাইজেশনের প্রয়োজন হয় এবং আক্রমণকারীরা এগুলোকে বাইপাস করতে পারে।

ক্রিপ্টোগ্রাফিক ননস বা হ্যাশের উপর ভিত্তি করে তৈরি কঠোর সিএসপি এই সমস্যাগুলো এড়িয়ে চলে।

কঠোর CSP কাঠামো

একটি মৌলিক কঠোর কন্টেন্ট নিরাপত্তা নীতি নিম্নলিখিত HTTP প্রতিক্রিয়া হেডারগুলির মধ্যে একটি ব্যবহার করে:

ননস-ভিত্তিক কঠোর CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

হ্যাশ-ভিত্তিক কঠোর CSP

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

নিম্নলিখিত বৈশিষ্ট্যগুলি এই ধরনের একটি CSP-কে 'কঠোর' এবং ফলস্বরূপ সুরক্ষিত করে তোলে:

• সাইটের ডেভেলপার ব্যবহারকারীর ব্রাউজারে কোন <script> ট্যাগগুলো কার্যকর করার জন্য আস্থা রাখে, তা বোঝাতে এটি 'nonce-{RANDOM}' ননস অথবা 'sha256-{HASHED_INLINE_SCRIPT}' হ্যাশ ব্যবহার করে।
• এটি 'strict-dynamic' সেট করে, যা একটি বিশ্বস্ত স্ক্রিপ্ট দ্বারা তৈরি স্ক্রিপ্টগুলোকে স্বয়ংক্রিয়ভাবে চালানোর অনুমতি দিয়ে ননস- বা হ্যাশ-ভিত্তিক সিএসপি (CSP) স্থাপনের প্রচেষ্টা কমিয়ে দেয়। এটি বেশিরভাগ থার্ড-পার্টি জাভাস্ক্রিপ্ট লাইব্রেরি এবং উইজেটের ব্যবহারকেও বাধামুক্ত করে।
• এটি ইউআরএল অ্যালাওলিস্টের উপর ভিত্তি করে তৈরি নয়, তাই এটি সাধারণ সিএসপি বাইপাসের শিকার হয় না।
• এটি ইনলাইন ইভেন্ট হ্যান্ডলার বা javascript: URI-এর মতো অবিশ্বস্ত ইনলাইন স্ক্রিপ্টগুলিকে ব্লক করে।
• এটি ফ্ল্যাশের মতো বিপজ্জনক প্লাগইন নিষ্ক্রিয় করতে object-src সীমাবদ্ধ করে।
• এটি <base> ট্যাগের সংযোজন রোধ করতে base-uri সীমাবদ্ধ করে। এর ফলে আক্রমণকারীরা রিলেটিভ ইউআরএল থেকে লোড হওয়া স্ক্রিপ্টগুলোর অবস্থান পরিবর্তন করতে পারে না।

একটি কঠোর সিএসপি গ্রহণ করুন

একটি কঠোর সিএসপি গ্রহণ করতে হলে আপনাকে যা করতে হবে:

1. আপনার অ্যাপ্লিকেশনটি ননস-ভিত্তিক নাকি হ্যাশ-ভিত্তিক সিএসপি সেট করবে, তা স্থির করুন।
2. Strict CSP structure সেকশন থেকে CSP-টি কপি করুন এবং আপনার অ্যাপ্লিকেশন জুড়ে এটিকে রেসপন্স হেডার হিসেবে সেট করুন।
3. CSP-এর সাথে বেমানান প্যাটার্নগুলো অপসারণ করতে HTML টেমপ্লেট এবং ক্লায়েন্ট-সাইড কোড রিফ্যাক্টর করুন।
4. আপনার CSP স্থাপন করুন।

এই পুরো প্রক্রিয়া জুড়ে, আপনার সাইটে CSP আছে কিনা এবং সেটি XSS-এর বিরুদ্ধে কার্যকর হওয়ার জন্য যথেষ্ট কঠোর কিনা তা পরীক্ষা করতে আপনি Lighthouse (v7.3.0 এবং উচ্চতর সংস্করণ --preset=experimental ফ্ল্যাগ সহ) বেস্ট প্র্যাকটিসেস অডিট ব্যবহার করতে পারেন।

ধাপ ১: আপনার ননস-ভিত্তিক নাকি হ্যাশ-ভিত্তিক সিএসপি প্রয়োজন, তা স্থির করুন।

দুই ধরনের কঠোর CSP যেভাবে কাজ করে তা নিচে দেওয়া হলো:

ননস-ভিত্তিক সিএসপি

ননস-ভিত্তিক সিএসপি (CSP) ব্যবহার করে, আপনি রানটাইমে একটি র‍্যান্ডম নম্বর তৈরি করেন, সেটিকে আপনার সিএসপি-তে অন্তর্ভুক্ত করেন এবং আপনার পেজের প্রতিটি স্ক্রিপ্ট ট্যাগের সাথে যুক্ত করেন। একজন আক্রমণকারী আপনার পেজে কোনো ক্ষতিকারক স্ক্রিপ্ট অন্তর্ভুক্ত বা চালাতে পারে না, কারণ সেই স্ক্রিপ্টের জন্য তাদের সঠিক র‍্যান্ডম নম্বরটি অনুমান করতে হবে। এটি কেবল তখনই কাজ করে, যখন নম্বরটি অনুমানযোগ্য না হয় এবং প্রতিটি রেসপন্সের জন্য রানটাইমে নতুন করে তৈরি করা হয়।

সার্ভারে রেন্ডার করা HTML পেজগুলোর জন্য একটি ননস-ভিত্তিক CSP ব্যবহার করুন। এই পেজগুলোর জন্য, আপনি প্রতিটি রেসপন্সের জন্য একটি নতুন র‍্যান্ডম নম্বর তৈরি করতে পারেন।

হ্যাশ-ভিত্তিক সিএসপি

হ্যাশ-ভিত্তিক সিএসপি-র ক্ষেত্রে, প্রতিটি ইনলাইন স্ক্রিপ্ট ট্যাগের হ্যাশ সিএসপি-তে যুক্ত করা হয়। প্রতিটি স্ক্রিপ্টের একটি ভিন্ন হ্যাশ থাকে। একজন আক্রমণকারী আপনার পেজে কোনো ক্ষতিকারক স্ক্রিপ্ট অন্তর্ভুক্ত বা চালাতে পারে না, কারণ সেটি চালানোর জন্য স্ক্রিপ্টটির হ্যাশ আপনার সিএসপি-তে থাকা প্রয়োজন।

স্ট্যাটিক্যালি পরিবেশিত HTML পেজ বা ক্যাশ করার প্রয়োজন এমন পেজের জন্য হ্যাশ-ভিত্তিক CSP ব্যবহার করুন। উদাহরণস্বরূপ, আপনি Angular, React বা অন্য কোনো ফ্রেমওয়ার্ক দিয়ে তৈরি সিঙ্গেল-পেজ ওয়েব অ্যাপ্লিকেশনের জন্য হ্যাশ-ভিত্তিক CSP ব্যবহার করতে পারেন, যেগুলো সার্ভার-সাইড রেন্ডারিং ছাড়াই স্ট্যাটিক্যালি পরিবেশিত হয়।

ধাপ ২: একটি কঠোর CSP সেট করুন এবং আপনার স্ক্রিপ্টগুলো প্রস্তুত করুন।

CSP সেট করার সময় আপনার কাছে কয়েকটি বিকল্প থাকে:

• রিপোর্ট-অনলি মোড ( Content-Security-Policy-Report-Only ) অথবা এনফোর্সমেন্ট মোড ( Content-Security-Policy )। রিপোর্ট-অনলি মোডে, CSP তখনও কোনো রিসোর্স ব্লক করবে না, তাই আপনার সাইটের কোনো কিছু ভেঙে যাবে না, কিন্তু যা কিছু ব্লক করা হতো, সেগুলোর জন্য আপনি ত্রুটি দেখতে এবং রিপোর্ট পেতে পারবেন। স্থানীয়ভাবে, যখন আপনি আপনার CSP সেট করছেন, তখন এটি তেমন কোনো ব্যাপার না, কারণ উভয় মোডই আপনাকে ব্রাউজার কনসোলে ত্রুটিগুলো দেখায়। বরং, এনফোর্সমেন্ট মোড আপনাকে আপনার ড্রাফট CSP দ্বারা ব্লক করা রিসোর্সগুলো খুঁজে পেতে সাহায্য করতে পারে, কারণ কোনো রিসোর্স ব্লক করলে আপনার পেজটি ভাঙা বা ত্রুটিপূর্ণ দেখাতে পারে। রিপোর্ট-অনলি মোড এই প্রক্রিয়ার পরবর্তী পর্যায়ে সবচেয়ে বেশি কার্যকর হয় ( ধাপ ৫ দেখুন)।
• হেডার বা এইচটিএমএল <meta> ট্যাগ। লোকাল ডেভেলপমেন্টের জন্য, আপনার সিএসপি (CSP) পরিবর্তন করতে এবং এটি আপনার সাইটকে কীভাবে প্রভাবিত করছে তা দ্রুত দেখতে একটি <meta> ট্যাগ আরও সুবিধাজনক হতে পারে। তবে:
  • পরবর্তীতে, প্রোডাকশনে আপনার CSP ডেপ্লয় করার সময়, আমরা এটিকে একটি HTTP হেডার হিসেবে সেট করার পরামর্শ দিই।
  • আপনি যদি আপনার CSP-কে শুধুমাত্র-রিপোর্ট মোডে সেট করতে চান, তাহলে আপনাকে এটিকে হেডার হিসেবে সেট করতে হবে, কারণ CSP মেটা ট্যাগগুলো শুধুমাত্র-রিপোর্ট মোড সমর্থন করে না।

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

const app = express();

app.get('/', function(request, response) {
  // Generate a new random nonce value for every response.
  const nonce = crypto.randomBytes(16).toString("base64");

  // Set the strict nonce-based CSP response header
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response<.set(&>quot;Content-Security-Policy", csp);

  // Every script tag in your application should set the `nonce` attribute to this value.
  response.render(template, { nonce: nonce });
});

বিকল্প B: হ্যাশ-ভিত্তিক CSP প্রতিক্রিয়া হেডার

আপনার অ্যাপ্লিকেশনে নিম্নলিখিত Content-Security-Policy HTTP রেসপন্স হেডারটি সেট করুন:

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

একাধিক ইনলাইন স্ক্রিপ্টের জন্য সিনট্যাক্সটি নিম্নরূপ: 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}' ।

ডাইনামিকভাবে সোর্স করা স্ক্রিপ্ট লোড করুন

আপনি ইনলাইন স্ক্রিপ্ট ব্যবহার করে ডায়নামিকভাবে থার্ড-পার্টি স্ক্রিপ্ট লোড করতে পারেন।

CSP দ্বারা অনুমোদিত

<script>
  var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];

  scripts.forEach(function(scriptUrl) {
    var s = document.createElement('script');
    s.src = scriptUrl;
    s.async = false; // to preserve execution order
    document.hea<d.appen>dChild(s);
  });
/script

এই স্ক্রিপ্টটি চালানোর জন্য, আপনাকে ইনলাইন স্ক্রিপ্টটির হ্যাশ গণনা করতে হবে এবং {HASHED_INLINE_SCRIPT} প্লেসহোল্ডারটি প্রতিস্থাপন করে সেটি CSP রেসপন্স হেডারে যোগ করতে হবে। হ্যাশের সংখ্যা কমাতে, আপনি সমস্ত ইনলাইন স্ক্রিপ্টকে একটি একক স্ক্রিপ্টে একীভূত করতে পারেন। এটি বাস্তবে দেখতে, এই উদাহরণ এবং এর কোডটি দেখুন।

CSP দ্বারা অবরুদ্ধ

<script src="https://example.org/fo><o.js&qu>o<t;/script
script src="https://exam><ple.org>/bar.js"/script

CSP এই স্ক্রিপ্টগুলোকে ব্লক করে, কারণ এগুলো ডাইনামিকভাবে যোগ করা হয়নি এবং এগুলোর কোনো integrity অ্যাট্রিবিউট নেই যা একটি অনুমোদিত সোর্সের সাথে মেলে।

স্ক্রিপ্ট লোড করার বিবেচ্য বিষয়

ইনলাইন স্ক্রিপ্ট উদাহরণটিতে s.async = false যোগ করা হয়েছে, যাতে bar আগে লোড হলেও foo স্ক্রিপ্টটি bar এর আগে এক্সিকিউট হয়। এই কোড স্নিপেটে, s.async = false স্ক্রিপ্টগুলো লোড হওয়ার সময় পার্সারকে ব্লক করে না, কারণ স্ক্রিপ্টগুলো ডাইনামিকভাবে যোগ করা হয়। পার্সার শুধুমাত্র স্ক্রিপ্টগুলো এক্সিকিউট হওয়ার সময়েই থামে, যেমনটা async স্ক্রিপ্টের ক্ষেত্রে হয়ে থাকে। তবে, এই কোড স্নিপেটটির ক্ষেত্রে মনে রাখবেন:

• ডকুমেন্টটি ডাউনলোড শেষ হওয়ার আগেই এক বা উভয় স্ক্রিপ্ট চালু হয়ে যেতে পারে। আপনি যদি চান যে স্ক্রিপ্টগুলো চালু হওয়ার আগেই ডকুমেন্টটি প্রস্তুত হয়ে যাক, তাহলে স্ক্রিপ্টগুলো যুক্ত করার আগে DOMContentLoaded ইভেন্টের জন্য অপেক্ষা করুন। স্ক্রিপ্টগুলো যথেষ্ট আগে ডাউনলোড শুরু না করার কারণে যদি পারফরম্যান্সে সমস্যা হয়, তাহলে পেজের আরও আগে প্রিলোড ট্যাগ ব্যবহার করুন।
• defer = true কোনো কাজ করে না। যদি আপনার ওই নির্দিষ্ট আচরণের প্রয়োজন হয়, তবে প্রয়োজনমতো স্ক্রিপ্টটি ম্যানুয়ালি চালান।

ধাপ ৩: এইচটিএমএল টেমপ্লেট এবং ক্লায়েন্ট-সাইড কোড রিফ্যাক্টর করুন

ইনলাইন ইভেন্ট হ্যান্ডলার (যেমন onclick="…" , onerror="…" ) এবং জাভাস্ক্রিপ্ট ইউআরআই ( <a href="javascript:…"> ) স্ক্রিপ্ট চালানোর জন্য ব্যবহার করা যেতে পারে। এর মানে হলো, কোনো আক্রমণকারী যদি একটি XSS বাগ খুঁজে পায়, তবে সে এই ধরনের HTML ইনজেক্ট করে ক্ষতিকারক জাভাস্ক্রিপ্ট চালাতে পারে। একটি ননস- বা হ্যাশ-ভিত্তিক CSP এই ধরনের মার্কআপের ব্যবহার নিষিদ্ধ করে। যদি আপনার সাইট এই প্যাটার্নগুলোর কোনোটি ব্যবহার করে থাকে, তবে আপনাকে সেগুলোকে আরও নিরাপদ বিকল্পে রিফ্যাক্টর করতে হবে।

যদি আপনি পূর্ববর্তী ধাপে CSP সক্রিয় করে থাকেন, তাহলে যখনই CSP কোনো বেমানান প্যাটার্ন ব্লক করবে, আপনি কনসোলে CSP লঙ্ঘন দেখতে পাবেন।

বেশিরভাগ ক্ষেত্রে, এর সমাধান খুবই সহজ:

ইনলাইন ইভেন্ট হ্যান্ডলারগুলি রিফ্যাক্টর করুন

<span id="th>ings&quo<t;A t>h<ing./span
script nonce=>"${nonce}"
  document.getElementById('things').addEventL<istener>('click', doThings);
/script

<span onclick="doThing>s();&quo<t;A t>hing./span

javascript: ইউআরআই

<a id=">;fo<o&>q<uot;foo/a
script nonce=>"${nonce}"
  document.getElementById('foo').addEventList<ener(&#>39;click', linkClicked);
/script

<a href="javascript:linkClick>ed(<)&>quot;foo/a

আপনার জাভাস্ক্রিপ্ট থেকে eval() সরিয়ে ফেলুন

যদি আপনার অ্যাপ্লিকেশন JSON স্ট্রিং সিরিয়ালাইজেশনকে JS অবজেক্টে রূপান্তর করতে eval() ব্যবহার করে, তবে আপনার উচিত এই ধরনের ইনস্ট্যান্সগুলোকে JSON.parse() -এ রিফ্যাক্টর করা, যা আরও দ্রুততর ।

যদি আপনি eval() এর সমস্ত ব্যবহার বাদ দিতে না পারেন, তাহলেও আপনি একটি কঠোর ননস-ভিত্তিক CSP সেট করতে পারেন, কিন্তু সেক্ষেত্রে আপনাকে 'unsafe-eval' CSP কীওয়ার্ডটি ব্যবহার করতে হবে, যা আপনার পলিসিকে কিছুটা কম সুরক্ষিত করে তোলে।

এই কঠোর CSP কোডল্যাবটিতে আপনি এই ধরনের রিফ্যাক্টরিংয়ের আরও অনেক উদাহরণ খুঁজে পাবেন:

ধাপ ৪ (ঐচ্ছিক): পুরোনো ব্রাউজার সংস্করণ সমর্থন করার জন্য ফলব্যাক যোগ করুন।

যদি আপনাকে পুরোনো ব্রাউজার সংস্করণগুলো সমর্থন করতে হয়:

• strict-dynamic ব্যবহার করার জন্য Safari-এর আগের সংস্করণগুলোর ক্ষেত্রে ফলব্যাক হিসেবে https: যোগ করতে হয়। যখন আপনি এটি করেন:
  • যেসব ব্রাউজার strict-dynamic সমর্থন করে, তারা https: ফলব্যাকটি উপেক্ষা করে, তাই এটি পলিসির কার্যকারিতা কমাবে না।
  • পুরানো ব্রাউজারগুলিতে, বাহ্যিকভাবে আসা স্ক্রিপ্টগুলি কেবল তখনই লোড হতে পারে যদি সেগুলি HTTPS অরিজিন থেকে আসে। এটি একটি কঠোর CSP-এর চেয়ে কম সুরক্ষিত, কিন্তু এটি javascript: URIs ইনজেকশনের মতো কিছু সাধারণ XSS আক্রমণের কারণ প্রতিরোধ করে।
• খুব পুরোনো ব্রাউজার সংস্করণগুলির (৪ বছরের বেশি) সাথে সামঞ্জস্যতা নিশ্চিত করতে, আপনি ফলব্যাক হিসেবে unsafe-inline যোগ করতে পারেন। কোনো CSP ননস বা হ্যাশ উপস্থিত থাকলে, সব সাম্প্রতিক ব্রাউজার unsafe-inline উপেক্ষা করে।

Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 9;none';
  base-uri 'none';

ধাপ ৫: আপনার CSP স্থাপন করুন

আপনার স্থানীয় ডেভেলপমেন্ট এনভায়রনমেন্টে আপনার CSP কোনো বৈধ স্ক্রিপ্ট ব্লক করছে না, এটি নিশ্চিত করার পর, আপনি আপনার CSP-কে স্টেজিং-এ এবং তারপর আপনার প্রোডাকশন এনভায়রনমেন্টে ডেপ্লয় করতে পারেন:

1. (ঐচ্ছিক) Content-Security-Policy-Report-Only হেডার ব্যবহার করে আপনার CSP শুধুমাত্র-রিপোর্ট মোডে স্থাপন করুন। CSP বিধিনিষেধ প্রয়োগ করা শুরু করার আগে, প্রোডাকশনে একটি নতুন CSP-এর মতো সম্ভাব্য ব্রেকিং চেঞ্জ পরীক্ষা করার জন্য রিপোর্ট-অনলি মোড বেশ সুবিধাজনক। রিপোর্ট-অনলি মোডে, আপনার CSP আপনার অ্যাপের আচরণকে প্রভাবিত করে না, কিন্তু ব্রাউজার যখন আপনার CSP-এর সাথে বেমানান প্যাটার্নের সম্মুখীন হয়, তখন এটি কনসোল এরর এবং ভায়োলেশন রিপোর্ট তৈরি করে, যাতে আপনি দেখতে পারেন যে আপনার শেষ ব্যবহারকারীদের জন্য কী সমস্যা তৈরি হতো। আরও তথ্যের জন্য, রিপোর্টিং এপিআই (Reporting API) দেখুন।
2. যখন আপনি নিশ্চিত হবেন যে আপনার CSP আপনার সাইটের ব্যবহারকারীদের জন্য কোনো সমস্যা তৈরি করবে না, Content-Security-Policy রেসপন্স হেডার ব্যবহার করে আপনার CSP প্রয়োগ করুন। আমরা সার্ভার-সাইডে একটি HTTP হেডার ব্যবহার করে আপনার CSP সেট করার পরামর্শ দিই, কারণ এটি একটি <meta> ট্যাগের চেয়ে বেশি সুরক্ষিত। এই ধাপটি সম্পন্ন করার পর, আপনার CSP আপনার অ্যাপকে XSS থেকে রক্ষা করা শুরু করবে।

সীমাবদ্ধতা

একটি কঠোর CSP সাধারণত নিরাপত্তার একটি শক্তিশালী অতিরিক্ত স্তর প্রদান করে যা XSS প্রতিরোধ করতে সাহায্য করে। বেশিরভাগ ক্ষেত্রে, CSP javascript: URIs-এর মতো বিপজ্জনক প্যাটার্ন প্রত্যাখ্যান করার মাধ্যমে আক্রমণের ক্ষেত্র উল্লেখযোগ্যভাবে হ্রাস করে। তবে, আপনি কোন ধরনের CSP ব্যবহার করছেন (ননস, হ্যাশ, 'strict-dynamic' সহ বা ছাড়া) তার উপর ভিত্তি করে, এমন কিছু পরিস্থিতি রয়েছে যেখানে CSP আপনার অ্যাপকে ততটা ভালোভাবে সুরক্ষা দেয় না:

• যদি আপনি কোনো স্ক্রিপ্টকে ননস (nonce) করেন, কিন্তু সেই <script> এলিমেন্টের বডি বা src প্যারামিটারে সরাসরি ইনজেকশন থাকে।
• ডাইনামিকভাবে তৈরি করা স্ক্রিপ্টের ( document.createElement('script') ) অবস্থানে যদি ইনজেকশন ঘটে, যার মধ্যে এমন যেকোনো লাইব্রেরি ফাংশনও অন্তর্ভুক্ত যা তাদের আর্গুমেন্টের মানের উপর ভিত্তি করে script DOM নোড তৈরি করে। এর মধ্যে কিছু সাধারণ API যেমন jQuery-এর .html() , এবং jQuery < 3.0-এর .get() ও .post() অন্তর্ভুক্ত।
• পুরোনো AngularJS অ্যাপ্লিকেশনগুলিতে টেমপ্লেট ইনজেকশন থাকলে, একজন আক্রমণকারী AngularJS টেমপ্লেটে ইনজেক্ট করার মাধ্যমে তা ব্যবহার করে যথেচ্ছ জাভাস্ক্রিপ্ট চালাতে পারে।
• যদি পলিসিতে 'unsafe-eval' থাকে, তাহলে eval() , setTimeout() এবং আরও কিছু কদাচিৎ ব্যবহৃত API-তে ইনজেকশন ঘটবে।

কোড রিভিউ এবং সিকিউরিটি অডিটের সময় ডেভেলপার ও সিকিউরিটি ইঞ্জিনিয়ারদের এই ধরনের প্যাটার্নগুলোর প্রতি বিশেষ মনোযোগ দেওয়া উচিত। এই বিষয়গুলো সম্পর্কে আরও বিস্তারিত জানতে পারবেন “Content Security Policy: A Successful Mess Between Hardening and Mitigation” শীর্ষক লেখাটিতে।

আরও পড়ুন

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