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

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • প্রান্ত: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4.

উৎস

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

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

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

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

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

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

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

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

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

কঠোর সিএসপি কাঠামো

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

ননস-ভিত্তিক কঠোর সিএসপি

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';

নিম্নলিখিত বৈশিষ্ট্যগুলি একটি সিএসপিকে এইরকম একটি "কঠোর" এবং তাই সুরক্ষিত করে:

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

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

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

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

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

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

ধাপ 1: আপনার একটি ননস- বা হ্যাশ-ভিত্তিক CSP প্রয়োজন কিনা তা নির্ধারণ করুন

দুই ধরনের কঠোর সিএসপি কীভাবে কাজ করে তা এখানে:

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

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

সার্ভারে রেন্ডার করা এইচটিএমএল পৃষ্ঠাগুলির জন্য একটি অ-ভিত্তিক CSP ব্যবহার করুন। এই পৃষ্ঠাগুলির জন্য, আপনি প্রতিটি প্রতিক্রিয়ার জন্য একটি নতুন র্যান্ডম নম্বর তৈরি করতে পারেন।

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

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

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

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

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

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

বিকল্প A: ননস-ভিত্তিক CSP

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

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

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

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

  • একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী র্যান্ডম মান (আদর্শভাবে দৈর্ঘ্যে 128+ বিট)
  • নতুনভাবে প্রতিটি প্রতিক্রিয়া জন্য উত্পন্ন
  • বেস64 এনকোড করা হয়েছে

সার্ভার-সাইড ফ্রেমওয়ার্কগুলিতে কীভাবে একটি 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 হেডারে নির্দিষ্ট করা র্যান্ডম নন্স মানের সাথে মেলে। সব স্ক্রিপ্টে একই নন্স থাকতে পারে। প্রথম ধাপ হল সমস্ত স্ক্রিপ্টে এই বৈশিষ্ট্যগুলি যোগ করা যাতে CSP তাদের অনুমতি দেয়।

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

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

স্ক্রিপ্ট লোডিং বিবেচনা

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

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

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

