সিরিজের পার্ট वन, ইনজেকশন অ্যাটাক কভার করেছিলো

OWASP Top 10 Web Application Security Risks সম্পর্কে আমাদের সিরিজের দ্বিতীয় আর্টিকেলে, আমরা ব্রোকেন অথেন্টিকেশন এবং ডেটা এক্সপোজার হুমকির বিশ্বে ডুব করব।

আরো স্পেসিফিকভাবে, আমরা বলব কীভাবে সহজে একজন হ্যাকার আপনার তৈরি কোডকে ঠগাতে পারে এবং আক্রমণ চালাতে পারে ইউজারদের ডেটা পেতে:

• ইউজার এনুমারেশন: যখন তারা আপনার লগইন পেজ এক্সপ্লয়িট করে ব্রুট-ফোর্স টেস্টিং করে সম্ভাব্য ইউজার লিস্ট দিয়ে শুধু চেক করতে যে সেগুলো আপনার ডেটাবেসে একজিস্ট করে কিনা।
• উইক পাসওয়ার্ড: যখন আপনার সিস্টেম উইক পাসওয়ার্ড অ্যালো করে, হ্যাকাররা ব্রুট ফোর্স অ্যাটাক চালাতে পারে আপনার ইউজারদের পাসওয়ার্ড حدস করতে।
• আনরিস্ট্রিক্টেড কুকি: যখন আপনার সিস্টেম সেনসিটিভ ডেটা কুকিতে সংরক্ষণ করে প্রপার সিকিউরিটি সেটিংস ছাড়া, হ্যাকাররা XSS অ্যাটাকের মাধ্যমে ইনফরমেশন চুরি করতে পারে।

আমরা সেনসিটিভ ডেটা সম্পর্কেও ডিটেইলে যাব যেগুলো পর্যাপ্তভাবে প্রটেক্টেড নয়, যা জায়গা করে ভালনারেবিলিটির জন্য, যেমন নিচের موارد:

• আনসেফ সেনসিটিভ স্টোরেজ: যখন সেনসিটিভ ডেটা উইক অ্যালগরিদম যেমন MD5 দিয়ে এনক্রিপ্ট করা হয়।
• সেনসিটিভ ডেটা এক্সপোজ করা: যখন ডেভেলপাররা অনিচ্ছাকৃতভাবে আনক্রিপ্টেড সেনসিটিভ ডেটা URL বা হিডেন ফিল্ডে এক্সপোজ করে, উদাহরণস্বরূপ।

সিরিজের প্রথম আর্টিকেলের মত, আমরা RailsGoat ব্যবহার করব প্রতিটি হুমকি প্র্যাকটিসে এক্সপ্লোর করতে। আপনি যদি নতুন হন, পূর্বের আর্টিকেল রেফার করুন অ্যাপ সেট আপ ও রান করতে।

চলুন সরাসরি যাই!

অথেন্টিকেশন হুমকি

আমরা অথেন্টিকেশনের বিনা নিই নয়। চাহে আপনার ব্যাক-এন্ড API-তে হোক বা ফ্রন্ট-এন্ড ফর্মের ভেতরে, এটা অ্যাপ্লিকেশন ডেভেলপমেন্টের সবচেয়ে গুরুত্বপূর্ণ স্টেপের একটা কারণ এটি আপনার সিকিউরিটি মেজার্সের বর্ডার লিমিট হাইলাইট করে।

শুধু অথেন্টিকেশনের জন্য নয়, বরং যা আসে তারপর: সেশন ম্যানেজমেন্ট। আপনি আপনার পাসওয়ার্ড এবং টোকেন কোথায় স্টোর করবেন? সেগুলো প্রপারলি এনক্রিপ্টেড কিনা? আপনি একটি বিশ্বস্ত অ্যালগরিদম ব্যবহার করছেন কিনা? আপনার পাসওয়ার্ড পর্যাপ্ত জটিল কিনা?

খেয়াল রাখার অনেক প্রশ্ন আছে। সেগুলো একটু ব্রেক ডাউন করি এবং রেইলস অ্যাপ্লিকেশনে অথেন্টিকেশন এবং সেশন ম্যানেজমেন্ট নিয়ে কিছু সাধারণ অ্যাটাক বুঝি।

ইউজার এনুমারেশন

