Web hardening — security header, WAF, dependency আর নিরাপদ error

১ · Hardening কী — দোকান খোলার আগের শেষ টহল

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

Web hardening ঠিক এই টহল। পর্ব ৩৮ থেকে ৪৩ পর্যন্ত আমরা কোডের ভুল নিয়ে কথা বলেছি: authorization, injection, XSS, CSRF, file handling আর API. এবার প্রশ্ন আলাদা। কোড ঠিক থাকলেও সাইটটি যেভাবে চালু আছে, সেই চালু রাখার ধরনে কোনো ফাঁক আছে কি? OWASP Top 10:2025-এ Security Misconfiguration দ্বিতীয় স্থানে আর Software Supply Chain Failures তৃতীয় স্থানে আছে। আর নতুন যোগ হয়েছে Mishandling of Exceptional Conditions, যা error সামলানোর ভুলের কথা বলে। এই পর্বের বিষয়গুলো তাই ছোটখাটো সাজসজ্জা নয়।

এই পর্বের একটি স্থির উদাহরণ আছে: একটি কাল্পনিক অনলাইন বাজার, shop.example. সাইটটি আপনিই চালান। সব সংখ্যা মনগড়া, সব ডেটা পাতার ভেতরের ছোট খেলনা তালিকা। কোনো কোড বাইরে কোনো অনুরোধ পাঠায় না।

ছবিটি defense in depth-এর (পর্ব ৩) web সংস্করণ। এবার পুরো পর্বের মূল ফল, একটি production checklist. প্রতিটি লাইন পরে কোনো না কোনো অংশে ব্যাখ্যা করা হয়েছে। নিজের সাইটের জন্য এটি কপি করে নিন।

• HTTPS সব পাতায়, HTTP থেকে 301 redirect, certificate-এর মেয়াদের alert (পর্ব ১২)
• Security header পাঠানো হচ্ছে, CSP আগে Report-Only-তে পরীক্ষিত
• Directory listing বন্ধ, default পাতা আর নমুনা ফাইল মোছা
• Web root-এ .git, .env, backup, dump আর phpinfo নেই
• Debug mode বন্ধ, ব্যবহারকারী সাধারণ বার্তা পান, বিবরণ log-এ যায়
• Admin panel-এ MFA, দরকার হলে IP সীমা, আর default password নেই
• Dependency, CMS আর plugin হালনাগাদ, অব্যবহৃত plugin মোছা
• File permission সঠিক, কোথাও 777 নেই
• Backup সার্ভারের বাইরে, আর restore করে পরীক্ষা করা হয়েছে
• Uptime, error rate আর certificate-এর নজরদারি চালু, alert সঠিক মানুষের কাছে যায়

২ · Security header — browser-কে দেওয়া লিখিত নির্দেশ

অফিসের দারোয়ানকে মালিক একটি চিরকুট দিয়ে রাখলেন: “শুধু মূল গেট দিয়ে ঢুকতে দেবেন। বাইরের লোক ক্যামেরার ঘরে যাবেন না।” Security header সেই চিরকুট। Server প্রতিটি উত্তরের সাথে কিছু বাড়তি লাইন পাঠায়, আর browser সেই নিয়ম মেনে চলে। Header কোনো ভুল কোড সারায় না। ভুল কোডের ক্ষতি সীমিত করে, আর ভুল ব্যবহারের কিছু পথ বন্ধ করে।

Referrer-Policy-তে একটি ভালো খবর আছে। Header না দিলেও এখনকার browser সাধারণত strict-origin-when-cross-origin ধরে নেয়: নিজের সাইটের ভেতরে পুরো URL যায়, অন্য সাইটে শুধু origin, আর HTTPS থেকে HTTP-তে নামলে কিছুই যায় না। তবু header স্পষ্ট করে দেওয়া ভালো, কারণ তখন আপনার নীতি সব browser-এ একই থাকে।

যেগুলো অবসরে গেছে

