ক্রস-সাইট স্ক্রিপ্টিং (XSS)

১ · XSS আসলে কী — এবং এটি কাকে লক্ষ্য করে

Cross-Site Scripting (XSS)XSSঅবিশ্বস্ত ইউজার ইনপুট কোনো এস্কেপিং ছাড়াই পেজে HTML/JavaScript হিসেবে রেন্ডার হওয়ার ফলে তৈরি হওয়া দুর্বলতা — আক্রমণকারীর স্ক্রিপ্ট ভুক্তভোগীর ব্রাউজারে ভুক্তভোগীরই সেশন/অনুমতি নিয়ে চলে। অন্যান্য অনেক OWASP ক্যাটাগরি (যেমন L20-এর SQLi) সার্ভার বা ডেটাবেসকে লক্ষ্য করে। XSS সম্পূর্ণ ভিন্ন — এখানে চূড়ান্ত লক্ষ্য হলো অন্য ব্যবহারকারীর ব্রাউজার। যদি একটি ওয়েবসাইট ব্যবহারকারীর দেওয়া টেক্সট (যেমন একটি কমেন্ট) কোনো প্রকার নিরাপত্তা-প্রক্রিয়াকরণ ছাড়াই সরাসরি পেজে বসিয়ে দেয়, এবং সেই টেক্সটে <script>...</script>-এর মতো কোড থাকে, তাহলে সেই স্ক্রিপ্ট ঠিক সেই ওয়েবসাইটের নিজের প্রেক্ষাপটে প্রতিটি ভিজিটরের ব্রাউজারে চলে — যা দিয়ে সেশন কুকি চুরি করা বা ভুক্তভোগীর হয়ে অ্যাকশন নেওয়া সম্ভব হতে পারে।

২ · তিন প্রকার XSS

৩ · প্রতিরক্ষা — Context-Aware Output Encoding

XSS-এর মূল কারণ ইনপুট নয় — মূল কারণ হলো আউটপুট রেন্ডার করার সময় এস্কেপ না করা। সঠিক ফিক্স হলো Context-Aware Output EncodingContext-Aware Output Encodingইউজার ইনপুট পেজে বসানোর ঠিক আগে, যে প্রেক্ষাপটে (HTML বডি, HTML অ্যাট্রিবিউট, JavaScript স্ট্রিং ইত্যাদি) বসানো হচ্ছে তার উপযোগী পদ্ধতিতে বিপজ্জনক ক্যারেক্টার এনকোড করে দেওয়া। — রেন্ডার করার ঠিক আগে ইউজার ইনপুটের <, >, &, ", ' ক্যারেক্টারগুলো তাদের নিরাপদ HTML-এনটিটি রূপে (যেমন <) রূপান্তর করা। এর ফলে ব্রাউজার সেই টেক্সটকে কোড হিসেবে নয়, স্রেফ লেখা হিসেবে দেখায় — দেখতে অবিকল একই থাকে, কিন্তু আর এক্সিকিউট হয় না। Content-Security-Policy (CSP) হেডার একটি অতিরিক্ত defense-in-depth স্তর (ties to L23-এর মিসিং-হেডার আলোচনা) — এটি ব্রাউজারকে বলে দেয় কোন উৎস থেকে স্ক্রিপ্ট চালানো অনুমোদিত, তাই এস্কেপিং ফসকে গেলেও CSP অনেক XSS পেলোডকে ব্লক করতে পারে।

৪ · কোড ডেমো — ইনসিকিউর বনাম সিকিউর কমেন্ট-রেন্ডারার

নিচের কোড সেলটি সম্পূর্ণ স্যান্ডবক্সড — এটি একটি ভুয়া ইন-মেমরি "কমেন্ট" তালিকা নিয়ে কাজ করছে, কোনো বাস্তব ওয়েবসাইট, ব্রাউজার DOM বা নেটওয়ার্ক এখানে জড়িত নয়। ইনসিকিউর ফাংশনটি একটি <script> পেলোড ফেরত দেয় — কিন্তু এটি সবসময় একটি সাধারণ Python স্ট্রিং হিসেবেই থেকে যায়, কখনো প্রকৃত HTML/JS হিসেবে রেন্ডার বা এক্সিকিউট করা হচ্ছে না — আমরা শুধু print() দিয়ে দেখছি এটি বাস্তব ব্রাউজারে কী দেখাত।

import html

# ভুয়া ইন-মেমরি "কমেন্ট" স্টোর -- বাস্তব কোনো ওয়েবসাইট, ডেটাবেস বা DOM নয়
comments = []

def post_comment(text):
    comments.append(text)

def render_comment_insecure(text):
    # ইনসিকিউর: raw স্ট্রিং যেমন এসেছে ঠিক তেমনই ফেরত দেওয়া হচ্ছে, কোনো এস্কেপিং নেই।
    # এই ফাংশনটি এখানে শুধুই একটি স্ট্রিং রিটার্ন করছে -- আমরা এটিকে কখনো প্রকৃত
    # HTML/DOM-এ বসাচ্ছি না বা কোনো JavaScript ইঞ্জিনে চালাচ্ছি না। এটি শুধু দেখায়
    # বাস্তব একটি ভালনারেবল সার্ভার কী স্ট্রিং পাঠাত।
    return text

def render_comment_secure(text):
    # সিকিউর: real Python stdlib html.escape() ব্যবহার করে বিপজ্জনক ক্যারেক্টার
    # (<, >, &, ", ') নিরাপদ HTML এনটিটিতে রূপান্তর করা হচ্ছে
    return html.escape(text)

# একটি toy আক্রমণ-পেলোড -- শুধুমাত্র একটি Python স্ট্রিং, কখনো এক্সিকিউট করা হয় না
attacker_payload = "সুন্দর পোস্ট! <script>steal_cookie()</script>"
post_comment(attacker_payload)

print("== ইনসিকিউর রেন্ডার (raw স্ট্রিং, শুধু প্রিন্ট -- কোথাও এক্সিকিউট হচ্ছে না) ==")
print(render_comment_insecure(comments[0]))
print("(বাস্তব ব্রাউজারে unescaped বসানো হলে <script> ট্যাগ সত্যিই চলত -- এখানে তা ঘটছে না)")

print()
print("== সিকিউর রেন্ডার (html.escape() প্রয়োগের পর) ==")
print(render_comment_secure(comments[0]))
print("(এখন <script> ট্যাগ নিষ্ক্রিয় টেক্সট -- ব্রাউজার একে কোড নয়, নিছক লেখা হিসেবে দেখাবে)")

৫ · কেন "ইনপুট ভ্যালিডেশন" একা যথেষ্ট নয়

একটি সাধারণ ভুল ধারণা হলো XSS ঠেকাতে শুধু ইনপুটে <script> শব্দটি ব্লক করলেই যথেষ্ট। বাস্তবে আক্রমণকারীরা অসংখ্য বিকল্প উপায়ে (ইভেন্ট হ্যান্ডলার অ্যাট্রিবিউট, বিভিন্ন এনকোডিং, ইত্যাদি) একই ফলাফল অর্জন করতে পারে — তাই "খারাপ শব্দ ব্লক করা" (blocklisting) কখনো নির্ভরযোগ্য সমাধান নয়। আসল সমাধান সবসময় আউটপুট এস্কেপিং — রেন্ডার করার মুহূর্তে, প্রতিটি প্রেক্ষাপটে সঠিকভাবে এনকোড করা, ইনপুট কী তা অনুমান করে ব্লক করার চেষ্টা নয়।