Go CSRF / XSRF টোকেনের উদ্দেশ্য এবং ফর্ম সুরক্ষা এবং স্ট্যান্ডার্ড প্যাকেজের ডিফল্ট টোকেনের মেয়াদ

নমস্কার, আমি অযোগ্য।
আমি ব্যক্তিগতভাবে তৈরি করেছি এবং ব্যক্তিগতভাবে ব্যবহার করছি এমন একটি অনলাইন স্টোরেজ
GitHub - haturatu/puremania: No security, very fast, web UI self-hosted online storage
আছে, কিন্তু যদি আপনি এর সামনে প্রমাণীকরণ যোগ করতে চান, তাহলে আমি একটি প্রমাণীকরণ প্রক্সি তৈরি করেছি।
GitHub - haturatu/auth-proxy: An authentication proxy server and frontend for a website without built-in authentication. JavaScript is supported, but it can also work without JS if using PHP-FPM. The backend is written in Go.
আসলে, এটি প্রায় পুরোটাই জেমিনি-কুন-এর কারণে।
শুধুমাত্র যেগুলি প্রমাণীকরণ পাস করে সেগুলিকে প্রক্সি করা হবে।
অ্যাডমিন ব্যবহারকারীরা API এন্ডপয়েন্টের জন্য Bearer টোকেন ইস্যু করতে পারে এবং সেই টোকেন ব্যবহার করে অনুরোধগুলি পাস করা যেতে পারে। তবে, এই ক্ষেত্রে এমন API এন্ডপয়েন্টও রয়েছে যেখানে ফ্রন্টএন্ড থেকে সেশন ব্যবহার করে অ্যাক্সেস করতে হবে, তাই বাস্তবে কুকি বা Bearer টোকেন উভয়ই কাজ করবে।
যদি শুধুমাত্র API এন্ডপয়েন্টগুলি সুরক্ষিত করতে হয়, তাহলে ওয়েব লগইন-এর মতো ফ্রন্টএন্ডগুলিকে একটি ব্যক্তিগত নেটওয়ার্কে বিচ্ছিন্ন করে এবং শুধুমাত্র API এন্ডপয়েন্টগুলিকে প্রকাশ করে, ব্যবহারকারী তৈরি ব্যক্তিগত নেটওয়ার্ক থেকে করা যেতে পারে এবং সেই ব্যবহারকারীকে ব্যবহার করে API টোকেন ইস্যু করা এবং API প্রক্সি ব্যবহার করা কার্যত সম্ভব। (দয়া করে বলবেন না যে 'API গেটওয়ে-ভিত্তিক OSS ব্যবহার করলেই তো হয়!')
বাস্তবে, এটি কুকি এবং টোকেন উভয় ব্যবহার করে ডাবল ব্রুট-ফোর্স আক্রমণকে কার্যত সম্ভব করে তোলে, তবে, ঠিক আছে...

সুতরাং, লগইন করার সময় ওয়েব ফ্রন্টএন্ডের নিরাপত্তার জন্য ফর্ম সুরক্ষার বিষয়ে আরেকটি বিষয়।
যদি JS লোড করা বাধ্যতামূলক করা হয়, তাহলে বেশিরভাগ সমস্যা সমাধান করা যায়, কিন্তু শুধুমাত্র JS-এর উপর নির্ভর করা কি বিরক্তিকর নয়? তাই, আমি JS ছাড়া অন্য উপায়ে ফর্মের নিরাপত্তা বাড়ানোর সিদ্ধান্ত নিয়েছি।

CSRF / XSRF টোকেন

এটিই এইবারের মূল বিষয়, তবে এটি আসলে কী?

সহজ কথায়, এটি নিশ্চিত করে যে সার্ভার এবং ক্লায়েন্টের অনুরোধ আমার কাছ থেকে অ্যাক্সেস করা হয়েছে এবং ইস্যু করা হয়েছে, এবং যদি টোকেনটি বৈধতার মধ্যে থাকে তবে অনুমতি দেওয়া হয়।
উদাহরণস্বরূপ

<input type="hidden" name="xsrf_token" value="BeftikzaR8Oe6npnqXYC7WtBhuo:1760376550660">

এই ধরনের একটি টোকেন ফ্রন্টএন্ড HTML-এ এম্বেড করা হয়। এই value সার্ভারের গোপন কী দ্বারা স্বাক্ষরিত। সুতরাং সার্ভার বুঝতে পারে যে এটি আমার সার্ভার থেকে ইস্যু করা হয়েছে!
1760376550660 হল শুধুমাত্র UNIX সময় সহ অক্ষরের একটি স্ট্রিং, তবে বর্তমান সময়ের জন্য এটি কীসের জন্য প্রয়োজন?
xsrftoken package - golang.org/x/net/xsrftoken - Go Packages