X-XSS-Protection একসময় সাধারণ পরামর্শ ছিল। এখন এটি কোনো spec-এর অংশ নয়, MDN একে deprecated বলে আর CSP ব্যবহার করতে বলে। উল্টো, এই filter কখনো নিরাপদ সাইটেও সমস্যা তৈরি করতে পারত। তাই পুরোনো tutorial-এর 1; mode=block কপি করবেন না। Header না পাঠানো, অথবা 0 পাঠানোই ভালো। Public-Key-Pins (HPKP), Expect-CT আর Feature-Policy-ও একই পথের। শেষেরটির জায়গা নিয়েছে Permissions-Policy.

নিচের খেলনা auditor তিনটি কাল্পনিক সাইটের header-এর তালিকা পড়ে নম্বর দেয়। মান ও grade আমাদের নিজের বানানো স্কেল, কোনো standard নয়। Header-গুলো পাতার ভেতরের object-এ আছে, কোনো অনুরোধ যায় না।

// Toy header auditor. Reads in-memory objects only; sends no request.
const sites = {
  'shop-a.example': { 'strict-transport-security': 'max-age=31536000; includeSubDomains',
    'content-security-policy': "default-src 'self'; object-src 'none'; base-uri 'self'",
    'x-content-type-options': 'nosniff', 'referrer-policy': 'strict-origin-when-cross-origin',
    'permissions-policy': 'camera=(), microphone=()', 'server': 'nginx' },
  'shop-b.example': { 'strict-transport-security': 'max-age=86400',
    'content-security-policy-report-only': "default-src 'self'",
    'x-content-type-options': 'nosniff', 'referrer-policy': 'no-referrer' },
  'shop-c.example': { 'strict-transport-security': 'max-age=300',
    'content-security-policy': "default-src * 'unsafe-inline'",
    'x-xss-protection': '1; mode=block', 'server': 'Apache/2.4.41', 'x-powered-by': 'PHP/7.4.3' },
};
const YEAR_HALF = 15768000; // 182.5 days, in seconds
const checks = [
  ['HSTS', h => { const m = /max-age=(\d+)/.exec(h['strict-transport-security'] || '');
    return !m ? 0 : Number(m[1]) >= YEAR_HALF ? 20 : 10; }],
  ['CSP', h => { const c = h['content-security-policy'];
    if (!c) return h['content-security-policy-report-only'] ? 10 : 0;
    return /unsafe-inline|default-src \*/.test(c) ? 10 : 30; }],
  ['nosniff', h => h['x-content-type-options'] === 'nosniff' ? 15 : 0],
  ['Referrer', h => h['referrer-policy'] && h['referrer-policy'] !== 'unsafe-url' ? 15 : 0],
  ['Permissions', h => h['permissions-policy'] ? 10 : 0],
  ['NoLeak', h => /\d/.test(h['server'] || '') || h['x-powered-by'] ? 0 : 10],
  ['Retired', h => (h['x-xss-protection'] || '0') !== '0' ? -5 : 0],
];
const grade = s => s >= 90 ? 'A' : s >= 70 ? 'B' : s >= 50 ? 'C' : s >= 30 ? 'D' : 'F';
for (const [name, headers] of Object.entries(sites)) {
  const parts = checks.map(([label, fn]) => [label, fn(headers)]);
  const total = Math.max(0, parts.reduce((sum, p) => sum + p[1], 0));
  console.log(`${name}  score ${total}/100  grade ${grade(total)}`);
  console.log('  ' + parts.map(([l, v]) => `${l}=${v}`).join(' '));
}

shop-a.example  score 100/100  grade A
  HSTS=20 CSP=30 nosniff=15 Referrer=15 Permissions=10 NoLeak=10 Retired=0
shop-b.example  score 60/100  grade C
  HSTS=10 CSP=10 nosniff=15 Referrer=15 Permissions=0 NoLeak=10 Retired=0
shop-c.example  score 15/100  grade F
  HSTS=10 CSP=10 nosniff=0 Referrer=0 Permissions=0 NoLeak=0 Retired=-5

৩ · Header চালু করার কাজ — ধাপে ধাপে, ফেরার পথ রেখে

