XSS প্রতিরক্ষা — output encoding আর Content Security Policy

১ · XSS কী: ডেটা যখন পাতার কোড হয়ে যায়

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

XSS (Cross-Site Scripting) হলো সেই ত্রুটি, যেখানে আক্রমণকারীর দেওয়া ডেটা ভুক্তভোগীর browser-এ আপনার সাইটের script হিসেবে চলে। লক্ষ করুন, আক্রমণকারীর script চলছে আপনার origin-এর ভেতরে। তাই browser-এর same-origin policy (পর্ব ৩৬) তাকে আটকায় না। Browser ভাবে, এটি আপনার সাইটেরই কোড।

ক্ষতি কতটা হতে পারে

একবার script চললে সে ব্যবহারকারীর নামে যা খুশি করার চেষ্টা করতে পারে, কারণ browser প্রতিটি request-এ তাঁর session নিয়েই যায়:

• ব্যবহারকারীর নামে কাজ: ঠিকানা বদল, অর্ডার, বার্তা পাঠানো, এমনকি admin হলে admin-এর কাজ।
• পাতার তথ্য পড়া: পাতায় যা দেখা যাচ্ছে তার সবই, যেমন নাম, ফোন, লেনদেন।
• ভুয়া ফর্ম দেখানো: আসল ঠিকানায় থেকেই ভুয়া login ফর্ম, তাই ঠিকানা দেখে ধরা যায় না।
• নিজে থেকে ছড়ানো: একটি account থেকে অন্য account-এ।

২ · তিন ধরন: ডেটা কোন পথে পাতায় আসে

পার্থক্যটি হামলার কৌশলে নয়, ডেটার পথে। পথ জানলে বোঝা যায় ত্রুটি খুঁজতে হবে কোথায়।

Stored ধরনটি সাধারণত সবচেয়ে বিপজ্জনক, কারণ ভুক্তভোগীকে কোনো link খুলতে হয় না। একবার জমলে সেটি বারবার চলে।

৩ · মূল কারণ: context না বুঝে ডেটা বসানো

সব ধরনের XSS-এর মূলে একই কথা: অবিশ্বস্ত ডেটা এমন জায়গায় বসেছে, যেখানে browser তাকে কোড হিসেবে পড়তে পারে, আর বসানোর আগে সেই জায়গার নিয়মে encode করা হয়নি। এই “জায়গা”-কেই বলে encoding context.

অনিরাপদ নকশাটি দেখতে এমন। এখানে <user-input> একটি নিরীহ চিহ্ন, আসল কোনো ডেটা নয়:

// অনিরাপদ নকশা: ডেটা জুড়ে HTML বানানো হচ্ছে
card.innerHTML = "<p>" + "<user-input>" + "</p>";

// নিরাপদ নকশা: ডেটা শুধু লেখা হিসেবে বসছে
const p = document.createElement("p");
p.textContent = "<user-input>";
card.append(p);

প্রথম লাইনে কোড আর ডেটা একই string-এ মিশে গেছে, তাই ডেটা পাতার কাঠামো বদলে দিতে পারে। অংশ ৬-এ এর পার্থক্য চালিয়ে দেখবেন। পর্ব ৩৯ · Injection প্রতিরক্ষা-র কথাও মনে পড়তে পারে: SQL-এ parameterized query যেমন কাঠামো আর ডেটা আলাদা রাখে, এখানেও একই নীতি।

ছবিতে একটি জিনিস খেয়াল করুন: Database-এ মূল ডেটা অক্ষত থাকে। Encoding হয় দেখানোর ঠিক আগে। কারণ জমা করার সময় আপনি জানেন না ডেটাটি পরে HTML-এ যাবে, PDF-এ, SMS-এ না mobile app-এ। নিচের ডায়াগ্রামে একটি মন্তব্যের পুরো যাত্রা দেখুন।

<b>hello</b> & "welcome"

length = 24      (সীমা 500, ঠিক আছে)
type   = text    (ঠিক আছে)
মান একই আছে, কিছু কাটা হয়নি

