কঠোর কন্টেন্ট সুরক্ষা সংক্রান্ত নীতি (CSP) প্রয়োগ করে ক্রস-সাইট স্ক্রিপ্টিং (XSS) কমানো

Lukas Weichselbaum

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 52.
  • Safari: 15.4.

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

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

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

মূল শব্দ: nonce হল একটি র‍্যান্ডম নম্বর যা শুধুমাত্র একবার ব্যবহার করা হয় এবং আপনি এটি ব্যবহার করে কোনও <script> ট্যাগকে বিশ্বস্ত হিসেবে চিহ্নিত করতে পারেন।

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

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

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

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

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

কঠোর CSP স্ট্রাকচার

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

ননস-ভিত্তিক স্ট্রিক্ট CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';
ননস-ভিত্তিক স্ট্রিক্ট CSP কীভাবে কাজ করে।

হ্যাশ-ভিত্তিক স্ট্রিক্ট CSP

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

নিম্নলিখিত প্রপার্টিগুলি এই ধরনের CSP-কে "কঠোর" এবং সেই কারণে সুরক্ষিত করে তোলে:

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

কঠোর CSP গ্রহণ করুন

স্ট্রিক্ট CSP গ্রহণ করতে, আপনাকে এগুলি করতে হবে:

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

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

Lighthouse রিপোর্ট সতর্ক করে যে এনফোর্সমেন্ট মোডে কোনও CSP পাওয়া যায়নি।
আপনার সাইটে CSP না থাকলে, Lighthouse এই সতর্কতা দেখায়।

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

স্ট্রিক্ট CSP-এর দুটি ধরন কীভাবে কাজ করে তা এখানে দেওয়া হল:

Nonce-ভিত্তিক CSP

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

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

হ্যাশ-ভিত্তিক CSP

হ্যাশ-ভিত্তিক CSP-এর ক্ষেত্রে, প্রতিটি ইনলাইন স্ক্রিপ্ট ট্যাগের হ্যাশ CSP-তে যোগ করা হয়। প্রতিটি স্ক্রিপ্টের আলাদা হ্যাশ আছে। কোনও আক্রমণকারী আপনার পৃষ্ঠায় ক্ষতিকর স্ক্রিপ্ট যোগ বা রান করতে পারবে না, কারণ সেটি রান করার জন্য স্ক্রিপ্টের হ্যাশ আপনার CSP-তে থাকতে হবে।

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

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

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

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

বিকল্প ক: Nonce-ভিত্তিক CSP

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

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

CSP-এর জন্য ননস জেনারেট করুন

ননস হল একটি র‍্যান্ডম নম্বর যা প্রতিবার পৃষ্ঠা লোড করার সময় একবারই ব্যবহার করা হয়। আক্রমণকারী ননস ভ্যালু অনুমান করতে না পারলে, ননস-ভিত্তিক CSP শুধুমাত্র XSS প্রশমিত করতে পারে। একটি CSP ননস অবশ্যই হতে হবে:

  • ক্রিপ্টোগ্রাফিক্যালি শক্তিশালী র‍্যান্ডম ভ্যালু (আদর্শগতভাবে ১২৮+ বিট দৈর্ঘ্যের)
  • প্রতিটি উত্তরের জন্য নতুন করে জেনারেট করা হয়
  • Base64 এনকোড করা

সার্ভার-সাইড ফ্রেমওয়ার্কে কীভাবে CSP নোন্স যোগ করতে হয় তার কিছু উদাহরণ এখানে দেওয়া হল:

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("Content-Security-Policy", csp);

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

<script>টি এলিমেন্টে nonce অ্যাট্রিবিউট যোগ করুন

নোন্স-ভিত্তিক CSP-এর ক্ষেত্রে, প্রতিটি <script> এলিমেন্টে অবশ্যই একটি nonce অ্যাট্রিবিউট থাকতে হবে যা CSP হেডারে নির্দিষ্ট করা র‍্যান্ডম নোন্স ভ্যালুর সাথে মেলে। সব স্ক্রিপ্টে একই nonce থাকতে পারে। প্রথম ধাপ হল, সব স্ক্রিপ্টে এইসব অ্যাট্রিবিউট যোগ করা যাতে CSP সেগুলি অনুমোদন করে।

বিকল্প খ: হ্যাশ-ভিত্তিক 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.head.appendChild(s);
  });
</script>
 এই স্ক্রিপ্ট রান করতে, আপনাকে অবশ্যই ইনলাইন স্ক্রিপ্টের হ্যাশ গণনা করতে হবে এবং {HASHED_INLINE_SCRIPT} প্লেসহোল্ডার পরিবর্তন করে এটি CSP রেসপন্স হেডারে যোগ করতে হবে। হ্যাশের সংখ্যা কমাতে, আপনি সব ইনলাইন স্ক্রিপ্টকে একটি স্ক্রিপ্টে মার্জ করতে পারেন। এটি কীভাবে কাজ করে তা দেখতে, এই উদাহরণ এবং এর কোড দেখুন।