func ValidFor(token, key, userID, actionID string, timeout time.Duration) bool

এটি উপরের মেয়াদ নির্ধারণের জন্য ব্যবহৃত হয়।

বাস্তবে, time প্যাকেজ সহ এটি দেখতে এরকম হবে:

if !xsrftoken.ValidFor(clientToken, string(xsrfSecret), sessionID, r.URL.Path, 15*time.Minute) {

যদি এই আর্গুমেন্টটি না দেওয়া হয়, তাহলে ডিফল্ট 24 ঘন্টা, যা বেশ শিথিল, তবে, আমি মনে করি এটি XSRF Token-এর আসল ফর্ম হিসাবে সরবরাহ করা হয়েছে, যেখানে শুধুমাত্র সার্ভার দ্বারা ইস্যু করা টোকেনটি যাচাই করা যথেষ্ট।

CSRF এবং XSRF এর মধ্যে পার্থক্য কী?!

বাস্তবে, খুব বেশি পার্থক্য নেই বলে মনে হয়।
উদ্দেশ্য হল ক্রস-সাইট আক্রমণ প্রতিরোধ করা।

CSRF এর ক্ষেত্রে
GitHub - gorilla/csrf: Package gorilla/csrf provides Cross Site Request Forgery (CSRF) prevention middleware for Go web applications & services 🔒
এই লাইব্রেরিটি ছিল, এবং আমি ঘটনাক্রমে এটি এখানে দেখেছি।
gorilla/csrf CSRF দুর্বলতা ডেমো

gorilla/csrf এর বাস্তবায়ন উন্নত করার একটি উপায় হল ফর্মে ব্যবহৃত র্যান্ডম মানগুলিকে ব্যবহারকারীর ID-এর সাথে সংযুক্ত এনক্রিপ্ট করা টোকেন দিয়ে প্রতিস্থাপন করা। এটি আক্রমণকারীদের তাদের নিজস্ব CSRF টোকেন এবং কুকি মানগুলিকে লক্ষ্যবস্তুর সাথে প্রতিস্থাপন করা থেকে বিরত রাখে। কারণ আক্রমণকারীর CSRF টোকেন একটি ভিন্ন ID-এর সাথে মিলে যায়। আসলে, এই পদ্ধতিটি x/net/xsrftokenHMAC ব্যবহার করে ব্যবহারকারীর ID, ঐচ্ছিক ফর্ম অ্যাকশন এবং মেয়াদ যাচাই করার জন্য একটি লাইব্রেরিতে বাস্তবায়িত হয়েছে।

তখন আমি ভাবলাম যে এটি একটি স্ট্যান্ডার্ড লাইব্রেরি,
xsrftoken/xsrf.go
সোর্স কোড দেখে আমি অবাক হয়ে গেলাম, মন্তব্য সহও মাত্র 100 লাইন! SHA1 এখনও ব্যবহার করা হচ্ছে দেখে কিছুটা চিন্তিত, তবে এটি কি ভবিষ্যতে আপগ্রেড হবে?
সুতরাং, যদি স্ট্যান্ডার্ড লাইব্রেরি এত সহজ হয়, তাহলে আমাদের উদ্দেশ্য এর মাধ্যমেই পূরণ হয়, এবং যদি SameSite যাচাই করতে হয়, তাহলে gorilla/csrf ব্যবহার করা উচিত, তাই না?

স্ট্যান্ডার্ড লাইব্রেরির সতর্কতা

আমি আগেই উল্লেখ করেছি যে ডিফল্ট টোকেনের মেয়াদ 24H।
বাস্তব প্রয়োগে, এই টোকেনের মেয়াদ অপব্যবহারের সম্ভাবনা বাড়াতে পারে, তাই এটি আরও কম করা যেতে পারে। ধারণা করা হয় যে, যদি এই টোকেনটি ফর্ম পূরণ করার জন্য অনুরোধ পাঠানোর উদ্দেশ্যে হয়, তাহলে 24H মেয়াদ একই টোকেন ব্যবহার করে বারবার অনুরোধ পাঠাতে দেয় যদি অন্য কোনো নিরাপত্তা ব্যবস্থা না থাকে, তাই অসীম curl ব্যবহার করে একই টোকেন বারবার ব্যবহার করে ফর্মে অনুরোধ পাঠিয়ে ব্রুট-ফোর্স আক্রমণ করা অসম্ভব নয়।