CORS Misconfiguration: ওয়েব অ্যাপ্লিকেশনের কনফিগারেশন ভুলে ডেটা লিক হওয়ার ঝুঁকি!

Cross-Origin Resource Sharing হলো একটি ব্রাউজার-ভিত্তিক প্রোটোকল যা ওয়েব সার্ভারকে নির্দিষ্ট অরিজিনগুলোর সাথে রিসোর্স শেয়ার করার অনুমতি দেয়। সাধারণভাবে, ব্রাউজার Same-Origin Policy অনুসরণ করে, অর্থাৎ একটি ওয়েবসাইট থেকে অন্য ওয়েবসাইটে অ্যাজাক্স রিকোয়েস্ট পাঠানো বা রেসপন্স পড়া বন্ধ থাকে। এই নিয়ম থাকার কারণেই attacker.com থেকে কোনো ম্যালিশাস স্ক্রিপ্ট bank.com-এর ইউজার সেশন ব্যবহার করে গোপন তথ্য পড়তে পারে না।

কিন্তু আধুনিক ওয়েব অ্যাপ্লিকেশনে API gateway, microservices আর্কিটেকচার এবং Single Page Application বা SPA-এর কারণে বিভিন্ন ডোমেইনের মধ্যে রিসোর্স শেয়ার করা প্রয়োজন হয়ে পড়ে। এখানেই CORS কাজ করে। সার্ভার যখন Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods এর মতো বিশেষ HTTP হেডার পাঠায়, তখন ব্রাউজার সেগুলো পড়ে সিদ্ধান্ত নেয় যে কোন অরিজিনের রিকোয়েস্ট সফলভাবে রেসপন্স পড়তে পারবে।

CORS-এর কার্যপদ্ধতি দুই ধরনের রিকোয়েস্টে বিভক্ত। প্রথমটি হলো Simple Request যেখানে শুধুমাত্র GET, HEAD অথবা POST মেথড ব্যবহৃত হয় এবং কোনো জটিল হেডার থাকে না। দ্বিতীয়টি হলো Preflight Request যেখানে ব্রাউজার প্রকৃত রিকোয়েস্ট পাঠানোর আগে একটি OPTIONS রিকোয়েস্ট পাঠিয়ে সার্ভারের অনুমতি যাচাই করে। এই দুটি প্রক্রিয়ার সঠিক বাস্তবায়নই নিরাপদ ক্রস-অরিজিন যোগাযোগের ভিত্তি।

CORS Misconfiguration বলতে বোঝায় সেই সকল কনফিগারেশন ত্রুটি যেখানে সার্ভার ভুলভাবে অননুমোদিত অরিজিনগুলোকে সংবেদনশীল ডেটায় প্রবেশের অনুমতি দিয়ে দেয়। বিশেষ করে যখন Access-Control-Allow-Credentials হেডার true সেট করা থাকে, তখন সমস্যাটি আরও মারাত্মক হয়ে ওঠে। কারণ এই অবস্থায় ব্যবহারকারীর কুকি, সেশন টোকেন এবং অথেনটিকেশন তথ্য ক্রস-অরিজিন রিকোয়েস্টের সাথে পাঠানো হয়।

একটি সাধারণ ভুল হলো Access-Control-Allow-Origin: * সেট করা এবং একই সাথে credentials অনুমোদন করা। যদিও আধুনিক ব্রাউজারগুলো এই কম্বিনেশন এখন ব্লক করে দেয়, তবুও অনেক পুরনো বা ভুলভাবে লেখা সার্ভার-সাইড কোড এই সমস্যা তৈরি করে। আরেকটি জটিল ত্রুটি হলো রিকোয়েস্টের Origin হেডার সরাসরি প্রতিফলিত করা। সার্ভার যদি প্রতিটি ইনকামিং অরিজিনকে যাচাই না করেই ফিরিয়ে দেয়, তাহলে যেকোনো ডোমেইন থেকে আসা রিকোয়েস্ট বৈধ হিসেবে গ্রহণ করা হয়।

আরও একটি প্রচলিত সমস্যা হলো null অরিজিন গ্রহণ করা। যখন সার্ভার Access-Control-Allow-Origin: null অনুমোদন করে, তখন আক্রমণকারী Sandbox iframe বা ডেটা URI ব্যবহার করে null অরিজিন তৈরি করতে পারে এবং সহজেই বাইপাস করতে পারে। এই ধরনের কনফিগারেশন বিশেষত পুরনো লিগ্যাসি সিস্টেমে দেখা যায় যেখানে ডেভেলপাররা CORS-এর জটিলতা সম্পর্কে পুরোপুরি অবগত ছিলেন না।