ইনলাইন ইভেন্ট হ্যান্ডলার (যেমন onclick="…" , onerror="…" ) এবং JavaScript URIs ( <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: ইউআরআই

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 ব্লক জাভাস্ক্রিপ্ট: URIs.

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

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

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

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

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

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • প্রান্ত: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4.

উৎস

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

  • strict-dynamic ব্যবহার করার জন্য সাফারির পূর্ববর্তী সংস্করণগুলির জন্য একটি ফলব্যাক হিসাবে https: যোগ করা প্রয়োজন। আপনি যখন এটি করবেন:
    • strict-dynamic সমর্থন করে এমন সমস্ত ব্রাউজার https: ফলব্যাককে উপেক্ষা করে, তাই এটি নীতির শক্তি হ্রাস করবে না।
    • পুরানো ব্রাউজারগুলিতে, বাহ্যিকভাবে প্রাপ্ত স্ক্রিপ্টগুলি শুধুমাত্র লোড হতে পারে যদি সেগুলি একটি HTTPS উত্স থেকে আসে৷ এটি একটি কঠোর সিএসপির চেয়ে কম নিরাপদ, তবে এটি এখনও javascript: URIs।
  • খুব পুরানো ব্রাউজার সংস্করণের সাথে সামঞ্জস্যতা নিশ্চিত করতে (4+ বছর), আপনি একটি ফলব্যাক হিসাবে unsafe-inline যোগ করতে পারেন। একটি CSP ননস বা হ্যাশ উপস্থিত থাকলে সমস্ত সাম্প্রতিক ব্রাউজারগুলি unsafe-inline উপেক্ষা করে।
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

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

আপনার স্থানীয় উন্নয়ন পরিবেশে আপনার CSP কোনো বৈধ স্ক্রিপ্ট ব্লক করে না তা নিশ্চিত করার পরে, আপনি আপনার CSP মঞ্চায়নে, তারপর আপনার উৎপাদন পরিবেশে স্থাপন করতে পারেন:

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

সীমাবদ্ধতা

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

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

কোড পর্যালোচনা এবং নিরাপত্তা নিরীক্ষার সময় বিকাশকারী এবং নিরাপত্তা প্রকৌশলীদের এই ধরনের নিদর্শনগুলিতে বিশেষ মনোযোগ দেওয়া উচিত। আপনি বিষয়বস্তু নিরাপত্তা নীতিতে এই ক্ষেত্রে আরও বিশদ বিবরণ পেতে পারেন: কঠোরকরণ এবং প্রশমনের মধ্যে একটি সফল মেস

আরও পড়া

,

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • প্রান্ত: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4.

উৎস

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

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

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

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

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

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

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

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

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

কঠোর সিএসপি কাঠামো

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

ননস-ভিত্তিক কঠোর সিএসপি

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';

নিম্নলিখিত বৈশিষ্ট্যগুলি একটি সিএসপিকে এইরকম একটি "কঠোর" এবং তাই সুরক্ষিত করে:

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

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

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

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

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

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

ধাপ 1: আপনার একটি ননস- বা হ্যাশ-ভিত্তিক CSP প্রয়োজন কিনা তা নির্ধারণ করুন

দুই ধরনের কঠোর সিএসপি কীভাবে কাজ করে তা এখানে:

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

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

সার্ভারে রেন্ডার করা এইচটিএমএল পৃষ্ঠাগুলির জন্য একটি অ-ভিত্তিক CSP ব্যবহার করুন। এই পৃষ্ঠাগুলির জন্য, আপনি প্রতিটি প্রতিক্রিয়ার জন্য একটি নতুন র্যান্ডম নম্বর তৈরি করতে পারেন।

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

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

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

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

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

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

বিকল্প A: ননস-ভিত্তিক CSP

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

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

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

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

  • একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী র্যান্ডম মান (আদর্শভাবে দৈর্ঘ্যে 128+ বিট)
  • নতুনভাবে প্রতিটি প্রতিক্রিয়া জন্য উত্পন্ন
  • বেস64 এনকোড করা হয়েছে

সার্ভার-সাইড ফ্রেমওয়ার্কগুলিতে কীভাবে একটি 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 হেডারে নির্দিষ্ট করা র্যান্ডম নন্স মানের সাথে মেলে। সব স্ক্রিপ্টে একই নন্স থাকতে পারে। প্রথম ধাপ হল সমস্ত স্ক্রিপ্টে এই বৈশিষ্ট্যগুলি যোগ করা যাতে CSP তাদের অনুমতি দেয়।

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

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

স্ক্রিপ্ট লোডিং বিবেচনা

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

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

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

ইনলাইন ইভেন্ট হ্যান্ডলার (যেমন onclick="…" , onerror="…" ) এবং JavaScript URIs ( <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: ইউআরআই

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 ব্লক জাভাস্ক্রিপ্ট: URIs.

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

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

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

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

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

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • প্রান্ত: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4.

উৎস

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

  • strict-dynamic ব্যবহার করার জন্য সাফারির পূর্ববর্তী সংস্করণগুলির জন্য একটি ফলব্যাক হিসাবে https: যোগ করা প্রয়োজন। আপনি যখন এটি করবেন:
    • strict-dynamic সমর্থন করে এমন সমস্ত ব্রাউজার https: ফলব্যাককে উপেক্ষা করে, তাই এটি নীতির শক্তি হ্রাস করবে না।
    • পুরানো ব্রাউজারগুলিতে, বাহ্যিকভাবে প্রাপ্ত স্ক্রিপ্টগুলি শুধুমাত্র লোড হতে পারে যদি সেগুলি একটি HTTPS উত্স থেকে আসে৷ এটি একটি কঠোর সিএসপির চেয়ে কম নিরাপদ, তবে এটি এখনও javascript: URIs।
  • খুব পুরানো ব্রাউজার সংস্করণের সাথে সামঞ্জস্যতা নিশ্চিত করতে (4+ বছর), আপনি একটি ফলব্যাক হিসাবে unsafe-inline যোগ করতে পারেন। একটি CSP ননস বা হ্যাশ উপস্থিত থাকলে সমস্ত সাম্প্রতিক ব্রাউজারগুলি unsafe-inline উপেক্ষা করে।
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

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

আপনার স্থানীয় উন্নয়ন পরিবেশে আপনার CSP কোনো বৈধ স্ক্রিপ্ট ব্লক করে না তা নিশ্চিত করার পরে, আপনি আপনার CSP মঞ্চায়নে, তারপর আপনার উৎপাদন পরিবেশে স্থাপন করতে পারেন:

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

সীমাবদ্ধতা

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

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

বিকাশকারী এবং সুরক্ষা প্রকৌশলীদের কোড পর্যালোচনা এবং সুরক্ষা নিরীক্ষণের সময় এই জাতীয় নিদর্শনগুলিতে বিশেষ মনোযোগ দেওয়া উচিত। আপনি বিষয়বস্তু সুরক্ষা নীতিতে এই মামলাগুলির আরও বিশদ পেতে পারেন: কঠোরতা এবং প্রশমনগুলির মধ্যে একটি সফল জগাখিচুড়ি

আরও পড়া

,

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • এজ: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4।

উৎস

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

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

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

কী শব্দ: একটি ননস হ'ল এলোমেলো সংখ্যা যা কেবলমাত্র একবার আপনি <script> ট্যাগকে বিশ্বস্ত হিসাবে চিহ্নিত করতে ব্যবহার করতে পারেন।

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

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

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

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

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

কঠোর সিএসপি কাঠামো

একটি প্রাথমিক কঠোর সামগ্রী সুরক্ষা নীতি নিম্নলিখিত এইচটিটিপি প্রতিক্রিয়া শিরোনামগুলির একটি ব্যবহার করে:

ননস-ভিত্তিক কঠোর সিএসপি

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

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

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

নিম্নলিখিত বৈশিষ্ট্যগুলি এই "কঠোর" এর মতো একটি সিএসপি তৈরি করে এবং তাই সুরক্ষিত:

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

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

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

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

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

লাইটহাউসটি সতর্ক করে যে কোনও সিএসপি প্রয়োগকারী মোডে পাওয়া যায় না।
যদি আপনার সাইটে কোনও সিএসপি না থাকে তবে বাতিঘর এই সতর্কতাটি দেখায়।

পদক্ষেপ 1: আপনার কোনও নন-বা হ্যাশ-ভিত্তিক সিএসপি দরকার কিনা তা স্থির করুন

দুটি ধরণের কঠোর সিএসপি কীভাবে কাজ করে তা এখানে:

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

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

সার্ভারে রেন্ডার করা এইচটিএমএল পৃষ্ঠাগুলির জন্য একটি ননস-ভিত্তিক সিএসপি ব্যবহার করুন। এই পৃষ্ঠাগুলির জন্য, আপনি প্রতিটি প্রতিক্রিয়ার জন্য একটি নতুন এলোমেলো নম্বর তৈরি করতে পারেন।

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

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

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

পদক্ষেপ 2: একটি কঠোর সিএসপি সেট করুন এবং আপনার স্ক্রিপ্টগুলি প্রস্তুত করুন

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

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

বিকল্প এ: ননস-ভিত্তিক সিএসপি

আপনার অ্যাপ্লিকেশনটিতে নিম্নলিখিত Content-Security-Policy এইচটিটিপি প্রতিক্রিয়া শিরোনাম সেট করুন:

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

সিএসপির জন্য একটি ননস তৈরি করুন

একটি ননস হ'ল একটি এলোমেলো সংখ্যা যা প্রতি পৃষ্ঠায় লোড একবারে ব্যবহৃত হয়। একটি ননস-ভিত্তিক সিএসপি কেবলমাত্র এক্সএসএসকে প্রশমিত করতে পারে যদি আক্রমণকারীরা ননস মানটি অনুমান করতে না পারে। একটি সিএসপি ননস অবশ্যই:

  • একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী এলোমেলো মান (আদর্শভাবে 128+ বিট দৈর্ঘ্য)
  • প্রতিটি প্রতিক্রিয়ার জন্য নতুন উত্পন্ন
  • বেস 64 এনকোডেড

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

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 বৈশিষ্ট্য যুক্ত করুন

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

বিকল্প বি: হ্যাশ-ভিত্তিক সিএসপি প্রতিক্রিয়া শিরোনাম

আপনার অ্যাপ্লিকেশনটিতে নিম্নলিখিত Content-Security-Policy এইচটিটিপি প্রতিক্রিয়া শিরোনাম সেট করুন:

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}'

গতিশীলভাবে টকযুক্ত স্ক্রিপ্টগুলি লোড করুন

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

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

স্ক্রিপ্ট লোডিং বিবেচনা

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

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

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

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

আপনি যদি পূর্ববর্তী পদক্ষেপে সিএসপি সক্ষম করে থাকেন তবে আপনি প্রতিবার সিএসপি একটি বেমানান প্যাটার্ন ব্লক করে কনসোলে সিএসপি লঙ্ঘন দেখতে সক্ষম হবেন।

ক্রোম বিকাশকারী কনসোলে সিএসপি লঙ্ঘন প্রতিবেদন।
অবরুদ্ধ কোডের জন্য কনসোল ত্রুটি।

বেশিরভাগ ক্ষেত্রে, ফিক্সটি সোজা:

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

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

রিফ্যাক্টর javascript: ইউআরআইএস

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

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

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

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

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

পদক্ষেপ 4 (al চ্ছিক): পুরানো ব্রাউজার সংস্করণগুলি সমর্থন করার জন্য ফ্যালব্যাকগুলি যুক্ত করুন

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • এজ: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4।

উৎস

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

  • strict-dynamic ব্যবহারের জন্য https: সাফারির পূর্ববর্তী সংস্করণগুলির জন্য ফ্যালব্যাক হিসাবে। আপনি যখন এটি করবেন:
    • strict-dynamic সমর্থন করে এমন সমস্ত ব্রাউজারগুলি https: ফলব্যাক, সুতরাং এটি নীতিমালার শক্তি হ্রাস করবে না।
    • পুরানো ব্রাউজারগুলিতে, বাহ্যিকভাবে টকযুক্ত স্ক্রিপ্টগুলি কেবল যদি এইচটিটিপিএস উত্স থেকে আসে তবেই লোড করতে পারে। এটি একটি কঠোর সিএসপির চেয়ে কম সুরক্ষিত, তবে এটি এখনও javascript: ইউআরআইএস।
  • খুব পুরানো ব্রাউজার সংস্করণ (4+ বছর) এর সাথে সামঞ্জস্যতা নিশ্চিত করতে, আপনি ফ্যালব্যাক হিসাবে unsafe-inline যুক্ত করতে পারেন। সমস্ত সাম্প্রতিক ব্রাউজারগুলি যদি কোনও সিএসপি ননস বা হ্যাশ উপস্থিত থাকে তবে unsafe-inline উপেক্ষা করে।
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

পদক্ষেপ 5: আপনার সিএসপি স্থাপন করুন

আপনার সিএসপি আপনার স্থানীয় বিকাশের পরিবেশে কোনও বৈধ স্ক্রিপ্টগুলি অবরুদ্ধ করে না তা নিশ্চিত করার পরে, আপনি আপনার সিএসপি মঞ্চে স্থাপন করতে পারেন, তারপরে আপনার উত্পাদন পরিবেশে:

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

সীমাবদ্ধতা

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

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

বিকাশকারী এবং সুরক্ষা প্রকৌশলীদের কোড পর্যালোচনা এবং সুরক্ষা নিরীক্ষণের সময় এই জাতীয় নিদর্শনগুলিতে বিশেষ মনোযোগ দেওয়া উচিত। আপনি বিষয়বস্তু সুরক্ষা নীতিতে এই মামলাগুলির আরও বিশদ পেতে পারেন: কঠোরতা এবং প্রশমনগুলির মধ্যে একটি সফল জগাখিচুড়ি

আরও পড়া

,

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • এজ: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4।

উৎস

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

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

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

কী শব্দ: একটি ননস হ'ল এলোমেলো সংখ্যা যা কেবলমাত্র একবার আপনি <script> ট্যাগকে বিশ্বস্ত হিসাবে চিহ্নিত করতে ব্যবহার করতে পারেন।

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

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

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

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

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

কঠোর সিএসপি কাঠামো

একটি প্রাথমিক কঠোর সামগ্রী সুরক্ষা নীতি নিম্নলিখিত এইচটিটিপি প্রতিক্রিয়া শিরোনামগুলির একটি ব্যবহার করে:

ননস-ভিত্তিক কঠোর সিএসপি

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

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

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

নিম্নলিখিত বৈশিষ্ট্যগুলি এই "কঠোর" এর মতো একটি সিএসপি তৈরি করে এবং তাই সুরক্ষিত:

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

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

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

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

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

লাইটহাউসটি সতর্ক করে যে কোনও সিএসপি প্রয়োগকারী মোডে পাওয়া যায় না।
যদি আপনার সাইটে কোনও সিএসপি না থাকে তবে বাতিঘর এই সতর্কতাটি দেখায়।

পদক্ষেপ 1: আপনার কোনও নন-বা হ্যাশ-ভিত্তিক সিএসপি দরকার কিনা তা স্থির করুন

দুটি ধরণের কঠোর সিএসপি কীভাবে কাজ করে তা এখানে:

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

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

সার্ভারে রেন্ডার করা এইচটিএমএল পৃষ্ঠাগুলির জন্য একটি ননস-ভিত্তিক সিএসপি ব্যবহার করুন। এই পৃষ্ঠাগুলির জন্য, আপনি প্রতিটি প্রতিক্রিয়ার জন্য একটি নতুন এলোমেলো নম্বর তৈরি করতে পারেন।

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

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

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

পদক্ষেপ 2: একটি কঠোর সিএসপি সেট করুন এবং আপনার স্ক্রিপ্টগুলি প্রস্তুত করুন

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

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

বিকল্প এ: ননস-ভিত্তিক সিএসপি

আপনার অ্যাপ্লিকেশনটিতে নিম্নলিখিত Content-Security-Policy এইচটিটিপি প্রতিক্রিয়া শিরোনাম সেট করুন:

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

সিএসপির জন্য একটি ননস তৈরি করুন

একটি ননস হ'ল একটি এলোমেলো সংখ্যা যা প্রতি পৃষ্ঠায় লোড একবারে ব্যবহৃত হয়। একটি ননস-ভিত্তিক সিএসপি কেবলমাত্র এক্সএসএসকে প্রশমিত করতে পারে যদি আক্রমণকারীরা ননস মানটি অনুমান করতে না পারে। একটি সিএসপি ননস অবশ্যই:

  • একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী এলোমেলো মান (আদর্শভাবে 128+ বিট দৈর্ঘ্য)
  • প্রতিটি প্রতিক্রিয়ার জন্য নতুন উত্পন্ন
  • বেস 64 এনকোডেড

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

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 বৈশিষ্ট্য যুক্ত করুন

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

বিকল্প বি: হ্যাশ-ভিত্তিক সিএসপি প্রতিক্রিয়া শিরোনাম

আপনার অ্যাপ্লিকেশনটিতে নিম্নলিখিত Content-Security-Policy এইচটিটিপি প্রতিক্রিয়া শিরোনাম সেট করুন:

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}'