ইউজার এনুমারেশন একটি বিখ্যাত টেকনিক যা আক্রমণকারী ব্যবহার করে চেক করতে (ব্রুট ফোর্সের মাধ্যমে) প্রদত্ত ডেটা আপনার সিস্টেমে একজিস্ট করে কিনা।

এই অ্যাটাকের সবচেয়ে কুখ্যাত উদাহরণ হচ্ছে বর্তমান Facebook লগইন পেজ। আপনি যদি কিছু ইনভ্যালিড এবং র‍্যান্ডম ক্রেডেনশিয়াল দেন নিচের ইমেজের মতো, Facebook রিকোয়েস্ট প্রসেস করবে এবং চেক করবে ইউজার তাদের ডেটাবেসে একজিস্ট করে কিনা।

Facebook-এর লগইন পেজ।

যখন আপনি Log In বাটনে ক্লিক করবেন, Facebook একটি এরর মেসেজ রিটার্ন করবে যে আপনার ইউজারনেম (যা হতে পারে ইমেইল বা ফোন নম্বর) ভ্যালিড নয়।

ইনভ্যালিড ইউজারনেম মেসেজ।

তাই, আক্রমণকারী জানতে পারবে অ্যাপ্লিকেশন আপনাকে বলে দিচ্ছে কোন ইউজার রেজিস্টার্ড। ফ্রি-তে।

যদি আক্রমণকারীর কাছে ইমেইল লিস্ট থাকে (চाहে র‍্যান্ডমলি জেনারেট করা হোক বা কোথাও থেকে কিনে), সেটিও পাসওয়ার্ড সঠিক কিনা চেক করতে অ্যাপ্লিকেশনে আস্ক করা সম্ভব:

ইনভ্যালিড পাসওয়ার্ড মেসেজ।

একবার আক্রমণকারী জানলে সিস্টেম প্রতিটি ভ্যালিডেশন আলাদা আলাদা কীভাবে রেসপন্ড করে, একটি লিস্ট তৈরি করা যায় possible users এবং কমন/উইক পাসওয়ার্ড। ব্রুট-ফোর্স টেস্টগুলো আবার আবার সিস্টেমের বিপক্ষে চালানো যায় যতক্ষণ না অ্যাক্সেস পাওয়া যায়।

অবশ্যই, Facebook ডেভেলপাররা এই বিষয়ে জানেন, এবং এইीलেই তারা অডিশনাল প্রোটেকশন বাস্তবায়ন করেছে, যেমন ইনভিজিবল ক্যাপচা এবং একটি নির্দিষ্ট IP এড্রেস থেকে আসা রিকোয়েস্টের সংখ্যা ওভার ভ্যালিডেশন।

ইউজার এনুমারেশন এড়াতে আপনি যা একটা করতে পারেন সেটি হলো ইউজারনেম এবং পাসওয়ার্ড দুটো একসাথে ভ্যালিডেট করা এবং একটি জেনেরিক মেসেজ রিটার্ন করা। চলুন এই অ্যাপ্রোচ একশনে দেখি!

হুমকি একশনে

RailsGoat অ্যাপে, app/models ফোল্ডারের user.rb ফাইল খুলুন এবং authenticate মেথড লোকেট করুন। তার ভেতরে, আপনি নিচের কোড স্নিপেট পেতে পারেন:

raise "#{email} doesn't exist!" if !(user) if user.password == Digest::MD5.hexdigest(password) auth = user else raise "Incorrect Password!" end 

ঠিকই! মেসেজগুলো এমনভাবে সেট করা হয়েছে যাতে আক্রমণকারী জানতে পারে ইউজার একজিস্ট করে না বা পাসওয়ার্ড ইনকরেক্ট।

টেস্ট করুন। RailsGoat লগইন পেজে যান এবং একটি র‍্যান্ডম ইমেইল এবং পাসওয়ার্ড টাইপ করুন। আপনি নিচের এরর মেসেজ দেখতে পারেন:

ইউজার একজিস্ট করে না।

অন্যথায়, যদি ইউজার একজিস্ট করে (ken@metacorp.com, উদাহরণস্বরূপ) কিন্তু পাসওয়ার্ড ভুল হয়, নিচের মেসেজ ডিসপ্লে হয়:

ইনকরেক্ট পাসওয়ার্ড।

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

এই ইস্যু রিজলভ কীভাবে