আক্রমণকারীরা CORS Misconfiguration খোঁজার সময় বেশ কিছু সাধারণ প্যাটার্ন অনুসরণ করেন। প্রথম এবং সবচেয়ে সহজ প্যাটার্ন হলো Wildcard অরিজিন। যদি কোনো API ক্রেডেনশিয়াল-সমর্থিত রিকোয়েস্টে wildcard ব্যবহার করে, তাহলে সেটি সরাসরি শোষণযোগ্য। দ্বিতীয় প্যাটার্ন হলো Origin Reflection যেখানে সার্ভার কোনো যাচাই ছাড়াই ক্লায়েন্টের পাঠানো Origin হেডার রেসপন্সে ফিরিয়ে দেয়। এই ক্ষেত্রে evil.com থেকে আসা রিকোয়েস্ট evil.com হিসেবে অনুমোদিত হয়ে যায়।

তৃতীয় প্যাটার্ন হলো অসম্পূর্ণ Regex Validation। অনেক ডেভেলপার সাবডোমেইন যাচাইয়ের জন্য রেগুলার এক্সপ্রেশন ব্যবহার করেন কিন্তু এটি ভুলভাবে লিখলে আক্রমণকারী evil-bank.com বা bank.com.evil.com-এর মতো ডোমেইন ব্যবহার করে বাইপাস করতে পারেন। উদাহরণস্বরূপ, যদি যাচাইকরণ শুধুমাত্র bank.com সাবস্ট্রিং খোঁজে, তাহলে অনেক ম্যালিশাস ডোমেইন বৈধ হিসেবে গৃহীত হবে।

চতুর্থ প্যাটার্ন হলো Trusted Subdomain Compromise। যখন একটি প্রধান ডোমেইনের কোনো সাবডোমেইন কম্প্রোমাইজ হয় বা সেখানে XSS ত্রুটি থাকে, তখন CORS-এর মাধ্যমে অন্য সাবডোমেইনগুলোর ডেটা চুরি করা সম্ভব হয়ে পড়ে। এজন্য Trusted Origin-এর তালিকায় থাকা প্রতিটি ডোমেইনের নিরাপত্তা সমান গুরুত্বপূর্ণ।

পঞ্চম প্যাটার্ন হলো Protocol Confusion। কিছু সার্ভার HTTPS অরিজিনের পাশাপাশি HTTP অরিজিনকেও অনুমোদন করে যা ম্যান-ইন-দ্য-মিডল আক্রমণের ঝুঁকি তৈরি করে। আধুনিক অ্যাপ্লিকেশনে শুধুমাত্র HTTPS অরিজিন গ্রহণ করা উচিত এবং অন্য সব প্রটোকল কঠোরভাবে প্রত্যাখ্যান করা উচিত।

ধরা যাক একটি ই-কমার্স প্ল্যাটফর্মের API endpoint https://api.shop.com/user/profile ব্যবহারকারীর ব্যক্তিগত তথ্য, ঠিকানা এবং কেনাকাটার ইতিহাস ফিরিয়ে দেয়। যদি এই endpoint Origin Reflection-এর সমস্যায় ভুগে এবং credentials অনুমোদন করে, তাহলে একজন আক্রমণকারী attacker.com নামে একটি ফিশিং সাইট তৈরি করতে পারে। যখন একজন বৈধ ব্যবহারকারী লগইন অবস্থায় এই ম্যালিশাস সাইটে প্রবেশ করেন, তখন ব্যাকগ্রাউন্ডে JavaScript চলে যা api.shop.com-এ ক্রস-অরিজিন রিকোয়েস্ট পাঠায়।

এই রিকোয়েস্টের সাথে ব্যবহারকারীর সেশন কুকি স্বয়ংক্রিয়ভাবে যুক্ত হয়, এবং সার্ভার যেহেতু Origin হেডার প্রতিফলিত করে, তাই রেসপন্স সফলভাবে পড়া যায়। ফলস্বরূপ, আক্রমণকারী ব্যবহারকারীর সমস্ত প্রোফাইল তথ্য একটি বহিরাগত সার্ভারে পাঠিয়ে দিতে পারেন। ব্যবহারকারী কখনো বুঝতেই পারেন না যে তার ডেটা চুরি হয়েছে।

