এই সিরিজের প্রথম অংশ, কভার ইনজেকশন অ্যাটাকস

OWASP শীর্ষ 10 ওয়েব অ্যাপ্লিকেশন নিরাপত্তা ঝুঁকি সম্পর্কে আমাদের সিরিজের দ্বিতীয় নিবন্ধে, আমরা ভাঙা প্রমাণীকরণ এবং ডেটা এক্সপোজার হুমকির মহাবিশ্বে ডুব দেব।

আরও নির্দিষ্টভাবে, আমরা আলোচনা করব যে হ্যাকারের পক্ষে আপনার তৈরি করা কোডটি কৌশলে চালান করা এবং ব্যবহারকারীদের ডেটা পাওয়ার জন্য আক্রমণ করা কতটা সহজ:

• ব্যবহারকারীর গণনা :যখন তারা আপনার ডাটাবেসে বিদ্যমান কিনা তা পরীক্ষা করার জন্য সম্ভাব্য ব্যবহারকারীদের একটি তালিকা নির্মমভাবে পরীক্ষা করে আপনার লগইন পৃষ্ঠাগুলিকে কাজে লাগায়৷
• দুর্বল পাসওয়ার্ড :যখন আপনার সিস্টেম দুর্বল পাসওয়ার্ডের অনুমতি দেয়, হ্যাকাররা আপনার ব্যবহারকারীদের পাসওয়ার্ড অনুমান করার জন্য একটি নৃশংস শক্তি আক্রমণ চালাতে পারে৷
• অনিয়ন্ত্রিত কুকিজ :যখন আপনার সিস্টেম যথাযথ নিরাপত্তা সেটিংস ছাড়া কুকিতে সংবেদনশীল ডেটা সঞ্চয় করে, তখন হ্যাকাররা XSS আক্রমণের মাধ্যমে তথ্য চুরি করতে পারে।

আমরা সংবেদনশীল ডেটা সম্পর্কেও বিস্তারিত জানাব যা পর্যাপ্তভাবে সুরক্ষিত নয়, দুর্বলতার জন্য জায়গা তৈরি করে, যেমন নিম্নলিখিত:

• অনিরাপদ সংবেদনশীল সঞ্চয়স্থান :যখন সংবেদনশীল ডেটা দুর্বল অ্যালগরিদম দিয়ে এনক্রিপ্ট করা হয়, যেমন MD5৷
• সংবেদনশীল ডেটা প্রকাশ করা৷ :যখন বিকাশকারীরা অনিচ্ছাকৃতভাবে ইউআরএল বা লুকানো ক্ষেত্রগুলিতে এনক্রিপ্ট করা সংবেদনশীল ডেটা প্রকাশ করে, উদাহরণস্বরূপ।

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

আসুন সরাসরি ভিতরে ঝাঁপ দেওয়া যাক!

প্রমাণিকরণের হুমকি

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

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

নজর রাখতে অনেক প্রশ্ন আছে। আসুন সেগুলিকে কিছুটা ভেঙে ফেলি এবং রেল অ্যাপ্লিকেশনগুলির মধ্যে প্রমাণীকরণ এবং সেশন পরিচালনার সাথে জড়িত কিছু সাধারণ আক্রমণগুলি বুঝতে পারি৷

ব্যবহারকারীর গণনা

ব্যবহারকারীর গণনা একটি বিখ্যাত কৌশল যা আক্রমণকারীরা পরীক্ষা করতে ব্যবহার করে (ব্রুট ফোর্স ব্যবহার করে) প্রদত্ত ডেটা আপনার সিস্টেমের মধ্যে বিদ্যমান কিনা।

এই আক্রমণের সবচেয়ে কুখ্যাত উদাহরণগুলির মধ্যে একটি বর্তমান ফেসবুক লগইন পৃষ্ঠার সাথে ঘটে। আপনি যদি নীচের ছবিতে দেখানোর মতো কিছু অবৈধ এবং র্যান্ডম শংসাপত্র প্রবেশ করেন, তাহলে Facebook অনুরোধটি প্রক্রিয়া করবে এবং তাদের ডাটাবেসের মধ্যে ব্যবহারকারীর অস্তিত্ব পরীক্ষা করবে৷

ফেসবুকের লগইন পৃষ্ঠা।

যখন আপনি লগ ইন ক্লিক করুন বোতাম, Facebook আপনার ব্যবহারকারীর নাম (যেটি একটি ইমেল বা ফোন নম্বর হতে পারে) বৈধ নয় বলে একটি ত্রুটি বার্তা দেবে৷