সেটাকে সেফার করার সবচেয়ে কুইক একশন আপনি নিতে পারেন সেটি হলো আপনার মেসেজ চেঞ্জ করা এবং হ্যাকারের জীবন জটিল করা।

sessions_controller.rb (app/controllers ফোল্ডার) খুলুন এবং create মেথড লোকেট করুন এবং নিচের কোড স্নিপেট চেঞ্জ করুন

flash[:error] = e.message 

নিচেরটিতে:

flash[:error] = "Your credentials aren't valid." 

এখন, প্রতিবার ইউজাররা ভুল ইউজারনেম বা পাসওয়ার্ড টাইপ করলে, সেটি মেসেজ তারা পাবে:

ইনভ্যালিড ক্রেডেনশিয়াল।

এটা করার আরেকটা উপায় হচ্ছে users.rb মডেলের ভেতরে দুটি মেসেজ চেঞ্জ করা।

উইক পাসওয়ার্ড

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

এটি ইউজার এনুমারেশন প্রতিরোধের সবচেয়ে গুরুত্বপূর্ণ স্টেপের একটা।

হুমকি একশনে

RailsGoat-এ, user.rb ফাইল খুলুন এবং ক্লাস ডেফিনিশনের ঠিক আগের প্রথম লাইন কোড লোকেট করুন:

validates :password, presence: true, confirmation: true, length: { within: 6..40 }, ... 

এটি পাসওয়ার্ড উইকলি ভ্যালিডেট হওয়ার একটি স্পষ্ট উদাহরণ যেহেতু শুধু এর লেংথ চেক করা হয়।

এই ইস্যু রিজলভ কীভাবে

সমাধানটা খুব সিম্পল; আপনার পাসওয়ার্ড কিছু স্ট্রง রিকোয়ারমেন্টের বিপক্ষে ভ্যালিডেট করুন, যেমন নিচেরগুলো:

• কমপক্ষে ১টি লোয়ারকেস এবং ১টি আপারকেস লেটার,
• কমপক্ষে ১টি ডিজিট,
• কমপক্ষে ১০ ক্যারেক্টার।

আপনি যত বেশি রিকোয়ারমেন্ট যোগ করবেন, আপনার পাসওয়ার্ড তত সেফ হবে। শুধু নিশ্চিত করুন খুব বেশি পুশ করবেন না যেন ইউজেবিলিটি এবং পাসওয়ার্ড রিকভারি ফ্লোতে কমপ্লেক্সিটি বেড়ে না যায়।

RailsGoat-এ এটি সমাধান করতে, সিম্পলি length প্রোপার্টি সাবস্টিটিউট করুন নিচের দিয়ে:

:format => {:with => /\A.*(?=.*[a-zA-Z])(?=.*[0-9])(?=.{10,}).*\z/}, 

তারপর, সাইন-আপ পেজে যান, ফিল্ডগুলো ফিল করুন, এবং একটি উইক পাসওয়ার্ড প্রদান করুন। সাবমিট করলে, এটি এরর মেসেজ ডিসপ্লে হবে:

পাসওয়ার্ড ইনভ্যালিড।

আনরিস্ট্রিক্টেড কুকি

পূর্বের আর্টিকেলে, আমরা কিছু সময় দিয়েছিলাম XSS অ্যাটাক কীভাবে ঘটে সেটি বুঝতে। যেহেতু সেগুলো ঘটে আক্রমণকারীকে ম্যালিশিয়াস স্ক্রিপ্ট রান করার অনুমতি দিয়ে, সেশন কুকি থেকে গুরুত্বপূর্ণ ইনফরমেশন চুরি করা যায় যদি আমরা `document.cookie` আপনার জাভাস্ক্রিপ্ট কোডে অ্যাক্সেস প্রিভেন্ট না করি।

মনে রাখবেন Web storage vs. cookies এর ডিসপিউট প্রায় কমিউনিটিতে ডিসকাস হয়। Web storage যদি বেশি প্র্যাক্টিক্যাল, একজন আক্রমণকারী সেটির ফুল অ্যাক্সেস পেতে পারে প্রপার প্রোটেকশন XSS হুমকি থেকে ছাড়া।

কুকি, অন্যদিকে, একটু সেফার যদি আপনি সঠিক স্টেপস নেন সেগুলো সেফ করতে, যেমন HttpOnly ফ্ল্যাগ সেট করা।

