XSS আক্রমণের বিরুদ্ধে সিএসপি কার্যকর তা নিশ্চিত করুন

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

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

একটি নন-বাইপাসযোগ্য CSP-এর জন্য প্রয়োজনীয় অনুশীলন

আপনার CSP বাইপাস করা যাবে না তা নিশ্চিত করতে নিম্নলিখিত অনুশীলনগুলি প্রয়োগ করুন। যদি CSP বাইপাস করা যায়, বাতিঘর একটি উচ্চ তীব্রতা সতর্কতা নির্গত করবে।

CSP টার্গেট XSS

XSS টার্গেট করার জন্য, একটি CSP-এ script-src , object-src , এবং base-uri নির্দেশাবলী অন্তর্ভুক্ত করা উচিত। সিএসপি সিনট্যাক্স ত্রুটি মুক্ত হতে হবে.

script-src এবং object-src যথাক্রমে অনিরাপদ স্ক্রিপ্ট এবং অনিরাপদ প্লাগইন থেকে একটি পৃষ্ঠা সুরক্ষিত করে। বিকল্পভাবে, script-src এবং object-src সহ অনেক নির্দেশের জায়গায় একটি বিস্তৃত নীতি কনফিগার করতে default-src ব্যবহার করা যেতে পারে।

base-uri অননুমোদিত <base> ট্যাগের ইনজেকশনকে বাধা দেয় যা আক্রমণকারী-নিয়ন্ত্রিত ডোমেনে সমস্ত আপেক্ষিক URL (যেমন স্ক্রিপ্ট) পুনঃনির্দেশ করতে ব্যবহার করা যেতে পারে।

CSP ননসেস বা হ্যাশ ব্যবহার করে অনুমোদিত তালিকা বাইপাস এড়াতে

একটি CSP যেটি script-src এর জন্য একটি অনুমোদিত তালিকা কনফিগার করে তা এই ধারণার উপর নির্ভর করে যে একটি বিশ্বস্ত ডোমেন থেকে আসা সমস্ত প্রতিক্রিয়া নিরাপদ, এবং স্ক্রিপ্ট হিসাবে কার্যকর করা যেতে পারে। যাইহোক, এই অনুমান আধুনিক অ্যাপ্লিকেশনের জন্য ধরে না; কিছু সাধারণ, সৌম্য প্যাটার্ন যেমন JSONP ইন্টারফেস প্রকাশ করা এবং AngularJS লাইব্রেরির কপি হোস্ট করা আক্রমণকারীদের CSP-এর সীমাবদ্ধতা থেকে বাঁচতে দেয়।

অনুশীলনে, যদিও এটি অ্যাপ্লিকেশন লেখকদের কাছে স্পষ্ট নাও হতে পারে, বেশিরভাগ script-src অনুমোদিত তালিকাগুলিকে একটি XSS বাগ সহ আক্রমণকারী দ্বারা বাধা দেওয়া যেতে পারে এবং স্ক্রিপ্ট ইনজেকশনের বিরুদ্ধে সামান্য সুরক্ষা প্রদান করে। বিপরীতে, ননস-ভিত্তিক এবং হ্যাশ-ভিত্তিক পন্থাগুলি এই সমস্যাগুলি ভোগ করে না এবং এটি আরও নিরাপদ নীতি গ্রহণ এবং বজায় রাখা সহজ করে তোলে।

উদাহরণস্বরূপ, আক্রমণকারী নিয়ন্ত্রিত স্ক্রিপ্ট ইনজেক্ট করার জন্য এই কোডটি একটি বিশ্বস্ত ডোমেনে হোস্ট করা একটি JSONP এন্ডপয়েন্ট ব্যবহার করে:

CSP:

script-src https://trusted.example.com

HTML:

<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>

বাইপাস হওয়া এড়াতে, একটি CSP-এর উচিত পৃথকভাবে ননসেস বা হ্যাশ ব্যবহার করে স্ক্রিপ্টের অনুমতি দেওয়া এবং অনুমোদিত তালিকার পরিবর্তে 'স্ট্রিক-ডাইনামিক' ব্যবহার করা।

একটি নিরাপদ CSP এর জন্য অতিরিক্ত সুপারিশ

অতিরিক্ত নিরাপত্তা এবং সামঞ্জস্যের জন্য নিম্নলিখিত অনুশীলনগুলি প্রয়োগ করুন। যদি CSP সুপারিশগুলির একটি অনুসরণ না করে, তাহলে Lighthouse একটি মাঝারি তীব্রতা সতর্কতা নির্গত করবে।

