1. “অধ্যায় 53: CSRF, CORS & Clickjacking” scenario-তে মূল control কোনটি?
state-changing request-এ CSRF token, SameSite cookie ও exact-origin policy—এটাই অধ্যায় 53: CSRF, CORS & Clickjacking-এর প্রধান defensive control.
Browser trust boundary, CSRF token ও frame policy.
অগ্রগতি এই browser-এ স্থানীয়ভাবে সংরক্ষিত হবে।
পাঠাগারে নীলা এক ক্লিকে বই ধার নেওয়ার সুবিধা বানাল। browser আগের login cookie নিজে পাঠাতে পারে বুঝে সে CSRF, CORS ও frame-এ পেজ দেখানোকে তিনটি আলাদা নিয়ন্ত্রণ হিসেবে নকশা করল। বৃষ্টি ম্যাম বললেন, “সৌরভ সোনা, আগে সমস্যাটাকে ছোট করে বুঝি—কোন সম্পদ, কার অনুমতি, আর কোন সীমার মধ্যে কাজ?” সৌরভ বোর্ডে একটি data-flow এঁকে সম্ভাব্য ভুলের জায়গা চিহ্নিত করল। তারা বাস্তব কোনো account বা website-এ হাত না দিয়ে synthetic উদাহরণে hypothesis যাচাই করল।
বৃষ্টি ম্যাম জিজ্ঞেস করলেন, “সৌরভ, গল্পের চরিত্রটি কোন সীমা পেরোতে দিচ্ছিল?” তারা বোর্ডে asset, actor, trust boundary আর expected outcome লিখল। ভুলটি শুধু একটি tool-এর সমস্যা নয়; server কী অনুমতি দিচ্ছে, আর সেই সিদ্ধান্ত যাচাই করা যায় কি না—সেটিই মূল প্রশ্ন।
তারপর তারা বাস্তব service ছুঁয়ে না দেখে synthetic record-এ একই decision অনুশীলন করল। প্রথমে স্বাভাবিক অনুমোদিত flow, তারপর ভুল পরিচয়/invalid state, শেষে fix-এর পর retest। বৃষ্টি ম্যাম বললেন, “সোনা, নিরাপদ শেখা মানে কেবল সমস্যা দেখানো নয়—সীমা মেনে প্রতিরক্ষা প্রমাণ করাও।”
সমস্যা: CORS, CSRF ও clickjacking আলাদা ঝুঁকি; একটির control অন্যটি মেটায় না।
মূল নিয়ম: state-changing request-এ CSRF token, SameSite cookie ও exact-origin policy। এই নিয়মটি Browser trust boundary, CSRF token ও frame policy.-এর সঙ্গে মিলিয়ে threat boundary-তে enforce করো; শুধু UI, client-side check বা model instruction-এ ভরসা কোরো না। প্রত্যাখ্যানের কারণ user-কে নিরাপদভাবে জানাও, আর diagnosis-এর জন্য সীমিত redacted event রাখো।
নিচের snippet-টি illustrative pseudocode। এটি কোনো বাইরের target-এ পরীক্ষা চালায় না; control কীভাবে server-side-এ বসে তা দেখায়।
if not valid_csrf(request):
deny()
if request.origin not in TRUSTED_ORIGINS:
deny()Review checklist: explicit scope, least privilege, malformed/unauthorized negative case, privacy-safe logging এবং post-fix retest।
পাঠাগারের account settings cookie-ভিত্তিক। browser cross-site form পাঠালে কী safeguard নেবে? কেবল isolated mock বা লিখিত অনুমতিপ্রাপ্ত lab-এ চেষ্টা করো। expected result এবং deny case লিখে রাখো।
state-changing request-এ CSRF token, SameSite cookie ও exact-origin policy SameSite cookies, anti-CSRF token, exact CORS origins ও CSP frame-ancestors. remediation-এর owner ও retest ফলাফলও নথিভুক্ত করো।
Review: owner, telemetry, failure behavior ও retest ফলাফল নথিভুক্ত করো।
Scope, synthetic setup, পর্যবেক্ষণ, ঝুঁকি, remediation ও retest লিখে রাখো। secret বা ব্যক্তিগত তথ্য যোগ কোরো না।
Fictional app-এর response header থেকে risk memo লেখো.
Scenario: পাঠাগারের account settings cookie-ভিত্তিক। browser cross-site form পাঠালে কী safeguard নেবে?
একটি defensive সিদ্ধান্ত বেছে নিয়ে ল্যাব চালু করো চাপো। এটি synthetic scenario; কোনো network request করা হয় না।
CORS, CSRF ও clickjacking আলাদা ঝুঁকি; একটির control অন্যটি মেটায় না।—সফল সমাধানে scope, control এবং retest—তিনটিই উল্লেখ করো।
প্রতিটি প্রশ্নে একটি উত্তর বেছে নাও। ব্যাখ্যাসহ স্কোর নিচে দেখা যাবে।
state-changing request-এ CSRF token, SameSite cookie ও exact-origin policy—এটাই অধ্যায় 53: CSRF, CORS & Clickjacking-এর প্রধান defensive control.
CORS, CSRF ও clickjacking আলাদা ঝুঁকি; একটির control অন্যটি মেটায় না। হওয়ায় access, data বা service impact হতে পারে.
Synthetic isolated environment production data বা অন্যের service-কে ঝুঁকিতে ফেলে না.
Negative case control bypass বা fail-open আচরণ ধরতে সাহায্য করে.
এতে তদন্তযোগ্য প্রমাণ থাকে, কিন্তু secret বা customer payload লগ হয় না.
আগে scope স্থির করলে পরীক্ষা অনুমোদিত ও সীমাবদ্ধ থাকে.
validation ব্যর্থতায় fail-closed আচরণ নিরাপদ.
Code/config ও synthetic test control বাস্তবে কার্যকর কি না দেখায়.
Retest fix ও regression দুটোই যাচাই করে.
এই তথ্য remediation-কে actionable করে, sensitive data প্রকাশ না করে.
স্কোর: ০ / ১০
আরও পড়ার জন্য প্রতিষ্ঠিত security standards ও guidance দেখো; প্রতিটি lab অনুমোদিত বা synthetic environment-এ করো।