সংক্ষেপে, একটি কুকি যেটি সেশন ইনফরমেশন ধারণ করে এবং HttpOnly ফ্ল্যাগ দিয়ে সেট করা হয়, সেটি অ্যাক্সেস করা যাবে না জাভাস্ক্রিপ্ট Document.cookie API থেকে। এইভাবে, শুধু সার্ভারই সেটি রিসিভ করবে।

বিকল্পভাবে, আমাদের Secure অ্যাট্রিবিউটও আছে, যেটি নিশ্চিত করবে একটি কুকি শুধু সার্ভারে পাঠানো হবে যদি (এবং শুধু যদি) রিকোয়েস্ট HTTPS-এ হয় (কখনো HTTP-এ নয়)। এটি আপনার রিকোয়েস্ট সেফার করবে কেউ স্নিফ করলে man-in-the-middle হিসেবে।

হুমকি একশনে

Rails আপনার জন্য একটি স্টেপ নেয় স্বয়ংক্রিয়ভাবে সকল কুকি HttpOnly ফ্ল্যাগ দিয়ে সেট করে। এটি দারুণ কারণ এটি অনজান ডেভেলপারদের তাদের অ্যাপ হ্যাক হওয়া থেকে বাঁচায়।

এই উদাহরণ টেস্ট করতে, আমাদের এই ফিচার ডিজেবল করতে হবে, যা RailsGoat স্পষ্টভাবে করেছে session_store.rb ফাইলে, যেটি অবস্থিত config/initializers ফোল্ডারে। চেক আউট করুন!

তারপর, রেজিস্ট্রেশন পেজে আবার যান, ফিল্ডগুলো প্রপারলি ফিল করুন, এবং Name ফিল্ডে নিচের কন্টেন্ট ইনপুট করুন:

<script> alert(document.cookie); </script> 

যখন আপনি ফর্ম সাবমিট করবেন, ইউজার তৈরি হবে, সাথে নিচের সাবসিকোয়েন্ট এলার্ট মেসেজ:

RailsGoat সেশন কুকি এক্সপোজ করে এলার্ট মেসেজ।

এই ইস্যু রিজলভ কীভাবে

এই কেসে, এটা বেশ স্ট্রেটফরওয়ার্ড, শুধু নিশ্চিত করুন আপনার রেইলস অ্যাপে HttpOnly ফ্ল্যাগ ডিজেবল করবেন না।

তাই, httponly: false সেটিং রিমুভ করুন এবং সার্ভার রিস্টার্ট করুন। যখন আপনি একই অপারেশন পারফর্ম করার চেষ্টা করবেন, নিচের এলার্ট মেসেজ ডিসপ্লে হবে:

খালি এলার্ট মেসেজ।

অন্য সিনেরিও

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

সিম্পলি একটি ব্রাউজার ট্যাব বন্ধ করা একটি অ্যাপ্লিকেশন থেকে লগ আউট করার জন্য পর্যাপ্ত নয়।

ডেভেলপারদের কোডের মধ্যে একটি অন্য কমন ইস্যু হলো যখন আপনি যেকোনো ধরনের ID ফ্রন্ট এন্ডে এক্সপোজ করেন। সেটি কঠিন নয় এমন সিনেরিও চিন্তা করা যেখানে একটি ইউজার আইডি হিডেন ইনপুটে বা এমনকি URL-এ রাখা আপনার জীবন সহজ করবে যখন ইউজার আরও কিছু রিকোয়েস্ট করবে সার্ভার থেকে।

তবে, এটি একটি চুরি অ্যাটাকের হাফওয়ে।

সেনসিটিভ ডেটা এক্সপোজার

এই টপিকটি সম্ভবত সবচেয়ে অনাদৃত যে পর্যাপ্ত এফোর্ট ডেডিকেট করা হয় না সেনসিটিভ ইনফরমেশনের সিকিউরিটি নিশ্চিত করতে।

চাহে আপনার ডেটা কনস্ট্যান্ট ট্রানজিটে হোক বা অ্যাট রেস্ট, এটি অত্যন্ত গুরুত্বপূর্ণ সাধারণ ডেটা থেকে সেনসিটিভ ডেটা আলাদা করা। সেনসিটিভ ডেটা شامل করে ক্রেডিট কার্ড নম্বর এবং কোড, পাসওয়ার্ড, পারসনাল আইডেন্টিফায়ার নম্বর, বা যেকোনো কিছু যা কম্প্লায়েন্স বা প্রাইভেসি ল ( যেমন EU-এর GDPR এবং PCI) এর সাথে রিলেটেড।