গতিশীলভাবে টকযুক্ত স্ক্রিপ্টগুলি লোড করুন

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

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

স্ক্রিপ্ট লোডিং বিবেচনা

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

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

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

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

আপনি যদি পূর্ববর্তী পদক্ষেপে সিএসপি সক্ষম করে থাকেন তবে আপনি প্রতিবার সিএসপি একটি বেমানান প্যাটার্ন ব্লক করে কনসোলে সিএসপি লঙ্ঘন দেখতে সক্ষম হবেন।

ক্রোম বিকাশকারী কনসোলে সিএসপি লঙ্ঘন প্রতিবেদন।
অবরুদ্ধ কোডের জন্য কনসোল ত্রুটি।

বেশিরভাগ ক্ষেত্রে, ফিক্সটি সোজা:

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

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

রিফ্যাক্টর javascript: ইউআরআইএস

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

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

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

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

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

পদক্ষেপ 4 (al চ্ছিক): পুরানো ব্রাউজার সংস্করণগুলি সমর্থন করার জন্য ফ্যালব্যাকগুলি যুক্ত করুন

ব্রাউজার সমর্থন

  • ক্রোম: 52।
  • এজ: 79।
  • ফায়ারফক্স: 52।
  • সাফারি: 15.4।

উৎস

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

  • strict-dynamic ব্যবহারের জন্য https: সাফারির পূর্ববর্তী সংস্করণগুলির জন্য ফ্যালব্যাক হিসাবে। আপনি যখন এটি করবেন:
    • strict-dynamic সমর্থন করে এমন সমস্ত ব্রাউজারগুলি https: ফলব্যাক, সুতরাং এটি নীতিমালার শক্তি হ্রাস করবে না।
    • পুরানো ব্রাউজারগুলিতে, বাহ্যিকভাবে টকযুক্ত স্ক্রিপ্টগুলি কেবল যদি এইচটিটিপিএস উত্স থেকে আসে তবেই লোড করতে পারে। এটি কঠোর সিএসপির চেয়ে কম সুরক্ষিত, তবে এটি এখনও কিছু সাধারণ এক্সএসএস কারণকে javascript: ইউআরআইএস।
  • খুব পুরানো ব্রাউজার সংস্করণ (4+ বছর) এর সাথে সামঞ্জস্যতা নিশ্চিত করতে, আপনি ফ্যালব্যাক হিসাবে unsafe-inline যুক্ত করতে পারেন। সমস্ত সাম্প্রতিক ব্রাউজারগুলি যদি কোনও সিএসপি ননস বা হ্যাশ উপস্থিত থাকে তবে unsafe-inline উপেক্ষা করে।
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

