বিশ্বব্যাপী ডেভেলপারদের জন্য Next.js অ্যাপ্লিকেশনে ক্রস-সাইট স্ক্রিপ্টিং (XSS) এবং ক্রস-সাইট রিকোয়েস্ট ফোরজারি (CSRF) আক্রমণ প্রতিরোধে শক্তিশালী নিরাপত্তা ব্যবস্থা বাস্তবায়নের একটি বিস্তারিত নির্দেশিকা।
Next.js নিরাপত্তা: XSS এবং CSRF আক্রমণের বিরুদ্ধে আপনার অ্যাপ্লিকেশনকে শক্তিশালী করা
আজকের আন্তঃসংযুক্ত ডিজিটাল বিশ্বে, ওয়েব অ্যাপ্লিকেশনের নিরাপত্তা সবচেয়ে গুরুত্বপূর্ণ। Next.js-এর মতো ফ্রেমওয়ার্ক ব্যবহার করে আধুনিক এবং ডাইনামিক ইউজার এক্সপেরিয়েন্স তৈরি করার সময় ডেভেলপারদের তাদের অ্যাপ্লিকেশন এবং ব্যবহারকারীর ডেটাকে অসংখ্য হুমকি থেকে রক্ষা করার একটি গুরুতর দায়িত্ব পালন করতে হয়। এর মধ্যে সবচেয়ে প্রচলিত এবং ক্ষতিকারক হলো ক্রস-সাইট স্ক্রিপ্টিং (XSS) এবং ক্রস-সাইট রিকোয়েস্ট ফোরজারি (CSRF) আক্রমণ। এই বিস্তারিত নির্দেশিকাটি বিশ্বব্যাপী ডেভেলপারদের জন্য ডিজাইন করা হয়েছে, যা Next.js অ্যাপ্লিকেশনগুলোকে এই ব্যাপক দুর্বলতা থেকে কার্যকরভাবে সুরক্ষিত করার জন্য ব্যবহারিক কৌশল এবং অন্তর্দৃষ্টি প্রদান করে।
হুমকিগুলো বোঝা: XSS এবং CSRF
প্রতিরোধ কৌশল নিয়ে আলোচনা করার আগে, এই আক্রমণগুলির প্রকৃতি বোঝা অত্যন্ত গুরুত্বপূর্ণ।
ক্রস-সাইট স্ক্রিপ্টিং (XSS) ব্যাখ্যা
ক্রস-সাইট স্ক্রিপ্টিং (XSS) আক্রমণ তখন ঘটে যখন একজন আক্রমণকারী অন্য ব্যবহারকারীদের দ্বারা দেখা ওয়েব পেজগুলিতে ক্ষতিকারক স্ক্রিপ্ট, সাধারণত জাভাস্ক্রিপ্টের আকারে, প্রবেশ করায়। এই স্ক্রিপ্টগুলি তখন ব্যবহারকারীর ব্রাউজারে চলতে পারে, যা সম্ভাব্যভাবে সেশন কুকি, লগইন তথ্যর মতো সংবেদনশীল তথ্য চুরি করতে পারে বা ব্যবহারকারীর অজান্তে বা সম্মতি ছাড়াই তার পক্ষে বিভিন্ন কাজ করতে পারে। XSS আক্রমণ একটি ওয়েবসাইটে ব্যবহারকারীর আস্থার অপব্যবহার করে, কারণ ক্ষতিকারক স্ক্রিপ্টটি একটি বৈধ উৎস থেকে এসেছে বলে মনে হয়।
XSS-এর তিনটি প্রধান প্রকার রয়েছে:
- Stored XSS (Persistent XSS): ক্ষতিকারক স্ক্রিপ্টটি স্থায়ীভাবে টার্গেট সার্ভারে সংরক্ষণ করা হয়, যেমন একটি ডাটাবেস, মেসেজ ফোরাম বা মন্তব্য ক্ষেত্রে। যখন একজন ব্যবহারকারী প্রভাবিত পৃষ্ঠাটি অ্যাক্সেস করেন, তখন স্ক্রিপ্টটি তার ব্রাউজারে পাঠানো হয়।
- Reflected XSS (Non-Persistent XSS): ক্ষতিকারক স্ক্রিপ্টটি একটি URL বা ওয়েব সার্ভারে ইনপুট হিসাবে পাঠানো অন্য ডেটাতে এমবেড করা হয়। সার্ভার তখন এই স্ক্রিপ্টটি ব্যবহারকারীর ব্রাউজারে প্রতিফলিত করে, যেখানে এটি কার্যকর হয়। এতে প্রায়শই সোশ্যাল ইঞ্জিনিয়ারিং জড়িত থাকে, যেখানে আক্রমণকারী শিকারকে একটি ক্ষতিকারক লিঙ্কে ক্লিক করতে প্ররোচিত করে।
- DOM-based XSS: এই ধরনের XSS তখন ঘটে যখন একটি ওয়েবসাইটের ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট কোড অনিরাপদ উপায়ে ডকুমেন্ট অবজেক্ট মডেল (DOM) পরিবর্তন করে, যার ফলে আক্রমণকারীরা এমন ক্ষতিকারক কোড প্রবেশ করাতে পারে যা ব্যবহারকারীর ব্রাউজারে কার্যকর হয় এবং সার্ভার পেলোড প্রতিফলিত করার সাথে জড়িত নাও থাকতে পারে।
ক্রস-সাইট রিকোয়েস্ট ফোরজারি (CSRF) ব্যাখ্যা
ক্রস-সাইট রিকোয়েস্ট ফোরজারি (CSRF) আক্রমণ একজন প্রমাণীকৃত ব্যবহারকারীর ব্রাউজারকে এমন একটি ওয়েব অ্যাপ্লিকেশনে অনিচ্ছাকৃত, ক্ষতিকারক অনুরোধ পাঠাতে প্ররোচিত করে যেখানে সে বর্তমানে লগ ইন করা আছে। আক্রমণকারী একটি ক্ষতিকারক ওয়েবসাইট, ইমেল বা অন্য কোনো বার্তা তৈরি করে যেখানে একটি লিঙ্ক বা স্ক্রিপ্ট থাকে যা টার্গেট অ্যাপ্লিকেশনে একটি অনুরোধ ট্রিগার করে। যদি ব্যবহারকারী টার্গেট অ্যাপ্লিকেশনে প্রমাণীকৃত থাকা অবস্থায় লিঙ্কটিতে ক্লিক করে বা ক্ষতিকারক সামগ্রী লোড করে, তবে তার স্পষ্ট সম্মতি ছাড়াই তার পক্ষে জাল অনুরোধটি কার্যকর করা হয়। এর মধ্যে তার পাসওয়ার্ড পরিবর্তন করা, কেনাকাটা করা বা তহবিল স্থানান্তর করা অন্তর্ভুক্ত থাকতে পারে।
CSRF আক্রমণ একটি ওয়েব অ্যাপ্লিকেশনের ব্যবহারকারীর ব্রাউজারের উপর থাকা আস্থার অপব্যবহার করে। যেহেতু ব্রাউজার স্বয়ংক্রিয়ভাবে প্রতিটি অনুরোধের সাথে প্রমাণীকরণের শংসাপত্র (যেমন সেশন কুকি) অন্তর্ভুক্ত করে, অ্যাপ্লিকেশনটি ব্যবহারকারীর কাছ থেকে আসা বৈধ অনুরোধ এবং আক্রমণকারীর কাছ থেকে আসা জাল অনুরোধের মধ্যে পার্থক্য করতে পারে না।
Next.js-এর অন্তর্নির্মিত নিরাপত্তা বৈশিষ্ট্য
Next.js, একটি শক্তিশালী React ফ্রেমওয়ার্ক হওয়ায়, জাভাস্ক্রিপ্ট ইকোসিস্টেমে উপলব্ধ অনেক অন্তর্নিহিত নিরাপত্তা নীতি এবং সরঞ্জাম ব্যবহার করে। যদিও Next.js আপনার অ্যাপ্লিকেশনকে জাদুকরীভাবে XSS এবং CSRF থেকে মুক্ত করে না, তবে এটি একটি শক্তিশালী ভিত্তি এবং সরঞ্জাম সরবরাহ করে যা সঠিকভাবে ব্যবহার করা হলে, আপনার নিরাপত্তা অবস্থাকে উল্লেখযোগ্যভাবে উন্নত করে।
সার্ভার-সাইড রেন্ডারিং (SSR) এবং স্ট্যাটিক সাইট জেনারেশন (SSG)
Next.js-এর SSR এবং SSG ক্ষমতা স্বাভাবিকভাবেই নির্দিষ্ট ধরনের XSS-এর জন্য আক্রমণের পৃষ্ঠকে কমাতে পারে। সার্ভারে বা বিল্ড টাইমে কন্টেন্ট প্রি-রেন্ডার করে, ফ্রেমওয়ার্ক ক্লায়েন্টে পৌঁছানোর আগে ডেটা স্যানিটাইজ করতে পারে। এটি ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টকে এমনভাবে ম্যানিপুলেট করার সুযোগ কমিয়ে দেয় যা XSS-এর দিকে নিয়ে যেতে পারে।
নিয়ন্ত্রিত ডেটা হ্যান্ডলিংয়ের জন্য API রুট
Next.js API রুট আপনাকে আপনার Next.js প্রকল্পের মধ্যে সার্ভারলেস ব্যাকএন্ড ফাংশন তৈরি করার সুযোগ দেয়। এটি শক্তিশালী নিরাপত্তা ব্যবস্থা বাস্তবায়নের জন্য একটি গুরুত্বপূর্ণ ক্ষেত্র, কারণ প্রায়শই এখানেই ডেটা গ্রহণ, প্রক্রিয়া এবং পাঠানো হয়। আপনার ব্যাকএন্ড লজিককে API রুটে কেন্দ্রীভূত করার মাধ্যমে, আপনি ডেটা আপনার ফ্রন্ট-এন্ড বা ডাটাবেসের সাথে ইন্টারঅ্যাক্ট করার আগে নিরাপত্তা পরীক্ষা প্রয়োগ করতে পারেন।
Next.js-এ XSS প্রতিরোধ
Next.js-এ XSS দুর্বলতা প্রশমিত করার জন্য ইনপুট ভ্যালিডেশন, আউটপুট এনকোডিং এবং ফ্রেমওয়ার্কের বৈশিষ্ট্যগুলিকে কার্যকরভাবে ব্যবহারের উপর দৃষ্টি নিবদ্ধ করে একটি বহু-স্তরীয় পদ্ধতির প্রয়োজন।
১. ইনপুট ভ্যালিডেশন: কোনো ইনপুটকে বিশ্বাস করবেন না
নিরাপত্তার স্বর্ণসূত্র হলো ব্যবহারকারীর ইনপুটকে কখনও বিশ্বাস না করা। এই নীতিটি যেকোনো উৎস থেকে আসা ডেটার ক্ষেত্রে প্রযোজ্য: ফর্ম, URL প্যারামিটার, কুকি বা এমনকি তৃতীয় পক্ষের API থেকে আনা ডেটা। Next.js অ্যাপ্লিকেশনগুলির উচিত সমস্ত ইনকামিং ডেটা কঠোরভাবে যাচাই করা।
API রুট সহ সার্ভার-সাইড ভ্যালিডেশন
API রুট হলো সার্ভার-সাইড ভ্যালিডেশনের জন্য আপনার প্রাথমিক প্রতিরক্ষা ব্যবস্থা। ফর্ম বা API অনুরোধের মাধ্যমে জমা দেওয়া ডেটা পরিচালনা করার সময়, এটি প্রক্রিয়া বা সংরক্ষণ করার আগে সার্ভারে ডেটা যাচাই করুন।
উদাহরণ: একটি API রুটে ব্যবহারকারীর নাম যাচাই করা।
// pages/api/register.js
import { NextApiRequest, NextApiResponse } from 'next';
export default function handler(req: NextApiRequest, res: NextApiResponse) {
if (req.method === 'POST') {
const { username, email } = req.body;
// Basic validation: Check if username is not empty and alphanumeric
const usernameRegex = /^[a-zA-Z0-9_]+$/;
if (!username || !usernameRegex.test(username)) {
return res.status(400).json({ message: 'Invalid username. Only alphanumeric characters and underscores are allowed.' });
}
// Further validation for email, password, etc.
// If valid, proceed to database operation
res.status(200).json({ message: 'User registered successfully!' });
} else {
res.setHeader('Allow', ['POST']);
res.status(405).end(`Method ${req.method} Not Allowed`);
}
}
Joi, Yup, বা Zod-এর মতো লাইব্রেরিগুলি জটিল ভ্যালিডেশন স্কিমা সংজ্ঞায়িত করার জন্য অমূল্য হতে পারে, যা ডেটার অখণ্ডতা নিশ্চিত করে এবং ইনজেকশন প্রচেষ্টা প্রতিরোধ করে।
ক্লায়েন্ট-সাইড ভ্যালিডেশন (UX-এর জন্য, নিরাপত্তার জন্য নয়)
যদিও ক্লায়েন্ট-সাইড ভ্যালিডেশন তাৎক্ষণিক প্রতিক্রিয়া দিয়ে একটি ভালো ব্যবহারকারীর অভিজ্ঞতা প্রদান করে, এটি কখনই একমাত্র নিরাপত্তা ব্যবস্থা হওয়া উচিত নয়। আক্রমণকারীরা সহজেই ক্লায়েন্ট-সাইড পরীক্ষা এড়িয়ে যেতে পারে।
২. আউটপুট এনকোডিং: প্রদর্শনের আগে ডেটা স্যানিটাইজ করা
কঠোর ইনপুট ভ্যালিডেশনের পরেও, HTML-এ ডেটা রেন্ডার করার আগে তা এনকোড করা অপরিহার্য। এই প্রক্রিয়াটি সম্ভাব্য ক্ষতিকারক অক্ষরগুলিকে তাদের নিরাপদ, এস্কেপড সমতুল্য অক্ষরে রূপান্তর করে, যা ব্রাউজার দ্বারা এক্সিকিউটেবল কোড হিসাবে ব্যাখ্যা হওয়া থেকে বিরত রাখে।
React-এর ডিফল্ট আচরণ এবং JSX
React, ডিফল্টরূপে, JSX-এর মধ্যে স্ট্রিং রেন্ডার করার সময় স্বয়ংক্রিয়ভাবে এস্কেপ করে। এর মানে হলো, যদি আপনি <script>
-এর মতো HTML ট্যাগ সম্বলিত একটি স্ট্রিং রেন্ডার করেন, তবে React এটিকে কার্যকর করার পরিবর্তে আক্ষরিক পাঠ্য হিসাবে রেন্ডার করবে।
উদাহরণ: React দ্বারা স্বয়ংক্রিয় XSS প্রতিরোধ।
function UserComment({ comment }) {
return (
User Comment:
{comment}
{/* React automatically escapes this string */}
);
}
// If comment = '', it will render as literal text.
`dangerouslySetInnerHTML`-এর বিপদ
React dangerouslySetInnerHTML
নামে একটি প্রপ সরবরাহ করে, যা এমন পরিস্থিতিতে ব্যবহৃত হয় যেখানে আপনাকে অবশ্যই র' HTML রেন্ডার করতে হবে। এই প্রপটি অত্যন্ত সতর্কতার সাথে ব্যবহার করা উচিত, কারণ এটি React-এর স্বয়ংক্রিয় এস্কেপিংকে বাইপাস করে এবং যদি আগে থেকে সঠিকভাবে স্যানিটাইজ না করা হয় তবে XSS দুর্বলতা তৈরি করতে পারে।
উদাহরণ: dangerouslySetInnerHTML-এর ঝুঁকিপূর্ণ ব্যবহার।
function RawHtmlDisplay({ htmlContent }) {
return (
// WARNING: If htmlContent contains malicious scripts, XSS will occur.
);
}
// To safely use this, htmlContent MUST be sanitized server-side before being passed here.
যদি আপনাকে অবশ্যই dangerouslySetInnerHTML
ব্যবহার করতে হয়, তবে নিশ্চিত করুন যে htmlContent
সার্ভার-সাইডে একটি নির্ভরযোগ্য স্যানিটাইজেশন লাইব্রেরি যেমন DOMPurify ব্যবহার করে পুঙ্খানুপুঙ্খভাবে স্যানিটাইজ করা হয়েছে।
সার্ভার-সাইড রেন্ডারিং (SSR) এবং স্যানিটাইজেশন
যখন সার্ভার-সাইডে ডেটা আনা হয় (যেমন, getServerSideProps
বা getStaticProps
-এ) এবং কম্পোনেন্টে পাস করা হয়, তখন নিশ্চিত করুন যে এটি রেন্ডার করার আগে স্যানিটাইজ করা হয়েছে, বিশেষ করে যদি এটি dangerouslySetInnerHTML
-এর সাথে ব্যবহার করা হবে।
উদাহরণ: সার্ভার-সাইডে আনা ডেটা স্যানিটাইজ করা।
// pages/posts/[id].js
import DOMPurify from 'dompurify';
export async function getServerSideProps(context) {
const postId = context.params.id;
// Assume fetchPostData returns data including potentially unsafe HTML
const postData = await fetchPostData(postId);
// Sanitize the potentially unsafe HTML content server-side
const sanitizedContent = DOMPurify.sanitize(postData.content);
return {
props: {
post: { ...postData, content: sanitizedContent },
},
};
}
function Post({ post }) {
return (
{post.title}
{/* Safely render potentially HTML content */}
);
}
export default Post;
৩. কনটেন্ট সিকিউরিটি পলিসি (CSP)
একটি কনটেন্ট সিকিউরিটি পলিসি (CSP) হলো একটি অতিরিক্ত নিরাপত্তা স্তর যা XSS সহ নির্দিষ্ট ধরনের আক্রমণ সনাক্ত এবং প্রশমিত করতে সহায়তা করে। CSP আপনাকে সেই সমস্ত রিসোর্স (স্ক্রিপ্ট, স্টাইলশীট, ছবি ইত্যাদি) নিয়ন্ত্রণ করার ক্ষমতা দেয় যা ব্রাউজার একটি নির্দিষ্ট পৃষ্ঠার জন্য লোড করতে পারে। একটি কঠোর CSP সংজ্ঞায়িত করার মাধ্যমে, আপনি অননুমোদিত স্ক্রিপ্টগুলির সম্পাদন প্রতিরোধ করতে পারেন।
আপনি আপনার Next.js সার্ভার কনফিগারেশনের মাধ্যমে বা আপনার API রুটের মধ্যে CSP হেডার সেট করতে পারেন।
উদাহরণ: next.config.js
-এ CSP হেডার সেট করা।
// next.config.js
module.exports = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'Content-Security-Policy',
// Example: Allow scripts only from same origin and a trusted CDN
// 'unsafe-inline' and 'unsafe-eval' should be avoided if possible.
value: "default-src 'self'; script-src 'self' 'unsafe-eval' https://cdn.example.com; object-src 'none'; base-uri 'self';"
},
{
key: 'X-Content-Type-Options',
value: 'nosniff'
},
{
key: 'X-Frame-Options',
value: 'DENY'
}
],
},
];
},
};
XSS প্রতিরোধের জন্য মূল CSP নির্দেশাবলী:
script-src
: জাভাস্ক্রিপ্টের জন্য অনুমোদিত উৎস নিয়ন্ত্রণ করে।'self'
বা'*'
-এর পরিবর্তে নির্দিষ্ট উৎস ব্যবহার করুন। সম্ভব হলে'unsafe-inline'
এবং'unsafe-eval'
এড়িয়ে চলুন, ইনলাইন স্ক্রিপ্ট এবং মডিউলের জন্য নন্স বা হ্যাশ ব্যবহার করে।object-src 'none'
: Flash-এর মতো সম্ভাব্য ঝুঁকিপূর্ণ প্লাগইনগুলির ব্যবহার প্রতিরোধ করে।base-uri 'self'
: একটি ডকুমেন্টের<base>
ট্যাগে নির্দিষ্ট করা যেতে পারে এমন URL গুলিকে সীমাবদ্ধ করে।form-action 'self'
: ফর্মের জন্য জমা দেওয়ার টার্গেট হিসাবে ব্যবহার করা যেতে পারে এমন ডোমেনগুলিকে সীমাবদ্ধ করে।
৪. স্যানিটাইজেশন লাইব্রেরি
শক্তিশালী XSS প্রতিরোধের জন্য, বিশেষ করে ব্যবহারকারী-সৃষ্ট HTML সামগ্রী নিয়ে কাজ করার সময়, সু-রক্ষণাবেক্ষণ করা স্যানিটাইজেশন লাইব্রেরির উপর নির্ভর করুন।
- DOMPurify: একটি জনপ্রিয় জাভাস্ক্রিপ্ট স্যানিটাইজেশন লাইব্রেরি যা HTML স্যানিটাইজ করে এবং XSS আক্রমণ প্রতিরোধ করে। এটি ব্রাউজারে ব্যবহারের জন্য ডিজাইন করা হয়েছে এবং Node.js-এর সাথে সার্ভার-সাইডেও ব্যবহার করা যেতে পারে (যেমন, Next.js API রুটে)।
- xss (npm প্যাকেজ): HTML স্যানিটাইজ করার জন্য আরেকটি শক্তিশালী লাইব্রেরি, যা নির্দিষ্ট ট্যাগ এবং অ্যাট্রিবিউট হোয়াইটলিস্ট বা ব্ল্যাকলিস্ট করার জন্য ব্যাপক কনফিগারেশনের অনুমতি দেয়।
সর্বদা আপনার অ্যাপ্লিকেশনের প্রয়োজনের উপর ভিত্তি করে উপযুক্ত নিয়ম দিয়ে এই লাইব্রেরিগুলি কনফিগার করুন, সর্বনিম্ন বিশেষাধিকারের নীতিকে লক্ষ্য রেখে।
Next.js-এ CSRF প্রতিরোধ
CSRF আক্রমণ সাধারণত টোকেন ব্যবহার করে প্রশমিত করা হয়। Next.js অ্যাপ্লিকেশনগুলি স্টেট-চেঞ্জিং অনুরোধগুলির জন্য অনন্য, অপ্রত্যাশিত টোকেন তৈরি এবং যাচাই করে CSRF সুরক্ষা বাস্তবায়ন করতে পারে।
১. সিঙ্ক্রোনাইজার টোকেন প্যাটার্ন
CSRF সুরক্ষার জন্য সবচেয়ে সাধারণ এবং কার্যকর পদ্ধতি হলো সিঙ্ক্রোনাইজার টোকেন প্যাটার্ন। এর মধ্যে রয়েছে:
- টোকেন জেনারেশন: যখন একজন ব্যবহারকারী একটি ফর্ম বা পৃষ্ঠা লোড করে যা স্টেট-চেঞ্জিং অপারেশন সম্পাদন করে, সার্ভার একটি অনন্য, গোপন এবং অপ্রত্যাশিত টোকেন (CSRF টোকেন) তৈরি করে।
- টোকেন অন্তর্ভুক্তি: এই টোকেনটি ফর্মের মধ্যে একটি লুকানো ইনপুট ফিল্ড হিসাবে এমবেড করা হয় বা পৃষ্ঠার জাভাস্ক্রিপ্ট ডেটাতে অন্তর্ভুক্ত করা হয়।
- টোকেন ভ্যালিডেশন: যখন ফর্ম জমা দেওয়া হয় বা একটি স্টেট-চেঞ্জিং API অনুরোধ করা হয়, সার্ভার যাচাই করে যে জমা দেওয়া টোকেনটি তার তৈরি করা এবং সংরক্ষণ করা টোকেনের সাথে মেলে (যেমন, ব্যবহারকারীর সেশনে)।
যেহেতু একজন আক্রমণকারী ব্যবহারকারীর সেশনের বিষয়বস্তু বা একটি পৃষ্ঠার HTML পড়তে পারে না যেখানে সে প্রমাণীকৃত নয়, তাই সে তার জাল অনুরোধে অন্তর্ভুক্ত করার জন্য বৈধ CSRF টোকেন পেতে পারে না। অতএব, জাল অনুরোধটি ভ্যালিডেশনে ব্যর্থ হবে।
Next.js-এ CSRF সুরক্ষা বাস্তবায়ন
Next.js-এ সিঙ্ক্রোনাইজার টোকেন প্যাটার্ন বাস্তবায়ন বিভিন্ন পদ্ধতির মাধ্যমে করা যেতে পারে। একটি সাধারণ পদ্ধতিতে সেশন ম্যানেজমেন্ট ব্যবহার করা এবং API রুটের মধ্যে টোকেন জেনারেশন এবং ভ্যালিডেশন একীভূত করা জড়িত।
একটি সেশন ম্যানেজমেন্ট লাইব্রেরি ব্যবহার করে (যেমন, `next-session` বা `next-auth`)
next-session
(সহজ সেশন ম্যানেজমেন্টের জন্য) বা next-auth
(প্রমাণীকরণ এবং সেশন ম্যানেজমেন্টের জন্য) এর মতো লাইব্রেরিগুলি CSRF টোকেন হ্যান্ডলিংকে ব্যাপকভাবে সহজ করতে পারে। এই লাইব্রেরিগুলির মধ্যে অনেকেরই বিল্ট-ইন CSRF সুরক্ষা ব্যবস্থা রয়েছে।
next-session
ব্যবহার করে উদাহরণ (ধারণাগত):
প্রথমে লাইব্রেরিটি ইনস্টল করুন:
npm install next-session crypto
তারপর, আপনার API রুটে বা একটি কাস্টম সার্ভারে একটি সেশন মিডলওয়্যার সেট আপ করুন:
// middleware.js (for API routes)
import { withSession } from 'next-session';
import { v4 as uuidv4 } from 'uuid'; // For generating tokens
export const sessionOptions = {
password: process.env.SESSION_COOKIE_PASSWORD,
cookie: {
secure: process.env.NODE_ENV === 'production',
httpOnly: true,
sameSite: 'lax',
maxAge: 60 * 60 * 24, // 1 day
},
};
export const csrfProtection = async (req, res, next) => {
if (!req.session.csrfToken) {
req.session.csrfToken = uuidv4(); // Generate token and store in session
}
// For GET requests to fetch the token
if (req.method === 'GET' && req.url === '/api/csrf') {
return res.status(200).json({ csrfToken: req.session.csrfToken });
}
// For POST, PUT, DELETE requests, validate token
if (['POST', 'PUT', 'DELETE'].includes(req.method)) {
const submittedToken = req.body.csrfToken || req.headers['x-csrf-token'];
if (!submittedToken || submittedToken !== req.session.csrfToken) {
return res.status(403).json({ message: 'Invalid CSRF token' });
}
}
// If it's a POST, PUT, DELETE and token is valid, regenerate token for next request
if (['POST', 'PUT', 'DELETE'].includes(req.method) && submittedToken === req.session.csrfToken) {
req.session.csrfToken = uuidv4(); // Regenerate token after successful operation
}
await next(); // Continue to the next middleware or route handler
};
// Combine with session middleware
export default withSession(csrfProtection, sessionOptions);
আপনি তখন এই মিডলওয়্যারটি আপনার API রুটে প্রয়োগ করবেন যা স্টেট-চেঞ্জিং অপারেশনগুলি পরিচালনা করে।
ম্যানুয়াল CSRF টোকেন বাস্তবায়ন
যদি একটি ডেডিকেটেড সেশন লাইব্রেরি ব্যবহার না করেন, তাহলে আপনি ম্যানুয়ালি CSRF সুরক্ষা বাস্তবায়ন করতে পারেন:
- সার্ভার-সাইডে টোকেন তৈরি করুন:
getServerSideProps
বা একটি API রুটে যা আপনার মূল পৃষ্ঠা পরিবেশন করে, একটি CSRF টোকেন তৈরি করুন এবং এটি একটি প্রপ হিসাবে পাস করুন। এই টোকেনটি ব্যবহারকারীর সেশনে (যদি আপনার সেশন ম্যানেজমেন্ট সেট আপ থাকে) বা একটি কুকিতে নিরাপদে সংরক্ষণ করুন। - UI-তে টোকেন এমবেড করুন: আপনার HTML ফর্মগুলিতে টোকেনটিকে একটি লুকানো ইনপুট ফিল্ড হিসাবে অন্তর্ভুক্ত করুন বা এটি একটি গ্লোবাল জাভাস্ক্রিপ্ট ভেরিয়েবলে উপলব্ধ করুন।
- অনুরোধের সাথে টোকেন পাঠান: AJAX অনুরোধের জন্য (যেমন,
fetch
বা Axios ব্যবহার করে), অনুরোধের হেডারে (যেমন,X-CSRF-Token
) বা অনুরোধের বডির অংশ হিসাবে CSRF টোকেন অন্তর্ভুক্ত করুন। - সার্ভার-সাইডে টোকেন যাচাই করুন: আপনার API রুটে যা স্টেট-চেঞ্জিং অ্যাকশনগুলি পরিচালনা করে, অনুরোধ থেকে টোকেনটি পুনরুদ্ধার করুন (হেডার বা বডি) এবং ব্যবহারকারীর সেশনে সংরক্ষিত টোকেনের সাথে তুলনা করুন।
একটি ফর্মে এমবেড করার উদাহরণ:
function MyForm({ csrfToken }) {
return (
);
}
// In getServerSideProps or getStaticProps, fetch csrfToken from session and pass it.
fetch-এর সাথে পাঠানোর উদাহরণ:
asyn