CSP রিপোর্টিং কনফিগার করুন

একটি রিপোর্টিং গন্তব্য কনফিগার করা কোনো বিচ্ছেদের জন্য নিরীক্ষণ করতে সাহায্য করবে। আপনি report-uri বা report-to নির্দেশাবলী ব্যবহার করে রিপোর্টিং গন্তব্য সেট করতে পারেন। report-to বর্তমানে সমস্ত আধুনিক ব্রাউজার দ্বারা সমর্থিত নয় তাই এটি উভয় বা শুধুমাত্র report-uri ব্যবহার করার পরামর্শ দেওয়া হচ্ছে।

কোনো বিষয়বস্তু CSP লঙ্ঘন করলে, ব্রাউজার কনফিগার করা গন্তব্যে একটি প্রতিবেদন পাঠাবে। নিশ্চিত করুন যে আপনার এই গন্তব্যে এই প্রতিবেদনগুলি পরিচালনা করার জন্য একটি অ্যাপ্লিকেশন কনফিগার করা আছে৷

একটি HTTP হেডারে CSP সংজ্ঞায়িত করুন

একটি মেটা ট্যাগে একটি CSP সংজ্ঞায়িত করা যেতে পারে এইরকম:

<meta http-equiv="Content-Security-Policy" content="script-src 'none'">

যাইহোক, আপনি যদি পারেন তবে আপনাকে একটি HTTP প্রতিক্রিয়া শিরোনামে একটি CSP সংজ্ঞায়িত করা উচিত। মেটা ট্যাগের আগে একটি ইনজেকশন সিএসপিকে বাইপাস করবে। উপরন্তু, frame-ancestors , sandbox এবং রিপোর্টিং মেটা ট্যাগ CSP-তে সমর্থিত নয়।

নিশ্চিত করুন যে CSP পিছনের দিকে সামঞ্জস্যপূর্ণ

সমস্ত ব্রাউজার CSP ননসেস/হ্যাশ সমর্থন করে না, তাই অ-সম্মতিশীল ব্রাউজারগুলির জন্য একটি ফলব্যাক হিসাবে unsafe-inline যোগ করার পরামর্শ দেওয়া হয়। যদি ব্রাউজার ননসেস/হ্যাশ সমর্থন করে, তবে unsafe-inline উপেক্ষা করা হবে।

একইভাবে, strict-dynamic সমস্ত ব্রাউজার দ্বারা সমর্থিত নয়। অনুগত নয় এমন ব্রাউজারগুলির জন্য একটি ফলব্যাক হিসাবে একটি অনুমোদিত তালিকা সেট করার পরামর্শ দেওয়া হয়। strict-dynamic সমর্থন করে এমন ব্রাউজারগুলিতে অনুমোদিত তালিকা উপেক্ষা করা হবে।

কিভাবে একটি কঠোর CSP বিকাশ করতে হয়

নীচে একটি ননস-ভিত্তিক নীতি সহ একটি কঠোর CSP ব্যবহার করার একটি উদাহরণ।

CSP:

script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;

HTML:

<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>

random123 যেকোন বেস64 স্ট্রিং জেনারেটেড সার্ভার-সাইড হবে প্রতিবার পেজ লোড হওয়ার সময়। unsafe-inline এবং https: আধুনিক ব্রাউজারে উপেক্ষা করা হয় কারণ ননস এবং strict-dynamic । একটি কঠোর CSP গ্রহণ সম্পর্কে আরও তথ্যের জন্য, কঠোর CSP নির্দেশিকা দেখুন।

আপনি Lighthouse এবং CSP ইভালুয়েটর ব্যবহার করে সম্ভাব্য বাইপাসের জন্য একটি CSP পরীক্ষা করতে পারেন। আপনি যদি বিদ্যমান পৃষ্ঠাগুলি ভাঙ্গার ঝুঁকি ছাড়াই একটি নতুন CSP পরীক্ষা করতে চান, তাহলে শুধুমাত্র শিরোনামের নাম হিসাবে Content-Security-Policy-Report-Only ব্যবহার করে CSP-কে শুধুমাত্র রিপোর্ট মোডে সংজ্ঞায়িত করুন। এটি report-to এবং report-uri সাথে আপনার কনফিগার করা যেকোন রিপোর্টিং গন্তব্যে CSP লঙ্ঘন পাঠাবে, কিন্তু এটি আসলে CSP প্রয়োগ করবে না।