অবৈধ ব্যবহারকারীর নাম বার্তা৷৷

অতএব, আক্রমণকারী জানে যে অ্যাপ্লিকেশনটি আপনাকে বলে যে একজন ব্যবহারকারী নিবন্ধিত কিনা। বিনামূল্যে।

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

অবৈধ পাসওয়ার্ড বার্তা৷৷

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

অবশ্যই, Facebook বিকাশকারীরা এটি সম্পর্কে জানেন, এবং এই কারণেই তারা একটি নির্দিষ্ট আইপি ঠিকানা থেকে আসা অনুরোধের সংখ্যার উপর অদৃশ্য ক্যাপচা এবং যাচাইকরণের মতো অতিরিক্ত সুরক্ষা প্রয়োগ করেছে৷

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

দ্যা থ্রেট ইন অ্যাকশন

RailsGoat অ্যাপে, 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
    },

    ...

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

এই সমস্যাটি কিভাবে সমাধান করবেন

সমাধান বেশ সহজ; কিছু শক্তিশালী প্রয়োজনীয়তার বিরুদ্ধে আপনার পাসওয়ার্ড যাচাই করুন, যেমন নিম্নলিখিত:

• কমপক্ষে ১টি ছোট হাতের এবং ১টি বড় হাতের অক্ষর,
• কমপক্ষে ১ সংখ্যা,
• কমপক্ষে 10 অক্ষর।

আপনি যত বেশি প্রয়োজনীয়তা যোগ করবেন, আপনার পাসওয়ার্ড তত নিরাপদ হবে। এটিকে খুব বেশি ধাক্কা না দেওয়ার বিষয়ে নিশ্চিত হন কারণ এটি ব্যবহারযোগ্যতা এবং পাসওয়ার্ড পুনরুদ্ধারের প্রবাহে জটিলতা বাড়াতে পারে৷

RailsGoat-এর মধ্যে এটি সমাধান করার জন্য, দৈর্ঘ্যের বৈশিষ্ট্যটিকে নিম্নলিখিত দিয়ে প্রতিস্থাপন করুন:

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

তারপর, সাইন আপ পৃষ্ঠায় যান, ক্ষেত্রগুলি পূরণ করুন এবং একটি দুর্বল পাসওয়ার্ড প্রদান করুন৷ আপনি যখন জমা দেবেন, এটি প্রদর্শিত ত্রুটি বার্তা হবে:

পাসওয়ার্ডটি অবৈধ৷৷

অনিয়ন্ত্রিত কুকি

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

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

কুকিজ, পরিবর্তে, একটু নিরাপদ হয় যদি আপনি সেগুলি তৈরি করার জন্য সঠিক পদক্ষেপ নেন, যেমন HttpOnly সেট করা। পতাকা।

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

বিকল্পভাবে, আমাদের কাছে Secureও আছে অ্যাট্রিবিউট, যা নিশ্চিত করবে যে কুকি শুধুমাত্র সার্ভারে পাঠানো হবে যদি (এবং শুধুমাত্র যদি) অনুরোধটি HTTPS-এর মধ্যে ঘটে (কখনও HTTP-এর মধ্যে নয়)। এটি আপনার অনুরোধগুলিকে আরও নিরাপদ করে তুলবে যদি কেউ সেগুলিকে মানুষ-মধ্যম হিসাবে শুঁকে থাকে .

অ্যাকশনে হুমকি

রেলগুলি স্বয়ংক্রিয়ভাবে HttpOnly সহ সমস্ত কুকি সেট করে আপনার জন্য একটি পদক্ষেপ নেয়৷ পতাকা এটি দুর্দান্ত কারণ এটি অসচেতন বিকাশকারীদের তাদের অ্যাপ হ্যাক হওয়া এড়াতে সহায়তা করে৷

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

তারপর, আরও একবার নিবন্ধন পৃষ্ঠায় যান, সঠিকভাবে ক্ষেত্রগুলি পূরণ করুন, এবং নাম-এ নিম্নলিখিত বিষয়বস্তু ইনপুট করুন ক্ষেত্র:

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

আপনি যখন ফর্ম জমা দেবেন, তখন ব্যবহারকারী তৈরি করা হবে, সাথে নিম্নলিখিত পরবর্তী সতর্কতা বার্তা থাকবে:

RailsGoat সেশন কুকি প্রকাশ করে সতর্কতা বার্তা৷৷

এই সমস্যাটি কিভাবে সমাধান করবেন

এই ক্ষেত্রে, এটি বেশ সহজবোধ্য, শুধু নিশ্চিত করুন যে HttpOnly অক্ষম করবেন না আপনার Rails অ্যাপে পতাকা।

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

