𝗖𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝗟𝗼𝗴𝗶𝗻 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆

আনলিমিটেড লগইন গুরুতর বিজনেস লজিক ত্রুটি লুকিয়ে রাখতে পারে।

একজন ব্যবহারকারী একটি ল্যাপটপে লগইন করেন। কয়েক সেকেন্ড পরে, একই অ্যাকাউন্ট দিয়ে অন্য একটি ব্রাউজারে লগইন করা হয়। তারপর একটি মোবাইল ডিভাইস। এরপর একটি API ক্লায়েন্ট। সবকিছুই নিখুঁতভাবে কাজ করছে।

এটি ঠিক মনে হতে পারে কারণ অনেক অ্যাপ একাধিক ডিভাইস সমর্থন করে। কিন্তু আপনার নিজেকে প্রশ্ন করতে হবে: প্রতিটি অ্যাপ্লিকেশন কি আনলিমিটেড সেশন অ্যালাউ করা উচিত?

কিছু সিস্টেমে একাধিক সেশন একটি ফিচার। অন্যদের ক্ষেত্রে, এটি একটি ত্রুটি যা আক্রমণকারীরা লুকিয়ে থাকার জন্য ব্যবহার করে। এটি একটি বিজনেস লজিক ভালনারেবিলিটি (business logic vulnerability)। কোডটি ডিজাইন অনুযায়ী কাজ করছে, কিন্তু ডিজাইনটি নিজেই দুর্বল।

পার্থক্য: • ট্র্যাডিশনাল বাগ (Traditional bugs) কোডিংয়ের ভুলকে কাজে লাগায়। • বিজনেস লজিক বাগ (Business logic bugs) ডিজাইনের সিদ্ধান্তকে কাজে লাগায়।

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

এটি ব্যাংকিং, অ্যাডমিন প্যানেল এবং SaaS প্রোডাক্টের ক্ষেত্রে প্রযোজ্য।

এটি কীভাবে টেস্ট করবেন:

হাই-সিকিউরিটি অ্যাপগুলো প্রায়ই এই নিয়মগুলো মেনে চলে:

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

প্রেক্ষাপটই সব। যেসব অ্যাপে অনেক সেশনের প্রয়োজন হয়:

যেসব অ্যাপে কঠোর নিয়ন্ত্রণের প্রয়োজন হয়:

এটি কীভাবে সমাধান করবেন:

শুধুমাত্র SQL ইনজেকশনের মতো কোড বাগ খুঁজবেন না। আপনার অ্যাপ কী করছে এবং আপনার ব্যবসার কী প্রয়োজন—এই দুটির মধ্যে কোনো ফাঁক আছে কি না তা দেখুন।

আজই আপনার সেশন পলিসিটি পর্যালোচনা করুন। আপনার সবচেয়ে বড় ঝুঁকি ভাঙা কোড নাও হতে পারে। এটি হতে পারে ত্রুটিপূর্ণ লজিক।

উৎস: https://dev.to/arashad_dodhiya_0e4bdba5a/concurrent-login-security-how-to-check-whether-multiple-sessions-are-allowed-1839