id   text
17   <b>hello</b> & "welcome"

ছাঁচ:   <p>{{ comment.text }}</p>
ফল:    <p>&lt;b&gt;hello&lt;/b&gt; &amp; &quot;welcome&quot;</p>

p
└─ text: <b>hello</b> & "welcome"
b নামের কোনো element তৈরি হয়নি

<b>hello</b> & "welcome"
হুবহু যা লেখা হয়েছিল, মোটা হরফ নেই

৪ · প্রতিটি context-এর নিজের নিয়ম

Output encoding মানে বিশেষ অক্ষরকে নিরীহ রূপে লেখা। HTML-এ এই রূপকে বলে HTML entity. এটি Base64-এর মতো কোনো গোপন করার কাজ নয়; উদ্দেশ্য শুধু browser-কে বলা, “এটি লেখা”। OWASP-এর Cross Site Scripting Prevention Cheat Sheet-এ HTML লেখার জন্য পাঁচটি অক্ষরের নিয়ম আছে:

কিন্তু একই encoding সব জায়গায় চলে না। পোস্ট অফিসে দেশের ভেতরের ঠিকানা আর বিদেশের ঠিকানার নিয়ম আলাদা; ডেটার ক্ষেত্রেও জায়গা বদলালে নিয়ম বদলায়।

নিচের খেলনা encoder একই নিরীহ লেখাকে তিন জায়গার নিয়মে encode করে। কোনো request যাচ্ছে না, শুধু string বদলাচ্ছে:

// খেলনা encoder: বাস্তবে framework-এর পরীক্ষিত encoder ব্যবহার করুন
const sample = `<b>hello</b> & "welcome" 'friend'`;

const MAP = { "&": "&amp;", "<": "&lt;", ">": "&gt;",
              '"': "&quot;", "'": "&#x27;" };