খালি সতর্কতা বার্তা৷৷

অন্যান্য পরিস্থিতি

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

একটি অ্যাপ্লিকেশন থেকে লগ আউট করার জন্য কেবল একটি ব্রাউজার ট্যাব বন্ধ করা যথেষ্ট নয়৷

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

যাইহোক, এটি একটি চুরি আক্রমণের অর্ধেক পথ।

সংবেদনশীল ডেটা এক্সপোজার

সংবেদনশীল তথ্যের নিরাপত্তা নিশ্চিত করার জন্য যথেষ্ট প্রচেষ্টা উৎসর্গ করার ক্ষেত্রে এই বিষয়টি সম্ভবত সবচেয়ে অবমূল্যায়নযোগ্য।

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

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

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

• আপনার ডেটা কি কোনোভাবে এনক্রিপ্ট করা হয় বা ওয়েবের মাধ্যমে প্লেইন টেক্সট হিসেবে পরিবহন করা হয়?
• আপনি যদি ডেটা এনক্রিপ্ট করেন, তাহলে আপনি কোন অ্যালগরিদম ব্যবহার করছেন? এটি কি নতুন ধরনের ক্রিপ্টো আক্রমণের বিরুদ্ধে শক্তিশালী এবং নির্ভরযোগ্য?
• আপনি কি ডিফল্ট ক্রিপ্টোগ্রাফিক কী ব্যবহার করেন যদি কোনোটি প্রদান করা না হয়?
• আপনি কি পরীক্ষা করেছেন যে আপনার HTTP অনুরোধগুলি যথাযথ নিরাপত্তা শিরোনাম দ্বারা প্রয়োগ করা হয়েছে কিনা?

আসুন কিছু সাধারণ পরিস্থিতি বিশ্লেষণ করি।

অনিরাপদ সংবেদনশীল স্টোরেজ

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

হ্যাশিং এবং এনক্রিপ্ট করা তথ্যের মধ্যে পার্থক্য বোঝা এখানে গুরুত্বপূর্ণ। এনক্রিপশন ঘটতে অনুমিত হয় যখন কিছু ধরণের কী ডেটা ডিক্রিপ্ট করতে ব্যবহার করা হয়। হ্যাশিং রূপান্তর পদ্ধতি বোঝায়; আপনি ডেটাকে হ্যাশে পরিণত করতে পারেন কিন্তু উল্টো নয়৷

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

অ্যাকশনে হুমকি

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

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

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

এই সমস্যাটি কিভাবে সমাধান করবেন

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

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

gem install bcrypt

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

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 API বা GraphQL এন্ডপয়েন্টের সাথে কাজ করছেন কিনা, উদাহরণস্বরূপ, ক্লায়েন্টকে কাজ করার জন্য যা প্রয়োজন তা শুধুমাত্র ফেরত দিতে ভুলবেন না।

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

প্রত্যয়িত করার জন্য সর্বদা আপনার API গুলি পর্যালোচনা করুন যে সংবেদনশীল তথ্য ফেরত দেওয়া হোক না কেন, এটি শুধুমাত্র সঠিক এনক্রিপশন এবং সঠিক জায়গায় তা করবে৷

অ্যাকশনে হুমকি

ব্যবহারকারীর ডেটার ক্ষেত্রে, সংবেদনশীল তথ্য ফাঁস হবে না তা নিশ্চিত করার জন্য সুরক্ষিত ব্যবস্থা তৈরি করা গুরুত্বপূর্ণ৷

users_controller.rb খুলুন api/v1-এ ফাইল ফোল্ডার সেখানে, আপনি নিম্নলিখিত পদ্ধতিটি পাবেন:

def show
  respond_with @user.as_json
end

এটি যতটা সহজ, ওয়েব ক্লায়েন্ট দ্বারা অ্যাক্সেস করা হলে, এই এন্ডপয়েন্টটি পাসওয়ার্ড সহ প্রতিক্রিয়ার মধ্যে থাকা সমস্ত ব্যবহারকারীর ক্ষেত্রগুলিকে ফিরিয়ে দেবে৷

শুধু user নয় মডেল কিন্তু সংবেদনশীল তথ্য ধারণ করে এমন অন্যান্য মডেলের জন্য এমন বৈশিষ্ট্য নির্বাচন করার একটি উপায় প্রয়োজন যা API-তে দৃশ্যমান হবে।

এই সমস্যাটি কিভাবে সমাধান করবেন

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

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

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

র্যাপিং আপ

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

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

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