সেটি ছাড়াও, আপনার অ্যাপ্লিকেশন যে স্পেসিফিক বিজনেস এরিয়ায় রান করছে সেটি নির্ভর করে, локаাল লেজিস্লেশন কনসাল্ট করা গুরুত্বপূর্ণ নির্ধারণ করতে কোন অন্যান্য কম্প্লায়েন্স রুলও প্রযোজ্য কিনা।

এখানে এই ভালনারেবিলিটির কিছু স্পষ্ট উদাহরণ:

• আপনার ডেটা কি ইনক্রিপ্টেড বা প্লেইন টেক্সট হিসেবে ওয়েবের মাধ্যমে ট্রান্সপোর্ট হচ্ছে?
• আপনি যদি ডেটা এনক্রিপ্ট করেন, কী অ্যালগরিদম ব্যবহার করছেন? কি সেটি.STRONG এবং রিলায়েবল নিউওয়েস্ট টাইপের ক্রিপ্টো অ্যাটাকের বিপক্ষে?
• আপনি কি ডিফল্ট ক্রিপ্টোগ্রাফিক কী ব্যবহার করেন যদি কেউ প্রদান না করে?
• আপনি চেক করেছেন কিনা আপনার HTTP রিকোয়েস্ট প্রপার সিকিউরিটি হেডার দ্বারা إنফোর্সড হচ্ছে?

চলুন কিছু সবচেয়ে কমন সিনেরিও বিশ্লেষণ করি।

আনসেফ সেনসিটিভ স্টোরেজ

আপনি যদি কিছু সময় ওয়েব অ্যাপ্লিকেশনের সাথে কাজ করেছেন, সম্ভাবনা আছে আপনি MD5 মেসেজ-ডাইজেস্ট অ্যালগরিদম সম্পর্কে শুনেছেন (বা হতে পারে ব্যবহার করেছেন)। যদিও এটি এখনও পাসওয়ার্ড হ্যাশের জন্য ব্যাপকভাবে ব্যবহৃত হয়, এটি প্রুভেন অত্যন্ত উইক।

এখানে গুরুত্বপূর্ণ হ্যাশিং এবং এনক্রিপ্টিং ইনফরমেশনের পার্থক্য বুঝতে। এনক্রিপশন সাপেক্ষ হওয়া উচিত যখন কোনো ধরনের কী ব্যবহার করা হয় ডেটা ডিক্রিপ্ট করতে। হ্যাশিং রেফার করে কনভারশনের মেথড; আপনি ডেটাকে একটি হ্যাশে রূপান্তর করতে পারেন কিন্তু বিপরীত দিক থেকে নয়।

এটি সকল ধরনের সেনসিটিভ ইনফরমেশনে প্রযোজ্য, যদিও MD5 অধিকাংশকে পাসওয়ার্ড হ্যাশিং-এ ব্যবহার করার জন্য পরিচিত। যদি আপনার অ্যাপ্লিকেশন ইউজারের সোশ্যাল সিকিউরিটি নম্বর (SSN) রাখে, উদাহরণস্বরূপ, নিশ্চিত করুন সেটি শুধু আপনার ডেটাবেসে সফলি স্টোর করা নয় বরং লক্ষ্য করুন কীভাবে ডেটা আপনার অ্যাপ্লিকেশনের মাধ্যমে অন্যান্য ডেটাবেসে এবং, বিশেষত, ব্রাউজারে ট্রান্সমিট হচ্ছে।

হুমকি একশনে

যে মানেই আমরা দেখেছি, RailsGoat উদ্দেশ্যপূর্ণভাবে ইউজারের পাসওয়ার্ড MD5 হ্যাশ হিসেবে স্টোর করে। আপনি এটি user.rb মডেলে দেখতে পারেন:

def hash_password if self.password.present? self.password = Digest::MD5.hexdigest(password) end end 

প্রতিবার ইউজার লগইন করলে, অ্যাপ প্রদত্ত পাসওয়ার্ড হ্যাশ করে এবং চেক করে রেজাল্টগুলো সমান কিনা। অন্যথায়, পাসওয়ার্ডগুলো মেলে না, তাই একটি এরর থ্রো করা হয়।

এই ইস্যু রিজলভ কীভাবে