CSP দ্বারা ব্লক করা হয়েছে
<script src="https://example.org/foo.js"></script>
<script src="https://example.org/bar.js"></script>
 CSP এইসব স্ক্রিপ্ট ব্লক করে কারণ সেগুলি ডায়নামিকভাবে যোগ করা হয়নি এবং সেগুলিতে কোনও integrity অ্যাট্রিবিউট নেই যা অনুমোদিত সোর্সের সাথে মেলে।

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

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

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

ধাপ ৩: HTML টেমপ্লেট ও ক্লায়েন্ট-সাইড কোড রিফ্যাক্টর করা

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

আপনি আগের ধাপে CSP চালু করে থাকলে, CSP যখনই কোনও বেমানান প্যাটার্ন ব্লক করবে, তখনই আপনি কনসোলে CSP লঙ্ঘন দেখতে পাবেন।

Chrome ডেভেলপার কনসোলে CSP লঙ্ঘন সংক্রান্ত রিপোর্ট।
ব্লক করা কোডের জন্য কনসোল সংক্রান্ত সমস্যা।

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

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

CSP-এর মাধ্যমে অনুমোদিত
<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things').addEventListener('click', doThings);
</script>
 জাভাস্ক্রিপ্ট ব্যবহার করে রেজিস্টার করা ইভেন্ট হ্যান্ডলারকে CSP অনুমতি দেয়।
CSP দ্বারা ব্লক করা হয়েছে
<span onclick="doThings();">A thing.</span>
 CSP ইনলাইন ইভেন্ট হ্যান্ডলার ব্লক করে।

javascript:টি URI রিফ্যাক্টর করুন

CSP-এর মাধ্যমে অনুমোদিত
<a id="foo">foo</a>
<script nonce="${nonce}">
  document.getElementById('foo').addEventListener('click', linkClicked);
</script>
 জাভাস্ক্রিপ্ট ব্যবহার করে রেজিস্টার করা ইভেন্ট হ্যান্ডলারকে CSP অনুমতি দেয়।
CSP দ্বারা ব্লক করা হয়েছে
<a href="javascript:linkClicked()">foo</a>
 CSP জাভাস্ক্রিপ্ট ব্লক করে: URI.

আপনার জাভাস্ক্রিপ্ট থেকে eval() সরান

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

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

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

ধাপ ৪ (ঐচ্ছিক): পুরনো ব্রাউজার ভার্সনে কাজ করার জন্য ফলব্যাক যোগ করুন

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 52.
  • Safari: 15.4.

আপনাকে যদি পুরনো ব্রাউজার ভার্সনে কাজ করতে হয়:

  • strict-dynamic ব্যবহার করার জন্য Safari-এর আগের ভার্সনের ফলব্যাক হিসেবে https: যোগ করতে হবে। আপনি এটি করলে:
    • strict-dynamic কাজ করে এমন সব ব্রাউজার https: ফলব্যাক উপেক্ষা করে, তাই এটি নীতির কার্যকারিতা কমাবে না।
    • পুরনো ব্রাউজারে, এক্সটার্নাল সোর্স থেকে পাওয়া স্ক্রিপ্ট শুধুমাত্র তখনই লোড হতে পারে যদি সেগুলি HTTPS অরিজিন থেকে আসে। এটি কঠোর CSP-এর থেকে কম সুরক্ষিত, তবে এটি এখনও javascript: URI-এর ইনজেকশনের মতো কিছু সাধারণ XSS কারণ প্রতিরোধ করে।
  • খুব পুরনো ব্রাউজার ভার্সনের (৪+ বছর) সাথে মানানসই কিনা তা নিশ্চিত করতে, আপনি ফলব্যাক হিসেবে unsafe-inline যোগ করতে পারেন। CSP ননস বা হ্যাশ থাকলে, সব সাম্প্রতিক ব্রাউজার unsafe-inline উপেক্ষা করে।
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src '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: URI-এর মতো বিপজ্জনক প্যাটার্ন প্রত্যাখ্যান করে। তবে, আপনি যে ধরনের CSP ব্যবহার করছেন (ননসেস, হ্যাশ, 'strict-dynamic' সহ বা ছাড়া) তার উপর ভিত্তি করে, এমন কিছু পরিস্থিতি আছে যেখানে CSP আপনার অ্যাপকে সুরক্ষিত করে না:

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

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

আরও পড়ুন