নতুন header সরাসরি চালু করলে দুই রকম বিপদ। কড়া CSP আপনার নিজের payment script, chat widget বা বিজ্ঞাপন আটকে দিতে পারে। আর বড় মেয়াদের HSTS দেওয়ার পর HTTPS-এ সমস্যা হলে যাঁরা header দেখেছেন, তাঁদের browser HTTP-তে ফিরবে না। ঈদের সেলের রাতে এটি জানার সময় নয়।

নিরাপদ পথটির নাম staged rollout: আগে শুধু দেখা, তারপর অল্প করে চালু, প্রতি ধাপে ফেরার রাস্তা মাপা। CSP-র জন্য browser-এর একটি বিশেষ header আছে, Content-Security-Policy-Report-Only. এটি কিছু আটকায় না, শুধু জানায় কী আটকাত। এটি IDS-এর শুধু-দেখা অবস্থা আর WAF-এর count mode-এর মতোই একটি audit mode. নিচের ডায়াগ্রামে shop.example-এর rollout দেখুন। সংখ্যাগুলো কাল্পনিক।

এবার বাস্তব config. নিচের দুটি উদাহরণের ধারণা একই। আপনার hosting অনুযায়ী একটি বেছে নিন। HSTS এখানে প্রথম ধাপে আছে, আর CSP আছে Report-Only-তে। মান বদলানোর আগে ওপরের ধাপগুলো মানুন। CSP-র /csp-report ঠিকানাটি উদাহরণ, সেখানে রিপোর্ট নেওয়ার ব্যবস্থা আপনাকেই করতে হবে। না থাকলে violation browser console-এও দেখা যায়।

# Apache 2.4; needs mod_headers and mod_alias. Test on staging first.
Options -Indexes

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=300"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; report-uri /csp-report"
  Header unset X-Powered-By
  Header always unset X-Powered-By
</IfModule>

# Hide dot-files, but keep /.well-known/ for ACME and security.txt
RedirectMatch 404 "/\.(?!well-known(/|$))"

# Backups do not belong here at all; this is only a second lock
<FilesMatch "\.(sql|bak|old)$">
  Require all denied
</FilesMatch>

# Inside your own server block. Test with: sudo nginx -t
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    server_tokens off;
    autoindex off;

    add_header Strict-Transport-Security "max-age=300" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; report-uri /csp-report" always;

    # Hide dot-files, keep /.well-known/
    location ~ /\.(?!well-known(/|$)) { deny all; }
}

Header ঠিকমতো যাচ্ছে কি না দেখার সহজ উপায় browser-এর DevTools. অথবা নিজের সাইটের জন্য একটি লাইন:

curl -sI https://example.com/

HTTP/2 200
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=300
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin

ওপরের লেখাটি নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে। সব header-ই দেখা উচিত, আর CDN থাকলে দেখুন সেটি header বদলে দিচ্ছে কি না। MDN HTTP Observatory-র মতো অনলাইন পরীক্ষকও আছে। সেগুলোও শুধু নিজের সাইটে ব্যবহার করুন।

৪ · নিজের সাইটে কী ফাঁস হচ্ছে — file আর তথ্যের হিসাব

বাড়ি বদলের পর পুরোনো চাবির গোছা অনেকে দরজার পাশেই ঝুলিয়ে রাখেন। Web সার্ভারেও এমন হয়। ডেভেলপার তাড়াহুড়োয় ফাইল রেখে যান, আর web root-এর ভেতরে যা আছে, server তা সাধারণত দিয়ে দেয়। এই ফাঁসকে বলে information disclosure. ঝুঁকিটি নিজের attack surface-এর অংশ, আর এটি খুঁজে পাওয়ার কাজ রক্ষকের।

সবচেয়ে ভালো যাচাই সার্ভারের ভেতর থেকে হয়, নিজের ফাইল দেখে। এতে কোনো network probe লাগে না। নিচের খেলনা কোড আপনার web root-এর একটি স্থির তালিকা পড়ে ঝুঁকি চিহ্নিত করে। কোনো সাইটে অনুরোধ যায় না, তালিকাটি array-এর ভেতরেই আছে।

