ভাবুন আপনার একটি সরলিকৃত টুইটারের মতো একটি ওয়েবসাইট রয়েছে, এটি একটি ডটকম এ হোস্ট করা হয়েছে। সাইন ইন ব্যবহারকারীরা একটি ফর্মের মধ্যে কিছু পাঠ্য (একটি টুইট) প্রবেশ করতে পারেন যা পোষ্ট অনুরোধ হিসাবে সার্ভারে প্রেরণ করা হয় এবং তারা সাবমিট বোতামটি চাপলে প্রকাশিত হয়। সার্ভারে ব্যবহারকারীকে তাদের অনন্য সেশন আইডিযুক্ত একটি কুকি দ্বারা চিহ্নিত করা হয়, সুতরাং আপনার সার্ভারটি কে পোস্ট করেছে তা জানেন।
ফর্মটি এতটা সহজ হতে পারে:
<form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>
এখন কল্পনা করুন, কোনও খারাপ লোক তার দূষিত ওয়েবসাইটে এই ফর্মটি অনুলিপি করে আটকে দিয়েছে, আসুন বি.কম. ফর্মটি এখনও কাজ করবে। যতক্ষণ না কোনও ব্যবহারকারী আপনার টুইটারে সাইন ইন থাকে (যেমন তারা a.com এর জন্য একটি বৈধ সেশন কুকি পেয়েছে), http://a.com/tweetব্যবহারকারী যখন সাবমিট বাটনে ক্লিক করেন তখন পোষ্ট অনুরোধটি যথারীতি প্রেরণ করা হবে
এবং প্রক্রিয়া করা হবে।
এখন পর্যন্ত এটি কোনও বড় সমস্যা নয় যতক্ষণ না ব্যবহারকারী ফর্মটি ঠিক কী করে তা সম্পর্কে সচেতন করা হবে, তবে আমাদের খারাপ লোক যদি ফর্মটিকে এইভাবে টুইট করে:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>
এখন, যদি আপনার কোনও ব্যবহারকারী খারাপ লোকের ওয়েবসাইটে গিয়ে শেষ করে এবং "জয়ের জন্য ক্লিক করুন!" বোতামটি, ফর্মটি আপনার ওয়েবসাইটে জমা দেওয়া হয়েছে, ব্যবহারকারী সঠিকভাবে কুকির সেশন আইডি দ্বারা চিহ্নিত করা হবে এবং লুকানো টুইট প্রকাশিত হবে।
যদি আমাদের খারাপ লোকটি আরও খারাপ হয়, তবে তিনি নিখরচায় ব্যবহারকারীদের জাভাস্ক্রিপ্ট ব্যবহার করে তার ওয়েব পৃষ্ঠাটি খোলার সাথে সাথে এই ফর্মটি জমা দিতে বাধ্য করবেন, এমনকি কোনও অদৃশ্য আইফ্রেমে সম্পূর্ণ লুকিয়ে রেখেছিলেন। এটি মূলত ক্রস-সাইট অনুরোধ জালিয়াতি।
একটি ফর্ম সহজেই সর্বত্র থেকে সর্বত্র জমা দেওয়া যেতে পারে। সাধারণত এটি একটি সাধারণ বৈশিষ্ট্য, তবে এমন আরও অনেকগুলি ক্ষেত্রে রয়েছে যেখানে কেবলমাত্র কোনও ফর্ম যেখানে এটির মালিকানাধীন সেখানে জমা দেওয়ার অনুমতি দেওয়া গুরুত্বপূর্ণ।
যদি আপনার ওয়েব অ্যাপ্লিকেশনটি POST এবং GET অনুরোধগুলির মধ্যে পার্থক্য না করে তবে পরিস্থিতি আরও খারাপ হয় (যেমন পিএইচপিতে $ _POST এর পরিবর্তে _RE $QQUEST ব্যবহার করে)। যে না! <img src="http://a.com/tweet?tweet=This+is+really+bad">দূষিত ওয়েবসাইট বা এমনকি একটি ইমেল এম্বেড করা , ডেটা পরিবর্তনের অনুরোধগুলি এত সহজে জমা দেওয়া যেতে পারে ।
আমি কীভাবে নিশ্চিত করব যে কোনও ফর্ম কেবলমাত্র আমার নিজের ওয়েবসাইট থেকে জমা দেওয়া যেতে পারে? এখানেই সিএসআরএফ টোকেন আসে A একটি সিএসআরএফ টোকেন একটি এলোমেলো, হার্ড-টু-অনুমানের স্ট্রিং। আপনি যে ফর্মটি সুরক্ষিত করতে চান সেই পৃষ্ঠায় সার্ভারটি একটি এলোমেলো স্ট্রিং তৈরি করবে, সিএসআরএফ টোকেন, এটি একটি লুকানো ক্ষেত্র হিসাবে ফর্মটিতে যুক্ত করবে এবং এটি কোনওভাবে মনে রাখবে, হয় এটি সেশনে সংরক্ষণ করে বা কুকি সেট করে either মানযুক্ত এখন ফর্মটি দেখতে এমন হবে:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>
যখন ব্যবহারকারী ফর্মটি জমা দেয়, সার্ভারকে কেবলমাত্র সিএসআরএফ-টোকেন (নামটির কোনও গুরুত্ব নেই) সার্ভারের দ্বারা স্মরণ করা সিএসআরএফ টোকেনের সাথে তুলনা করতে হবে। উভয় স্ট্রিং সমান হলে, সার্ভারটি ফর্মটি প্রক্রিয়া চালিয়ে যেতে পারে। অন্যথায় সার্ভারটি অবিলম্বে ফর্মটি প্রক্রিয়াকরণ বন্ধ করে একটি ত্রুটির সাথে প্রতিক্রিয়া জানাবে।
কেন এই কাজ করে? উপরের আমাদের উদাহরণ থেকে খারাপ লোকটি সিএসআরএফ টোকেন গ্রহণ করতে অক্ষম হওয়ার বিভিন্ন কারণ রয়েছে:
স্ট্যাটিক সোর্স কোডটি আমাদের পৃষ্ঠা থেকে অন্য কোনও ওয়েবসাইটে অনুলিপি করা অকেজো হবে, কারণ প্রতিটি ব্যবহারকারীর সাথে লুকানো ক্ষেত্রের মান পরিবর্তিত হয়। খারাপ ব্যবহারকারীর ওয়েবসাইট ছাড়া বর্তমান ব্যবহারকারীর সিএসআরএফ টোকেন না জেনে আপনার সার্ভার সর্বদা পোস্টের অনুরোধটিকে প্রত্যাখ্যান করবে।
যেহেতু খারাপ লোকটির দূষিত পৃষ্ঠাটি আপনার ব্যবহারকারীর ব্রাউজার দ্বারা একটি অন্য ডোমেন (a.com এর পরিবর্তে b.com) থেকে লোড করা হয়েছে, খারাপ লোকটির জাভা স্ক্রিপ্ট কোড করার কোনও সুযোগ নেই, যা সামগ্রীটি লোড করে এবং তাই আমাদের ব্যবহারকারীর বর্তমান সিএসআরএফ টোকেন থেকে আপনার ওয়েবসাইট. এর কারণ ওয়েব ব্রাউজারগুলি ডিফল্টরূপে ক্রস-ডোমেন এজেএক্স অনুরোধগুলিকে অনুমতি দেয় না।
খারাপ লোকটি আপনার সার্ভার দ্বারা সেট করা কুকি অ্যাক্সেস করতে অক্ষম, কারণ ডোমেনগুলি মেলে না।
আমি কখন ক্রস-সাইট অনুরোধ জালিয়াতির বিরুদ্ধে রক্ষা করব? আপনি যদি নিশ্চিত করতে পারেন যে আপনি উপরে বর্ণিত হিসাবে জিইটি, পোষ্ট এবং অন্যান্য অনুরোধ পদ্ধতিগুলি মিশ্রিত না করে থাকেন তবে ডিফল্টরূপে সমস্ত পোষ্ট অনুরোধ রক্ষা করা একটি ভাল শুরু।
আপনাকে পুট এবং মুছে ফেলার অনুরোধগুলি রক্ষা করতে হবে না, কারণ উপরে বর্ণিত হিসাবে, এই পদ্ধতিগুলি ব্যবহার করে কোনও মানক এইচটিএমএল ফর্ম কোনও ব্রাউজার দ্বারা জমা দেওয়া যায় না।
অন্যদিকে জাভাস্ক্রিপ্ট প্রকৃতপক্ষে অন্যান্য ধরণের অনুরোধ করতে পারে, যেমন jQuery এর aj .জ্যাক্স () ফাংশনটি ব্যবহার করে, তবে মনে রাখবেন, অ্যাজ্যাক্সের জন্য ডোমেনগুলি কাজ করার অনুরোধগুলি অবশ্যই মিলবে (যতক্ষণ না আপনি স্পষ্টভাবে আপনার ওয়েব সার্ভারটি কনফিগার না করেন) ।
এর অর্থ, প্রায়শই আপনাকে এজেএক্স অনুরোধগুলিতে সিএসআরএফ টোকেন যুক্ত করতে হবে না, এমনকি তারা পোষ্ট অনুরোধগুলি হলেও, আপনাকে অবশ্যই নিশ্চিত করতে হবে যে আপনি কেবলমাত্র আপনার ওয়েব অ্যাপ্লিকেশনটিতে সিএসআরএফ চেককে বাইপাস করবেন যদি পোষ্ট অনুরোধটি আসলে একটি হয় AJAX অনুরোধ। আপনি এক্স-রিকুয়েস্টড-উইথের মতো শিরোনামের উপস্থিতি সন্ধান করে এটি করতে পারেন, যা এজেএক্স অনুরোধগুলিতে সাধারণত অন্তর্ভুক্ত থাকে। আপনি অন্য কাস্টম শিরোনাম সেট করতে এবং সার্ভারের পাশে এটির উপস্থিতি পরীক্ষা করতে পারেন। এটি নিরাপদ, কারণ কোনও ব্রাউজার কোনও নিয়মিত এইচটিএমএল ফর্ম জমা দেওয়ার জন্য কাস্টম শিরোনাম যুক্ত করে না (উপরে দেখুন), তাই মিঃ বাড গাইয়ের কোনও ফর্মের সাথে এই আচরণটি অনুকরণ করার কোনও সুযোগ নেই।
যদি আপনার এজেএক্স অনুরোধ সম্পর্কে সন্দেহ হয়, কারণ কোনও কারণে আপনি এক্স-রিকুয়েস্টড-উইথের মতো শিরোনামটি চেক করতে পারবেন না, কেবল আপনার জাভাস্ক্রিপ্টে উত্পন্ন সিএসআরএফ টোকনটি পাস করুন এবং অ্যাজাক্স অনুরোধে টোকন যুক্ত করুন। এই কাজ করার বিভিন্ন উপায় আছে; হয় কোনও নিয়মিত এইচটিএমএল ফর্মের মতো পেডলোডে এটিকে যুক্ত করুন বা এজেএক্স অনুরোধে একটি কাস্টম শিরোনাম যুক্ত করুন। যতক্ষণ না আপনার সার্ভারটি এটি আসবে এমন কোনও অনুরোধে কোথায় এটি সন্ধান করতে হবে এবং সেশন বা কুকি থেকে স্মরণ করা মূল মানের সাথে এটি তুলনা করতে সক্ষম হবে ততক্ষণ আপনি বাছাই করেছেন।