আরেকটি বাস্তব উদাহরণ হলো অভ্যন্তরীণ অ্যাডমিন প্যানেল। অনেক প্রতিষ্ঠানের অভ্যন্তরীণ ড্যাশবোর্ড থাকে যা শুধুমাত্র কর্পোরেট নেটওয়ার্ক থেকে অ্যাক্সেসযোগ্য। যদি এই অ্যাডমিন প্যানেলের API CORS-এর মাধ্যমে যেকোনো অরিজিনকে অনুমতি দেয় এবং কোনো কর্মচারী লগইন অবস্থায় ম্যালিশাস ওয়েবসাইট ভিজিট করেন, তাহলে আক্রমণকারী সেই অ্যাডমিন সেশন ব্যবহার করে সংবেদনশীল ব্যবসায়িক ডেটা চুরি করতে পারেন।

বাস্তব জগতে কয়েকটি বড় কোম্পানির CORS Misconfiguration থেকে লক্ষ লক্ষ ডলারের ক্ষতি হয়েছে। বিশেষ করে ক্রিপ্টোকারেন্সি এক্সচেঞ্জ, ব্যাংকিং অ্যাপ্লিকেশন এবং SaaS প্ল্যাটফর্মে এই দুর্বলতা সবচেয়ে বেশি ক্ষতিকর হয়ে দাঁড়ায়। বাগ বাউন্টি প্রোগ্রামগুলোতে CORS Misconfiguration একটি জনপ্রিয় রিপোর্টিং ক্যাটাগরি, এবং বড় প্রতিষ্ঠানগুলো এই ধরনের রিপোর্টের জন্য হাজার হাজার ডলার পুরস্কার দিয়ে থাকে।

CORS Misconfiguration শনাক্ত করার জন্য পেনিট্রেশন টেস্টাররা পদ্ধতিগতভাবে কাজ করেন। প্রথম ধাপে তারা টার্গেট অ্যাপ্লিকেশনের সমস্ত API endpoint চিহ্নিত করেন এবং প্রতিটিতে বিভিন্ন Origin হেডার দিয়ে রিকোয়েস্ট পাঠান। উদাহরণস্বরূপ, একটি বৈধ অরিজিন, একটি সম্পূর্ণ ভিন্ন অরিজিন, null অরিজিন এবং সাবডোমেইন ভেরিয়েশন পরীক্ষা করা হয়।

দ্বিতীয় ধাপে রেসপন্স হেডার বিশ্লেষণ করা হয়। বিশেষত Access-Control-Allow-Origin এবং Access-Control-Allow-Credentials হেডার পর্যবেক্ষণ করে বোঝা যায় সার্ভার কীভাবে CORS পরিচালনা করে। যদি সার্ভার সব ক্ষেত্রে অরিজিন প্রতিফলিত করে এবং credentials অনুমোদন করে, তাহলে সেটি একটি শোষণযোগ্য দুর্বলতা।

তৃতীয় ধাপে Proof of Concept বা PoC তৈরি করা হয়। এটি সাধারণত একটি HTML পেজ যা JavaScript ব্যবহার করে টার্গেট API-তে রিকোয়েস্ট পাঠায় এবং রেসপন্স দেখায়। Burp Suite, OWASP ZAP এবং বিশেষায়িত টুল যেমন CORScanner বা Corsy এই ধরনের টেস্টিংয়ে ব্যাপকভাবে ব্যবহৃত হয়।

চতুর্থ ধাপে ব্যবসায়িক প্রভাব মূল্যায়ন করা হয়। প্রতিটি দুর্বলতার তীব্রতা নির্ভর করে কোন ধরনের ডেটা প্রকাশিত হচ্ছে তার উপর। ব্যক্তিগত তথ্য, আর্থিক ডেটা, অথেনটিকেশন টোকেন বা প্রশাসনিক ক্ষমতা প্রকাশিত হলে দুর্বলতা Critical হিসেবে শ্রেণিবদ্ধ হয়।

CORS Misconfiguration প্রতিরোধের জন্য কয়েকটি মূল নীতি অনুসরণ করা অপরিহার্য। সর্বপ্রথম, অনুমোদিত অরিজিনের একটি কঠোর Whitelist বজায় রাখুন। কখনোই Origin হেডার সরাসরি প্রতিফলিত করবেন না। প্রতিটি ইনকামিং Origin-কে একটি পূর্বনির্ধারিত তালিকার বিরুদ্ধে কঠোরভাবে যাচাই করুন এবং শুধুমাত্র মিল পেলেই অনুমোদন দিন।