পদক্ষেপ 5: আপনার সিএসপি স্থাপন করুন

আপনার সিএসপি আপনার স্থানীয় বিকাশের পরিবেশে কোনও বৈধ স্ক্রিপ্টগুলি অবরুদ্ধ করে না তা নিশ্চিত করার পরে, আপনি আপনার সিএসপি মঞ্চে স্থাপন করতে পারেন, তারপরে আপনার উত্পাদন পরিবেশে:

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

সীমাবদ্ধতা

একটি কঠোর সিএসপি সাধারণত সুরক্ষার একটি শক্তিশালী যুক্ত স্তর সরবরাহ করে যা এক্সএসএসকে প্রশমিত করতে সহায়তা করে। In most cases, CSP reduces the attack surface significantly, by rejecting dangerous patterns like javascript: URIs. However, based on the type of CSP you're using (nonces, hashes, with or without 'strict-dynamic' ), there are cases where CSP doesn't protect your app as well:

  • If you nonce a script, but there's an injection directly into the body or the src parameter of that <script> element.
  • If there are injections into the locations of dynamically created scripts ( document.createElement('script') ), including into any library functions that create script DOM nodes based on the values of their arguments. This includes some common APIs such as jQuery's .html() , as well as .get() and .post() in jQuery < 3.0.
  • If there are template injections in old AngularJS applications. An attacker that can inject into an AngularJS template can use it to execute arbitrary JavaScript .
  • If the policy contains 'unsafe-eval' , injections into eval() , setTimeout() , and a few other rarely used APIs.

Developers and security engineers should pay particular attention to such patterns during code reviews and security audits. You can find more details on these cases in Content Security Policy: A Successful Mess Between Hardening and Mitigation .

আরও পড়া