এই ইস্যু ট্যাকল করার অনেক উপায় আছে, কিন্তু সবচেয়ে বিখ্যাত একটি হলো সল্ট হ্যাশের মাধ্যমে, যেগুলো BCrypt-এ প্রদান করা হয়।

যদিও রেইলস ডিফল্ট ক্যাপাবিলিটি দিয়ে থাকে Bcrypt-র সাথে ডিল করার জন্য, একটি বিখ্যাত লিব ব্যাপকভাবে ব্যবহৃত হয়েছে এই উদ্দেশ্যে: bcrypt-ruby:

gem install bcrypt 

যখন আপনি আপনার মডেল সেটি ম্যাপ করবেন, পাসওয়ার্ড কীভাবে সেট এবং ডেটাবেস থেকে অবটেইন করা হয় সেটি ডিফাইন হয়। লিব বাকি সব কিছু অটোমেটিকলি অ্যাডাপ্ট করে:

require 'bcrypt' class User < ActiveRecord include BCrypt def password @password ||= Password.new(password_hash) end def password=(new_password) @password = Password.create(new_password) self.password_hash = @password end end 

তবে, ফ্লোতে একটি অতিরিক্ত স্ট্রিং কলাম (password_hash) টেবিলে দরকার BCrypt অ্যালগরিদমের জন্য পাসওয়ার্ড হ্যাশ স্টোর করতে।

এইভাবে, আপনি পাসওয়ার্ড ভ্যালু সরাসরি মডেল অবজেক্টে সেট করতে পারেন, এবং BCrypt সিকিউরলি হ্যাশ করার দায়িত্ব নেবে। একই ঘটবে যখন পাসওয়ার্ড রিট্রিভ করা হবে ইউজারের ইনপুটের সাথে কম্পেয়ার করার জন্য।

ওভার এক্সপোজ

চাহে আপনি REST APIs বা GraphQL এন্ডপয়েন্টের সাথে কাজ করছেন, নিশ্চিত করুন শুধু সেটি রিটার্ন করছে যা ক্লায়েন্ট কাজ করার জন্য প্রয়োজন।

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

সদা আপনার APIs রিভিউ করুন সার্টিফাই করতে যে সেনসিটিভ ইনফরমেশন রিটার্ন হচ্ছে কিনা, সেটি শুধু প্রপার এনক্রিপশন এবং সঠিক জায়গায় করবে।

হুমকি একশনে

যখন ইউজারের ডেটার কথা আসে, সিকিউর মেকানিজম তৈরি করা গুরুত্বপূর্ণ যাতে সেনসিটিভ ইনফরমেশন লিক হবে না।

users_controller.rb ফাইল খুলুন api/v1 ফোল্ডারে। সেখানে, আপনি নিচের মেথড পাবেন:

def show respond_with @user.as_json end 

যতটা সিম্পল, যখন ওয়েব ক্লায়েন্ট দ্বারা অ্যাক্সেস করা হয়, এই এন্ডপয়েন্ট ইউজারের সকল ফিল্ড পপুলেটেড রেসপন্সে রিটার্ন করবে, পাসওয়ার্ডসহ।

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

এই ইস্যু রিজলভ কীভাবে

শুকরCAR, রেইলস একটি খুব সহজ উপায় দিয়ে থাকে এটিকে ডিল করার জন্য। চলুন শুধু as_json মেথড ওভাররাইড করি নিচের দিয়ে:

def as_json super(only: [:id, :email]) end 

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

র‍্যাপ আপ

আজ, আমরা ব্রোকেন অথেন্টিকেশন এবং সেনসিটিভ ডেটা এক্সপোজারের জলপ্লাবনে নেভিগেট করেছি। এই রুলগুলো ফলো করলে, আপনি নিশ্চিত করবেন আপনার ইউজার এবং ক্লায়েন্টদের জন্য একটি অনেক সেফার অ্যাপ্লিকেশন।

অতিরিক্তভাবে, অফিশিয়াল Ruby on Rails Security Documentation পড়ার গুরুত্ব অতিক্রান্ত করা যায় না। সেখানে, আপনি সেশন হাইজ্যাকিং, স্টোরেজ মেকানিজম, এবং আপনার ডেটা সবচেয়ে ভালোভাবে এনক্রিপ্ট করার কৌশল সম্পর্কে আরও ইনফরমেশন পাওয়া যাবে।

পরবর্তী স্টপে দেখা হবে!