const encodeHtml = s => s.replace(/[&<>"']/g, c => MAP[c]);

function encodeFor(context, value) {
  if (context === "html-text") return encodeHtml(value);
  if (context === "attribute") return encodeHtml(value);
  if (context === "url-param") return encodeURIComponent(value);
  if (context === "href-attr") return encodeHtml(encodeURIComponent(value));
  throw new Error("no safe encoder for context: " + context);
}

const t = encodeFor("html-text", sample);
console.log("html-text: <p>" + t + "</p>");
console.log('attribute: <input value="' + encodeFor("attribute", sample) + '">');
console.log("url-param: /search?q=" + encodeFor("url-param", sample));
console.log('href-attr: <a href="/search?q=' + encodeFor("href-attr", sample) + '">');
try {
  encodeFor("script-block", sample);
} catch (e) {
  console.log("REFUSED: " + e.message);
}

আপনার ভাষায় তৈরি encoder

নিজে encoder লেখার দরকার নেই। ওপরের কোড শুধু বোঝার জন্য। কয়েকটি পরিচিত উদাহরণ, হুবহু নাম ব্যবহারের আগে নিজের version-এর নথি মিলিয়ে নিন:

৫ · Template engine: নিরাপদ পথটিই সহজ পথ

প্রতিটি জায়গায় হাতে encode করতে গেলে একদিন ভুল হবেই। তাই আধুনিক template engine আর framework auto-escaping করে: {{ name }} লিখলে encoding নিজে থেকেই হয়। React-এর JSX, Vue-র {{ }}, Django-র template আর Laravel Blade-এর {{ }}, সবগুলোতেই এটি স্বাভাবিক আচরণ।

কিন্তু প্রতিটি ব্যবস্থায় একটি “জরুরি দরজা” আছে, যা encoding বন্ধ করে দেয়। XSS-এর বড় অংশ এই দরজাগুলো দিয়েই আসে। আপনার code review-তে এই শব্দগুলো দেখলেই থামতে হবে:

৬ · Browser-এ: innerHTML, textContent, sanitizer আর link

DOM-based XSS-এর ক্ষেত্রে server কিছু করার সুযোগই পায় না, সিদ্ধান্ত নেয় পাতার JavaScript. কিছু API string-কে কোড হিসেবে পড়তে পারে। এগুলোকে বলে DOM sink. সবচেয়ে পরিচিত হলো innerHTML. আর তার নিরাপদ বিকল্প textContent, যা string-কে শুধু লেখা হিসেবে বসায়।

পার্থক্যটি একটি খেলনা DOM-এ দেখুন। এটি আসল browser parser নয়। শুধু <b> tag চেনে, আর কোনো কিছু চালায় না:

// খেলনা DOM: real browser parser নয়, শুধু ধারণার জন্য
function toyParse(html) {
  const nodes = [];
  let rest = html;
  while (rest.length > 0) {
    const m = rest.match(/^<b>(.*?)<\/b>/);
    if (m) {
      nodes.push({ type: "element", tag: "b", text: m[1] });
      rest = rest.slice(m[0].length);
      continue;
    }
    const next = rest.indexOf("<b>", 1);
    const end = next === -1 ? rest.length : next;
    nodes.push({ type: "text", text: rest.slice(0, end) });
    rest = rest.slice(end);
  }
  return nodes;
}

const toyEl = {
  children: [],
  set innerHTML(v) { this.children = toyParse(v); },
  set textContent(v) { this.children = [{ type: "text", text: v }]; },
};

function report(label) {
  const elements = toyEl.children.filter(n => n.type === "element").length;
  console.log(label, "nodes=" + toyEl.children.length, "elements=" + elements);
  for (const n of toyEl.children) console.log("  ", n.type, JSON.stringify(n.text));
}

const comment = `<b>hello</b> & "welcome"`;
toyEl.innerHTML = comment;   report("innerHTML-like  :");
toyEl.textContent = comment; report("textContent-like:");

OWASP-এর পরামর্শ অনুযায়ী লেখা বসাতে textContent, createTextNode, insertAdjacentText ব্যবহার করুন, আর innerHTML, outerHTML, insertAdjacentHTML, document.write এড়িয়ে চলুন। String থেকে কোড চালানোর API, যেমন eval, encoding দিয়েও নিরাপদ হয় না। এগুলোতে অবিশ্বস্ত ডেটা যাবেই না। DOM-এর ভিত্তি ঝালিয়ে নিতে পারেন JavaScript কোর্সের DOM পর্বে।

ব্যবহারকারী যদি সত্যিই সাজানো লেখা দিতে চান

ব্লগ, পণ্যের বিবরণ বা email-এর editor-এ rich text লাগে। সেখানে encoding করলে মোটা হরফও লেখা হয়ে যাবে। তখন লাগে HTML sanitization: অনুমোদিত tag আর attribute রেখে বাকিটা সরানো। কাজটি শুনতে সহজ, আসলে খুব কঠিন, কারণ browser HTML পড়ে অনেক অপ্রত্যাশিতভাবে। তাই regex দিয়ে নিজে বানাবেন না। DOMPurify-র মতো নিয়মিত হালনাগাদ হওয়া library একটি পরিচিত উদাহরণ।

// উদাহরণ: DOMPurify-র মতো library, version-ভেদে option আলাদা হতে পারে
const clean = DOMPurify.sanitize("<user-input>", {
  ALLOWED_TAGS: ["b", "i", "p", "ul", "ol", "li", "a"],
  ALLOWED_ATTR: ["href"],
});
box.innerHTML = clean;   // sanitize-এর পরে আর কিছু বদলানো যাবে না

• Allowlist ছোট রাখুন: যা লাগে শুধু তা-ই।
• Sanitize করার পরে বদলাবেন না: OWASP সতর্ক করে, পরে string পাল্টালে আগের নিশ্চয়তা নষ্ট হতে পারে।
• Library হালনাগাদ রাখুন: Browser বদলায়, তাই sanitizer-এর ত্রুটিও সময়ে সময়ে পাওয়া যায়।
• Markdown হলে আরও সহজ: সাধারণত HTML পুরো বন্ধ রেখে শুধু Markdown-এর চিহ্ন অনুমোদন করা নিরাপদ।
• Browser-এর নিজস্ব পথ: MDN অনুযায়ী HTML Sanitizer API-র setHTML() এখনো সব প্রধান browser-এ নেই, তাই আপাতত fallback রাখতে হয়।

Link-এর জন্য URL scheme allowlist

ধরুন প্রোফাইলে ব্যবহারকারী নিজের website-এর ঠিকানা দেন। আপনি সেটি encode করে href-এ বসালেন। লেখাটি নিরাপদ হলো, কিন্তু link-এর অর্থ নিরাপদ কি? Attribute encoding URL-এর URL scheme যাচাই করে না। কিছু scheme ক্লিক করলে সাইট না খুলে পাতার ভেতরেই কিছু চালাতে পারে। তাই এখানে encoding-এর পাশাপাশি allowlist লাগে: https: আর mailto: ঠিক আছে, বাকি সব বন্ধ।

Denylist দিয়ে “খারাপ” scheme আটকানোর চেষ্টা করবেন না; তালিকা কখনো পুরো হয় না। হাতে string মেলানোর বদলে আসল URL parser ব্যবহার করুন, যাতে browser যেভাবে পড়বে আপনিও সেভাবে পড়েন। নিচের কোডে blocked-scheme: একটি বানানো, অস্তিত্বহীন scheme:

// খেলনা link তালিকা: কোনো URL খোলা হচ্ছে না, শুধু parse হচ্ছে
const ALLOWED = new Set(["https:", "mailto:"]);
const BASE = "https://shop.example.com/";

function safeHref(raw) {
  let url;
  try {
    url = new URL(raw, BASE);
  } catch {
    return { ok: false, why: "cannot parse" };
  }
  if (!ALLOWED.has(url.protocol)) {
    return { ok: false, why: "scheme " + url.protocol + " not allowed" };
  }
  return { ok: true, href: url.href };
}

const links = [
  "https://example.com/docs",
  "/profile/7",
  "mailto:help@example.com",
  "http://example.com/old",
  "blocked-scheme:do-something",
  "https://",
];

for (const raw of links) {
  const r = safeHref(raw);
  console.log(r.ok ? "ALLOW" : "BLOCK", raw, "=>", r.ok ? r.href : r.why);
}

৭ · Content Security Policy: ভুল হলেও দ্বিতীয় দেয়াল

ধরা যাক সবকিছু ঠিক করেছেন, তবু লাখ লাইনের কোডে একটি ফাঁক থাকতেই পারে। CSP সেই দিনের জন্য। এটি server-এর পাঠানো একটি header, যা browser-কে বলে: “এই পাতায় কোন script চলবে।” তালিকার বাইরের script browser নিজেই চালাবে না।

যে policy-টি আজ সুপারিশ করা হয়

OWASP-এর CSP Cheat Sheet আর web.dev-এর “strict CSP” নির্দেশিকা nonce-ভিত্তিক এই ধরনের policy দিয়ে শুরু করতে বলে:

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

এবার একটি পাতা লোড হওয়ার সময় nonce কীভাবে কাজ করে দেখুন। সব মান বানানো, example-nonce-Q1 কোনো আসল nonce নয়।

GET /product/7 HTTP/1.1
Host: shop.example.com

nonce = base64(CSPRNG থেকে 16 byte)
      = example-nonce-Q1   (বানানো মান)

Content-Security-Policy:
  script-src 'nonce-example-nonce-Q1' 'strict-dynamic';
  object-src 'none'; base-uri 'none'

<script nonce="example-nonce-Q1" src="/app.js"></script>

script     nonce              সিদ্ধান্ত
/app.js    example-nonce-Q1   চলবে

script     বিশ্বাসের উৎস         সিদ্ধান্ত
/app.js    nonce মিলেছে          চলেছে
/chart.js  app.js লোড করেছে      চলবে

script                nonce    সিদ্ধান্ত
inline, ধরুন কোনো     নেই      বন্ধ
ফাঁক দিয়ে ঢুকেছে
report পাঠানো হলো: script-src লঙ্ঘন

আগের nonce  example-nonce-Q1   আর কোনো কাজের নয়
নতুন nonce  example-nonce-Z9   (বানানো মান)

Nonce-এর হিসাব

১৬ byte = ১৬ × ৮ = ১২৮ bit. Base64-এ প্রতি ৩ byte-এ ৪ অক্ষর, তাই ১৬ byte-এ ⌈১৬/৩⌉ × ৪ = ২৪ অক্ষর (শেষে দুটি = সহ)। নিচের কোড আপনার server-এর জন্য একটি উদাহরণ:

import base64, secrets

nonce = base64.b64encode(secrets.token_bytes(16)).decode()
headers["Content-Security-Policy"] = (
    f"script-src 'nonce-{nonce}' 'strict-dynamic'; "
    "object-src 'none'; base-uri 'none'"
)

নিজের policy পরীক্ষা করুন

নিচের খেলনা evaluator একটি policy পড়ে সাধারণ দুর্বলতা জানায়। এটি শেখার জন্য, বাস্তবে Google-এর CSP Evaluator-এর মতো সরঞ্জামও দেখতে পারেন:

// খেলনা evaluator: browser-এর পুরো নিয়ম নয়, শুধু ধারণার জন্য
function parse(header) {
  const map = {};
  for (const part of header.split(";")) {
    const [name, ...values] = part.trim().split(/\s+/);
    if (name) map[name] = values;
  }
  return map;
}

function evaluate(header) {
  const p = parse(header);
  const s = p["script-src"] || p["default-src"];
  if (!s) return ["FAIL no script-src or default-src"];
  const out = [];
  const nonce = s.some(v => v.startsWith("'nonce-") || v.startsWith("'sha256-"));
  if (s.includes("'unsafe-inline'") && !nonce) out.push("FAIL unsafe-inline with no nonce");
  if (s.includes("'unsafe-eval'")) out.push("WARN unsafe-eval");
  if (s.includes("*") && !nonce) out.push("FAIL wildcard source");
  if (!nonce) out.push("WARN allowlist only, no nonce or hash");
  if (!p["object-src"] && !p["default-src"]) out.push("WARN no object-src");
  if (!p["base-uri"]) out.push("WARN no base-uri");
  return out.length ? out : ["PASS"];
}

const policies = {
  A: "img-src 'self'",
  B: "default-src 'self'",
  C: "script-src 'self' 'unsafe-inline' *; object-src 'none'",
  D: "script-src 'nonce-example1' 'strict-dynamic'; object-src 'none'; base-uri 'none'",
};
for (const [k, v] of Object.entries(policies)) console.log(k, evaluate(v).join(" | "));

CSP যা থামায় না

• ত্রুটিটি সারায় না: OWASP-এর ভাষায় CSP প্রতিরক্ষার বাড়তি স্তর, প্রধান প্রতিরক্ষা নয়। Encoding-এর ভুল থেকেই যায়।
• Script ছাড়া HTML injection: ভুয়া লেখা বা বিভ্রান্তিকর link পাতায় ঢুকলে script-এর নিয়ম তা আটকায় না।
• DOM XSS-এর একটি অংশ: বিশ্বস্ত script নিজেই অনিরাপদ sink-এ ডেটা দিলে strict CSP সব ক্ষেত্রে থামাতে পারে না।
• অন্য শ্রেণির ত্রুটি: SQL injection, broken access control, CSRF, business logic ভুল।
• বিশ্বস্ত script নিজেই বদলে গেলে: nonce দিয়ে দেওয়া third-party script আপস হলে সেটিও চলবে। এর জন্য আলাদা করে ভাবতে হয় Subresource Integrity আর vendor ঝুঁকি নিয়ে।

৮ · Report-only rollout: কিছু না ভেঙে চালু করা

পুরোনো সাইটে হঠাৎ কড়া CSP দিলে চেকআউট পাতা, chart, বিজ্ঞাপন সব বন্ধ হতে পারে। তাই আছে CSP Report-Only: Content-Security-Policy-Report-Only header কিছুই আটকায় না, শুধু জানায় কী আটকাত। মহড়ার মতো: দরজা খোলা, কিন্তু খাতায় লেখা হচ্ছে কে কে আটকে যেত। লক্ষ রাখুন, <meta> tag-এ report-only চলে না, এটি HTTP header হিসেবেই পাঠাতে হয়।

Reporting-Endpoints: csp-endpoint="https://shop.example.com/csp-reports"
Content-Security-Policy-Report-Only:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none'; base-uri 'none';
  report-to csp-endpoint

পুরোনো browser-এর জন্য অনেকে report-uri-ও সাথে রাখেন। নিচে কাল্পনিক বাজারের ছয় সপ্তাহের rollout দেখুন। সংখ্যাগুলো বানানো, শুধু পদ্ধতি বোঝার জন্য।

1send Report-Only header2add nonce to own scripts3load vendors via app.js4filter extension noise5switch to enforcing header6review new reports weekly

Report-এর ভেতরে থাকে কোন পাতা, কোন directive, কোন উৎস। নিচে একটি নমুনা, মানগুলো বানানো, আর ক্ষেত্রের নাম ব্যবহৃত পদ্ধতি অনুযায়ী (report-uri বা report-to) আলাদা হতে পারে:

{
  "document-uri": "https://shop.example.com/product/7",
  "effective-directive": "script-src-elem",
  "blocked-uri": "https://cdn.example.net/widget.js",
  "disposition": "report"
}

Report endpoint নিজেও ইন্টারনেটের দিকে খোলা। তাই এতে rate limit দিন, আর report-এর লেখা dashboard-এ encode করে দেখান। Report-ও অবিশ্বস্ত ডেটা।

৯ · ক্ষতি সীমিত করা, নিজের app পরীক্ষা আর সাড়া

Session cookie-তে HttpOnly দিলে পাতার JavaScript সেটি পড়তে পারে না। ফলে XSS হলেও session ID চুরি করে অন্য যন্ত্র থেকে ব্যবহারের পথটি বন্ধ হয়। বিস্তারিত আছে পর্ব ১৭ · Session আর token-এ।

Set-Cookie: __Host-sid=example-token; Path=/; Secure; HttpOnly; SameSite=Lax

কিন্তু সীমাটি স্পষ্ট করে বুঝুন। HttpOnly cookie-টি পড়া আটকায়, ব্যবহার নয়। পাতার ভেতরে চলা script request পাঠালে browser নিজেই cookie জুড়ে দেয়। তাই ব্যবহারকারী পাতা খোলা রাখা পর্যন্ত script তাঁর নামে কাজ করতে পারে। সংবেদনশীল কাজে, যেমন টাকা পাঠানো বা password বদলে, আবার পরিচয় যাচাই এই ফাঁক অনেকটা কমায়। Token localStorage-এ রাখলে এই সুরক্ষাটুকুও থাকে না, কারণ script সেটি পড়তে পারে।

WAF নিয়ে আরও জানতে দেখুন CDN, WAF আর edge. পুরোনো X-XSS-Protection header-এর ওপরও ভরসা করবেন না; আধুনিক browser-এ সেই ফিল্টার আর নেই।

নিজের app পরীক্ষা

এখানে “নিজের app” কথাটি খুব গুরুত্বপূর্ণ। পরীক্ষা করুন শুধু নিজের development পরিবেশে, বা পর্ব ৬-এ বলা লিখিত অনুমতি নিয়ে।

Unit test: নিরীহ চিহ্ন দিয়ে

একটি নিরীহ <b> tag পাঠিয়ে দেখুন পাতায় সেটি encode হয়ে আসছে কি না। মোটা হরফ দেখা গেলে বুঝবেন encoding হচ্ছে না, আর কোনো ক্ষতিকর কিছুও চালাতে হলো না।

# উদাহরণ: নিজের app-এর test, client আপনার test framework-এর
def test_comment_is_encoded(client):
    client.post("/comments", data={"text": "<b>marker-7</b>"})
    page = client.get("/comments").text
    assert "&lt;b&gt;marker-7&lt;/b&gt;" in page
    assert "<b>marker-7</b>" not in page

নিজের কোডে বিপজ্জনক sink খোঁজা

grep -rnE "innerHTML|insertAdjacentHTML|dangerouslySetInnerHTML|v-html|\|safe" src/

প্রতিটি ফলাফল ভুল নয়, কিন্তু প্রতিটির পক্ষে একটি কারণ থাকা চাই। এই কাজটিই CI-তে SAST নিয়ম হয়ে চলতে পারে, যা Semgrep বা ESLint-এর মতো সরঞ্জামের নিরাপত্তা-নিয়মে পাওয়া যায়। আর নিজের staging পরিবেশে OWASP ZAP-এর মতো DAST সরঞ্জাম চালানো যায়, অনুমতিসহ। বিস্তারিত পর্ব ৪৯ · নিরাপত্তা পরীক্ষা-য়। Code review-তে “ডেটাটি কোথায় বসছে?” প্রশ্নটি একটি অভ্যাস করে নিন।

Detection

• CSP report: Enforce চালুর পরে হঠাৎ অচেনা report বেড়ে যাওয়া একটি সংকেত।
• অস্বাভাবিক account আচরণ: একসাথে অনেক account-এ একই বদল, যা আগের worm-ঘটনাগুলোর মতো ছড়ানোর লক্ষণ হতে পারে।
• Log-এ ডেটা দেখা: Admin panel-ও encode করে দেখাক; নিরাপত্তার log পড়ার পাতাও XSS-এর লক্ষ্য হতে পারে।

ঘটনা ঘটলে সাড়া

1. থামান: আক্রান্ত feature সাময়িক বন্ধ করুন।
2. মূল কারণ সারান: নির্দিষ্ট sink বা template ঠিক করুন, একই নকশা পুরো code-এ খুঁজুন।
3. জমা ডেটা পরিষ্কার: Stored হলে আক্রান্ত সারিগুলো খুঁজে সংশোধন করুন।
4. Session বাতিল: আক্রান্ত ব্যবহারকারীদের session শেষ করুন, প্রয়োজনে পরিচয় পুনরায় যাচাই।
5. ক্ষতি মাপুন আর জানান: Log দেখে কারা, কী তথ্য। প্রযোজ্য আইন আর নীতি অনুযায়ী জানান।
6. Regression test যোগ করুন: যাতে একই ভুল ফিরে না আসে।

১০ · AI-এর যুগে XSS প্রতিরক্ষা

AI খুব দ্রুত UI কোড লেখে, আর ঠিক সেই গতিতেই অনিরাপদ sink ঢুকিয়ে দিতে পারে। CSP-র error দেখে AI-কে “ঠিক করে দাও” বললে সে প্রায়ই নিরাপত্তা ঢিলে করেই error সরায়। তাই error চলে যাওয়া মানেই সমস্যা মিটে যাওয়া নয়।

AI-এর পরিবর্তন গ্রহণ করার আগে

• Diff-এ innerHTML, v-html, |safe বা dangerouslySetInnerHTML নতুন করে এসেছে কি না দেখেছি
• CSP header-এ 'unsafe-inline', 'unsafe-eval' বা * যোগ হয়নি
• নিরীহ <b> marker দিয়ে নিজের পরিবেশে পরীক্ষা করেছি
• উল্লেখ করা CVE, option আর standard মূল সূত্রে মিলিয়েছি
• Prompt-এ কোনো secret বা ব্যক্তিগত ডেটা পাঠাইনি
• Production-এ যাওয়ার সিদ্ধান্ত একজন মানুষ নিয়েছেন