দ্বিতীয়ত, যদি আপনার অ্যাপ্লিকেশনে credentials প্রয়োজন না হয়, তাহলে Access-Control-Allow-Credentials কখনোই true সেট করবেন না। অনেক সময় ডেভেলপাররা প্রয়োজন ছাড়াই এটি সক্রিয় রাখেন যা ঝুঁকি বৃদ্ধি করে। যদি credentials প্রয়োজন হয়, তাহলে অরিজিন তালিকা আরও কঠোর হতে হবে এবং wildcard কখনোই ব্যবহার করা যাবে না।

তৃতীয়ত, null অরিজিন কখনোই অনুমোদন করবেন না। এটি একটি বিপজ্জনক অভ্যাস যা সহজেই বাইপাসযোগ্য। চতুর্থত, সাবডোমেইন-ভিত্তিক ভ্যালিডেশনে সাবধানতা অবলম্বন করুন। শুধুমাত্র সম্পূর্ণ ডোমেইন নাম মিলিয়ে দেখুন, সাবস্ট্রিং বা পার্শিয়াল ম্যাচিং ব্যবহার করবেন না। রেগুলার এক্সপ্রেশন ব্যবহার করলে সেটি অত্যন্ত সতর্কতার সাথে লিখুন এবং পরীক্ষা করুন।

পঞ্চমত, সংবেদনশীল API endpoint-গুলোর জন্য অতিরিক্ত নিরাপত্তা স্তর যোগ করুন। যেমন CSRF token, custom হেডার যাচাইকরণ, এবং multi-factor অথেনটিকেশন। CORS শুধুমাত্র একটি ব্রাউজার-ভিত্তিক নিরাপত্তা স্তর; এটি সম্পূর্ণ নিরাপত্তা ব্যবস্থা নয়।

ষষ্ঠত, নিয়মিত নিরাপত্তা অডিট এবং স্বয়ংক্রিয় স্ক্যানিং চালু রাখুন। CI/CD পাইপলাইনে CORS কনফিগারেশন যাচাইয়ের জন্য টেস্ট যুক্ত করুন যাতে নতুন কোড ডিপ্লয় হওয়ার আগেই সম্ভাব্য সমস্যা ধরা পড়ে। সপ্তমত, ডেভেলপারদের জন্য নিয়মিত নিরাপত্তা প্রশিক্ষণের ব্যবস্থা করুন। অনেক CORS ত্রুটি ঘটে কেবল প্রটোকল সম্পর্কে অপর্যাপ্ত জ্ঞানের কারণে।

বর্তমান সময়ে Node.js, Django, Spring Boot, ASP.NET-এর মতো ফ্রেমওয়ার্কগুলোতে CORS-এর জন্য বিল্ট-ইন লাইব্রেরি রয়েছে। তবে এই লাইব্রেরিগুলো সঠিকভাবে কনফিগার করা ডেভেলপারের দায়িত্ব। উদাহরণস্বরূপ, Express.js-এর cors মিডলওয়্যার ব্যবহার করার সময় অরিজিনের জন্য একটি ফাংশন প্রদান করা ভালো যা ডায়নামিকভাবে যাচাই করে।

Spring Security-তে CorsConfiguration ক্লাস ব্যবহার করে কনফিগারেশন তৈরি করার সময় allowedOrigins-এর জন্য কখনোই * ব্যবহার করবেন না বিশেষত যখন credentials সক্রিয় থাকে। Django-তে django-cors-headers প্যাকেজ ব্যবহার করার সময় CORS_ALLOWED_ORIGINS সেটিংয়ে শুধুমাত্র বিশ্বস্ত ডোমেইনগুলো যুক্ত করুন।

Cloudflare, AWS API Gateway-এর মতো এজ সার্ভিস ব্যবহার করলে সেখানে CORS পলিসি কেন্দ্রীভূতভাবে নিয়ন্ত্রণ করা সম্ভব। এটি একদিকে ব্যবস্থাপনা সহজ করে অন্যদিকে নিরাপত্তা নীতির ধারাবাহিকতা নিশ্চিত করে। তবে এই ধরনের সেটআপে অরিজিন সার্ভার এবং এজ লেয়ারের মধ্যে কনফিগারেশন কনফ্লিক্ট এড়াতে সতর্ক থাকতে হবে।