// Static list of YOUR OWN web root (toy data). No request is sent anywhere.
const webRoot = [
  'index.html', 'css/style.css', 'robots.txt', 'uploads/photo.jpg',
  '.well-known/security.txt', '.git/config', '.env', 'db_dump.sql',
  'backup/site-2026-10.zip', 'wp-config.php.bak', 'phpinfo.php',
  'error_log', 'admin/index.php',
];
const rules = [
  [/^\.well-known\//, 'OK', 'public on purpose'],
  [/(^|\/)\.git\//, 'HIGH', 'remove; deploy without the repository'],
  [/(^|\/)\.env$/, 'HIGH', 'move outside web root; rotate every secret'],
  [/\.(sql|zip|tar|gz|bak|old)$|~$/, 'HIGH', 'move backups off the web root'],
  [/phpinfo\.php$/, 'MEDIUM', 'delete after use'],
  [/(^|\/)error_log$/, 'MEDIUM', 'keep logs outside web root'],
  [/^admin\//, 'REVIEW', 'add IP limit and MFA; not a secret path'],
];
const count = { OK: 0, HIGH: 0, MEDIUM: 0, REVIEW: 0 };
for (const path of webRoot) {
  const hit = rules.find(([re]) => re.test(path));
  const level = hit ? hit[1] : 'OK';
  count[level]++;
  if (level !== 'OK') console.log(level.padEnd(7) + path.padEnd(25) + hit[2]);
}
console.log('--');
console.log(`checked ${webRoot.length} paths:`, JSON.stringify(count));
console.log(count.HIGH > 0 ? 'RESULT: fix HIGH items before launch' : 'RESULT: clean');

HIGH   .git/config              remove; deploy without the repository
HIGH   .env                     move outside web root; rotate every secret
HIGH   db_dump.sql              move backups off the web root
HIGH   backup/site-2026-10.zip  move backups off the web root
HIGH   wp-config.php.bak        move backups off the web root
MEDIUM phpinfo.php              delete after use
MEDIUM error_log                keep logs outside web root
REVIEW admin/index.php          add IP limit and MFA; not a secret path
--
checked 13 paths: {"OK":5,"HIGH":5,"MEDIUM":2,"REVIEW":1}
RESULT: fix HIGH items before launch

একই কাজ বাস্তবে নিজের hosting account-এর terminal থেকে হয়। cPanel-এর Terminal বা SSH থাকলে এটি শুধু আপনার নিজের ফাইল পড়ে, বাইরে কোনো অনুরোধ পাঠায় না।

# Run only on your own account. Read-only: nothing is changed.
cd ~/public_html
find . \( -name '.env' -o -name '.git' -o -name '*.sql' \
       -o -name '*.bak' -o -name '*.old' -o -name 'phpinfo.php' \) -print

# Files or folders that any account may write to
find . -perm -o+w -print

৫ · নিরাপদ error — ব্যবহারকারীকে কম, log-এ বেশি

ব্যাংকের কাউন্টারে সিস্টেম নষ্ট হলে কর্মকর্তা বলেন, “দুঃখিত, এখন সার্ভারে সমস্যা, এই নম্বরটি রাখুন।” তিনি গ্রাহককে ভল্টের নকশা বা সার্ভার রুমের পাসওয়ার্ড শোনান না। ভেতরের রেজিস্টার খাতায় পুরো ঘটনা লেখেন। Web-এর নিরাপদ error handling-ও ঠিক তাই।

Development-এ debug mode খুব কাজের। কিন্তু production-এ এটি stack trace, ফাইলের পথ, query, এমনকি environment-এর মান দেখাতে পারে। কিছু framework-এর debug পাতায় ভেতরের console-ও থাকতে পারে, যা তখন সরাসরি কোড চালানোর ঝুঁকিতে দাঁড়ায়। তিনটি নিয়ম মনে রাখুন:

• ব্যবহারকারী পান: সাধারণ বার্তা, সঠিক HTTP status আর একটি correlation id.
• Log পায়: সময়, path, কারণ, id, তবে password, token আর PIN বাদ দিয়ে। Log-এর নীতি আছে পর্ব ৫৫-এ।
• Error-এ দরজা বন্ধ থাকে: Permission যাচাই ব্যর্থ হলে উত্তর “না”। এটিই fail secure (পর্ব ৩)। OWASP Top 10:2025-এর A10 এই ধরনের ভুল নিয়েই।

// Toy error handler. Fake data; the clock is simulated, nothing is sent.
let clock = 1000, nextId = 41;
const SECRET_KEYS = ['password', 'token', 'pin'];
const scrub = ctx => Object.fromEntries(Object.entries(ctx).map(
  ([k, v]) => [k, SECRET_KEYS.includes(k) ? '[REDACTED]' : v]));
const logBook = [];

function handle(route, ctx, work, debug) {
  try {
    return { status: 200, body: work() };
  } catch (e) {
    clock += 5;
    const id = 'E-' + (nextId++).toString(16).padStart(4, '0');
    logBook.push({ id, t: clock, route, msg: e.message, ctx: scrub(ctx) });
    if (debug) return { status: 500, body: e.message + ' | ' + JSON.stringify(ctx) };
    return { status: 500, body: `Something went wrong. Reference: ${id}` };
  }
}
const failingQuery = () => {
  throw new Error('db.internal.example:3306 refused for user shop_app');
};
const ctx = { user: 'u-1042', token: 'example-token' };

const bad = handle('/checkout', ctx, failingQuery, true);
const good = handle('/checkout', ctx, failingQuery, false);
const fine = handle('/home', {}, () => 'welcome', false);

console.log('DEBUG ON  user sees:', bad.status, bad.body);
console.log('DEBUG OFF user sees:', good.status, good.body);
console.log('NORMAL    user sees:', fine.status, fine.body);
console.log('-- server log only --');
logBook.forEach(entry => console.log(JSON.stringify(entry)));

DEBUG ON  user sees: 500 db.internal.example:3306 refused for user shop_app | {"user":"u-1042","token":"example-token"}
DEBUG OFF user sees: 500 Something went wrong. Reference: E-002a
NORMAL    user sees: 200 welcome
-- server log only --
{"id":"E-0029","t":1005,"route":"/checkout","msg":"db.internal.example:3306 refused for user shop_app","ctx":{"user":"u-1042","token":"[REDACTED]"}}
{"id":"E-002a","t":1010,"route":"/checkout","msg":"db.internal.example:3306 refused for user shop_app","ctx":{"user":"u-1042","token":"[REDACTED]"}}

Debug বন্ধ করার switch প্রতিটি stack-এ আলাদা। ঠিক নামটি নিজের version-এর docs থেকে মিলিয়ে নিন।

Login-এ error-এর আরেকটি ফাঁদ আছে। “এই email নেই” আর “password ভুল” আলাদা বললে account enumeration-এর পথ খোলে। তাই বার্তা একটিই রাখুন, “email বা password সঠিক নয়” (পর্ব ১৫)।

এবার একটি কাল্পনিক ঘটনা। সব মান বানানো, কোনো secret আসল নয়। shop.example-এর checkout পাতায় বৃহস্পতিবার রাতে নতুন release গেছে।

Exception: connection refused
at /var/www/shop/app/Checkout.php:88
DB_HOST=db.internal.example
DB_USER=shop_app
DB_PASSWORD=example-token
APP_DEBUG=true

দুঃখিত, একটি সমস্যা হয়েছে।
Reference: E-002a

grep -qx 'APP_DEBUG=false' .env.production \
  || { echo 'debug is on: stop'; exit 1; }

৬ · WAF — ঢাল হিসেবে ভালো, চিকিৎসা হিসেবে নয়

WAF (Web Application Firewall) HTTP অনুরোধের ভেতরটা পড়ে নিয়ম ধরে সিদ্ধান্ত নেয়। Rule-এর ধরন, count ও block action আর cloud-এ বসানোর পদ্ধতি বিস্তারিত আছে CDN, WAF আর edge-এর পর্বে। সেগুলো এখানে আর বলছি না। এখানে নিরাপত্তার প্রশ্ন তিনটি: কোন মডেলে চলে, ভুল করলে কী হয়, আর কোথায় থামে।

Negative আর positive security

এখানে সেই denylist আর allowlist-এর পুরোনো হিসাবই চলে। বাস্তবে দুটি মেলানো হয়। বাইরে সাধারণ rule set, আর সংবেদনশীল API-তে schema ধরে positive নিয়ম (পর্ব ৪৩)।

False positive আর তার tuning

WAF শব্দের ধরন মেলায়, অর্থ বোঝে না। তাই নিরীহ লেখাও সন্দেহজনক মনে হতে পারে। নিচের ডায়াগ্রামে একটি খেলনা rule আছে, যা একই ক্ষেত্রে select আর from শব্দ পেলে সন্দেহ করে। আসল rule আরও জটিল হয়, কিন্তু সমস্যাটি একই। সংখ্যাগুলো কাল্পনিক।

path=/support/message  field=message
text="please select a blue size from the list"
action=COUNT  rule=toy-sql-words

rule=toy-sql-words  skip when
  path == /support/message AND field == message
owner=web-team  review=2027-01-31

WAF কোড সারানোর বদলি কেন নয়

• যুক্তির ভুল সে দেখে না। অন্য গ্রাহকের order id চাওয়ার অনুরোধ দেখতে একদম স্বাভাবিক। Broken access control-এর (পর্ব ৩৮) সামনে WAF প্রায় অন্ধ, কারণ তার জানা নেই কোন order কার।
• Pattern-এর সীমা আছে। যে ধরন rule-এর অচেনা, তা পার হতে পারে। তাই একে শেষ দেয়াল ধরা বিপজ্জনক।
• ভেতরের পথ বাদ পড়ে। Origin সরাসরি খোলা থাকলে WAF-কে পাশ কাটিয়ে অনুরোধ পৌঁছায়। Origin রক্ষার কথা আছে cloud কোর্সের ওই পর্বেই।

WAF-এর সত্যিকারের ভালো ব্যবহার virtual patch: নতুন ত্রুটি প্রকাশের পর আসল patch না হওয়া পর্যন্ত একটি সরু rule দিয়ে সময় কেনা (পর্ব ৩২)। মেয়াদ দিন, আর আসল সমাধান শেষ হলে rule-টি পর্যালোচনা করুন। ঝুঁকি কমানোর এই অস্থায়ী উপায়কে বলে compensating control.

৭ · Dependency আর third-party script — অন্যের কোডে বিশ্বাসের হিসাব

রেস্টুরেন্টের রান্নাঘর পরিষ্কার হতে পারে, কিন্তু বাইরের মসলা ভেজাল হলে খাবার তবু খারাপ। আপনার সাইটের বড় অংশ অন্যের লেখা কোড। Transitive dependency ধরলে তালিকা আরও লম্বা। পুরো supply chain আলাদা করে আছে পর্ব ৪৮-এ। এখানে শুধু দৈনন্দিন hardening.

Third-party script আরও সরাসরি ঝুঁকি। Analytics, chat, বিজ্ঞাপন বা CDN-এর একটি <script src> আপনার পাতায় আপনার কোডের সমান ক্ষমতা পায়। সেটি form-এর লেখাও পড়তে পারে। ২০২৪ সালে polyfill.io-র ঘটনায় Sansec-এর প্রকাশিত প্রতিবেদন বলছে, domain-এর মালিকানা বদলের পরে এক লাখের বেশি সাইটে embed করা সেই script থেকে কিছু মোবাইল ব্যবহারকারীকে অন্য সাইটে পাঠানো হচ্ছিল। সাইট মালিকরা নিজের কোড একটুও বদলাননি।

Subresource Integrity (SRI, W3C Recommendation, ২০১৬) এর একটি উত্তর। পোস্ট অফিসের সিলমোহর করা খামের মতো: খাম খুলে সিল না মিললে জিনিসটি নেওয়া হয় না। আপনি HTML-এ ফাইলের প্রত্যাশিত hash লিখে দেন। Browser ফাইল এনে hash মেলায়, না মিললে চালায় না (hash-এর ভিত্তি পর্ব ৯)।

# SRI value for a fake script held in memory. Nothing is downloaded.
import base64
import hashlib


def sri(data: bytes, algorithm: str = "sha384") -> str:
    digest = hashlib.new(algorithm, data).digest()
    return algorithm + "-" + base64.b64encode(digest).decode("ascii")


pinned_file = b"function greet(){return 'hello from example CDN';}\n"
changed_file = b"function greet(){return 'hello from example CDN!';}\n"

expected = sri(pinned_file)
print("integrity value:", expected)

digest_bytes = hashlib.sha384(pinned_file).digest_size
base64_chars = len(expected.split("-", 1)[1])
print("digest bytes:", digest_bytes, "base64 chars:", base64_chars)

for label, delivered in [("same file", pinned_file), ("one char added", changed_file)]:
    actual = sri(delivered)
    decision = "RUN" if actual == expected else "BLOCK (network error)"
    print(f"{label:15} {actual[:25]}... {decision}")

integrity value: sha384-QJjojmQzbULHbKbJK7ioD/QFXaHq5lR+mCoWZ7yJtCBTotebeWjt8oytUhpoWdhH
digest bytes: 48 base64 chars: 64
same file       sha384-QJjojmQzbULHbKbJK7... RUN
one char added  sha384-CrooZN9QULXst6+jOj... BLOCK (network error)

HTML-এ এটি এভাবে বসে। অন্য origin-এর ফাইলে crossorigin আর সেই server-এর CORS অনুমতিও লাগে।

<script src="https://cdn.example.com/lib-1.2.3.min.js"
        integrity="sha384-QJjojmQzbULHbKbJK7ioD/QFXaHq5lR+mCoWZ7yJtCBTotebeWjt8oytUhpoWdhH"
        crossorigin="anonymous"></script>

৮ · CMS, plugin আর shared hosting — ছোট সাইটের বাস্তবতা

বাংলাদেশের বহু ছোট ব্যবসা, স্কুল, পত্রিকা আর ব্যক্তিগত সাইট চলে একটি CMS আর সস্তা shared hosting-এ, প্রায়ই cPanel-জাতীয় panel দিয়ে। এখানে CDN বা WAF-এর বাজেট নাও থাকতে পারে। কিন্তু সবচেয়ে কাজের hardening-এর বেশিরভাগই বিনা খরচে করা যায়।

CMS আর plugin

WordPress উদাহরণ হিসেবে নিচ্ছি, কারণ এটি বহুল ব্যবহৃত, এটি অন্যগুলোর চেয়ে দুর্বল বলে নয়। অন্য CMS-এও একই নীতি চলে। অভিজ্ঞতায় অনেক সমস্যা আসে মূল software থেকে নয়, plugin আর theme থেকে।

• Update চালু রাখুন: Core, theme আর plugin. স্বয়ংক্রিয় update সম্ভব হলে নিন, তবে আগে backup নিশ্চিত করুন।
• কম plugin: অব্যবহৃত plugin শুধু বন্ধ নয়, মুছে ফেলুন। দীর্ঘদিন আপডেট না পাওয়া plugin বদল করুন।
• Crack করা paid plugin বা theme নয়: অজানা উৎসের “free” কপিতে লুকানো কোড থাকতে পারে। সস্তা দেখালেও এটি সবচেয়ে দামি ভুলগুলোর একটি।
• Admin account: MFA, শক্ত password, আলাদা ব্যবহারকারী, admin নাম নয়। Login-এ rate limit (পর্ব ১৬)।
• Panel থেকে ফাইল সম্পাদনা বন্ধ: WordPress-এ DISALLOW_FILE_EDIT-এর মতো setting আছে। Admin account দখল হলেও ক্ষতি কিছুটা কমে।

File permission

Shared hosting-এ একই machine-এ বহু গ্রাহক থাকেন, যেন একই ভবনের ভিন্ন ভাড়াটিয়া। তাই file permission গুরুত্বপূর্ণ। সংখ্যার তিনটি ঘর হলো মালিক, group আর অন্যরা। ৪ মানে পড়া, ২ মানে লেখা, ১ মানে চালানো বা ফোল্ডারে ঢোকা। মূল তত্ত্ব আছে OS কোর্সে আর পর্ব ৩০-এ।

cPanel-জাতীয় hosting-এ আরও কিছু কাজ: panel-এ MFA চালু করুন, FTP-র বদলে SFTP নিন, পুরোনো PHP version বদলান, একই account-এ অনেক সাইট গাদাগাদি না রাখুন। কারণ একটি অবহেলিত পুরোনো সাইট দিয়ে পুরো account ঝুঁকিতে পড়তে পারে। এটি blast radius-এর সহজ উদাহরণ। ভুলে থাকা subdomain আর পুরোনো staging সাইটও খুঁজে সরিয়ে ফেলুন।

৯ · Backup, monitoring আর uptime — খারাপ দিনের প্রস্তুতি

Hardening ঝুঁকি কমায়, শূন্য করে না। সাইট একদিন ভাঙতে পারে, ভুল update-এ বা হামলায়। তখন প্রশ্ন দুটি: আপনি কত দ্রুত জানবেন, আর কতটা ফিরিয়ে আনতে পারবেন।

Backup

• সার্ভারের বাইরে কপি: Backup একই account-এ থাকলে হ্যাক হলে সেটিও যাবে। 3-2-1-1-0 নিয়মের ভিত্তি আছে পর্ব ৩৪-এ।
• Host-এর backup-কে নিজের ভাববেন না: মেয়াদ, শর্ত আর ফেরত দেওয়ার নিয়ম host-ভেদে আলাদা। নিজের একটি কপি রাখুন।
• ফাইল আর database দুটোই: শুধু ফাইল ফেরালে order আর গ্রাহকের তথ্য থাকবে না। প্রতিদিন একবার backup মানে সর্বোচ্চ প্রায় ২৪ ঘণ্টার ডেটা হারানোর ঝুঁকি, যা RPO.
• পুরোনো কপিও রাখুন: হামলা হয়তো ২ সপ্তাহ আগে হয়েছে। মাত্র ৭ দিনের backup তখন সবগুলোই দূষিত।
• Restore করে দেখুন: Restore test ছাড়া backup শুধু একটি আশা। বিস্তারিত আছে Backup আর DR-এর পর্বে।

Monitoring আর uptime

Alert এমন জায়গায় যাওয়া দরকার, যা কেউ দেখেন। কে দেখবেন, রাতে কে ফোন ধরবেন, সেটি একটি ছোট runbook-এ লিখুন। Alert-এর নকশা আছে SLO আর alert-এর পর্বে। আর সাইটে /.well-known/security.txt রাখলে (security.txt) কোনো সৎ গবেষক ত্রুটি পেলে কোথায় জানাবেন, তা সহজে খুঁজে পান।

১০ · AI-এর যুগে web hardening

AI খুব দ্রুত একটি header block লিখে দিতে পারে। সমস্যা হলো, সে আপনার সাইট দেখতে পায় না। সে জানে না আপনার payment script কোন domain থেকে আসে, বা কোন subdomain এখনো HTTP-তে আছে। আর বহু পুরোনো tutorial থেকে শেখা অভ্যাসও সে নিয়ে আসে।

AI-এর পরামর্শ চালু করার আগে

• প্রতিটি header আর directive MDN বা অফিসিয়াল docs-এ মিলিয়ে দেখেছি
• আগে staging-এ বা Report-Only-তে চালিয়েছি, আর ফেরার পথ জানি
• Prompt-এ কোনো secret, token, আসল log বা ব্যক্তিগত তথ্য দিইনি
• “Error ঠিক করতে check বন্ধ করুন” ধরনের পরামর্শ মানিনি, কারণ খুঁজেছি
• পরিবর্তনের diff নিজে পড়েছি, প্রতিটি লাইনের কাজ বলতে পারি
• Scanner-এর ফল বা AI-র “নিরাপদ” রায় চূড়ান্ত মানিনি, সিদ্ধান্ত মানুষের