সেশন হাইজ্যাকিং রোধ করার সেরা উপায় কী?


124

সার্ভারে একটি সেশন সনাক্ত করতে ক্লায়েন্ট সেশন কুকি ব্যবহার করার সময় এটি সম্পর্কিত this

পুরো ওয়েব সাইটের জন্য এসএসএল / এইচটিটিপিএস এনক্রিপশন ব্যবহার করার সর্বোত্তম উত্তরটি কী এবং আপনার পক্ষে সর্বোত্তম গ্যারান্টি রয়েছে যে মাঝের আক্রমণগুলির কোনও লোকই বিদ্যমান ক্লায়েন্ট সেশন কুকিকে স্নিগ্ধ করতে সক্ষম হবে না?

এবং সেশন কুলিতে নিজেই যে কোনও ধরণের এনক্রিপশন ব্যবহার করা সম্ভবত দ্বিতীয়টি সেরা?

যদি কোনও দূষিত ব্যবহারকারীর কোনও মেশিনে শারীরিক অ্যাক্সেস থাকে তবে তারা এখনও একটি বৈধ সেশন কুকি পুনরুদ্ধার করতে ফাইল সিস্টেমের দিকে তাকাতে পারেন এবং একটি সেশন হাইজ্যাক করার জন্য এটি ব্যবহার করতে পারেন?

উত্তর:


140

সেশন মান এনক্রিপ্ট করা শূন্য প্রভাব ফেলবে। সেশন কুকি ইতিমধ্যে একটি স্বেচ্ছাসেবী মান, এটি এনক্রিপ্ট করা কেবল স্নিগ্ধ হতে পারে এমন অন্য এক স্বেচ্ছাসেবী মান তৈরি করবে।

একমাত্র আসল সমাধান হ'ল এইচটিটিপিএস। আপনি যদি নিজের পুরো সাইটে এসএসএল করতে না চান (সম্ভবত আপনার পারফরম্যান্সের উদ্বেগ রয়েছে) তবে আপনি কেবল সংবেদনশীল অঞ্চলগুলি রক্ষা করে এসএসএল থেকে সরে যেতে সক্ষম হতে পারেন। এটি করতে প্রথমে নিশ্চিত হয়ে নিন যে আপনার লগইন পৃষ্ঠাটি এইচটিটিপিএস। যখন কোনও ব্যবহারকারী লগ ইন করে, নিয়মিত সেশন কুকি ছাড়াও একটি সুরক্ষিত কুকি সেট করুন (ব্রাউজারটি কেবল এটি কোনও এসএসএল লিঙ্কের মাধ্যমে প্রেরণ করবে)। তারপরে, যখন কোনও ব্যবহারকারী আপনার "সংবেদনশীল" অঞ্চলগুলির একটিতে যান, তাদের HTTPS এ পুনর্নির্দেশ করুন এবং সেই সুরক্ষিত কুকির উপস্থিতি যাচাই করুন। প্রকৃত ব্যবহারকারীর কাছে এটি থাকবে, একটি সেশন হাইজ্যাকার তা করবে না।

সম্পাদনা : এই উত্তরটি মূলত ২০০৮ সালে লেখা হয়েছিল It's এটি এখন 2016, এবং আপনার পুরো সাইট জুড়ে এসএসএল না থাকার কোনও কারণ নেই। আর কোনও সরল টেক্সট এইচটিটিপি!


28
এইচটিটিপিএস কেবল স্নিফিং প্রতিরোধ করবে। তবে আপনার যদি এক্সএসএস থাকে, বা সেশন আইডিগুলি সহজেই অনুমান করা যায়, বা আপনি সেশন ফিক্সেশনের পক্ষে ঝুঁকছেন, বা আপনার সেশন আইডি স্টোরেজটি দুর্বল (এসকিউএল ইনজেকশন?), এসএসএলের কোনও উন্নতি হবে না।
ক্যালিমো

5
@ জোশ যদি কোনও দূষিত ব্যবহারকারীর কোনও মেশিনে শারীরিক অ্যাক্সেস থাকে তবে তারা এখনও একটি বৈধ সেশন কুকি পুনরুদ্ধার করতে ফাইল সিস্টেমটি দেখতে পারেন এবং একটি সেশন হাইজ্যাক করার জন্য এটি ব্যবহার করতে পারেন?
পেসারিয়ার

72
যদি কোনও দূষিত ব্যবহারকারীর কোনও ফাইল সিস্টেমে শারীরিক অ্যাক্সেস থাকে তবে তাদের একটি সেশন হাইজ্যাক করার দরকার নেই।
জোশ হিন্মান

25
@Josh। সত্য নয়, কখনও কখনও কোনও ব্যবহারকারী একটি ফাইল সিস্টেমে সীমিত শারীরিক অ্যাক্সেস রাখে। কল্পনা করুন একটি ল্যাপটপ একজন সহকর্মী টয়লেটে rushing দ্বারা আনলক করে ছেড়ে দেওয়া, এখন আমি যা করতে হবে, যে ল্যাপটপ যেতে EditThisCookie প্লাগইন ইনস্টল করুন, EditThisCookie রপ্তানি বৈশিষ্ট্য ব্যবহার plus.google.com তার কুকি দখল হয় এবং এখন আমি তার একাউন্ট আছে । সময় নেওয়া হয়েছে: 18 সেকেন্ড
পেসারিয়ার

1
আমি যথেষ্ট নিশ্চিত যে গুগলের কোনও ধরণের সুরক্ষা বৈশিষ্ট্য
অন্তর্নির্মিত

42

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

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

আমি নিশ্চিত নই যে এই ধারণাটি কাজ করবে কিনা তবে এখানে যায়: আপনার সেশন কুকিতে একটি সিরিয়াল নম্বর যুক্ত করুন, সম্ভবত এর মতো একটি স্ট্রিং:

সেশনউইউইড, ক্রমিক সংখ্যা, বর্তমান তারিখ / সময়

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

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


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

@ ক্রাশ, তবে তবে আক্রমণকারীকে বরাদ্দ করা উইন্ডোর পরে লক আউট করা হবে, তাই না? সুতরাং খুব কম সময়ে আক্রমণ উইন্ডোটি ছোট (এর)।
জোহানকে

2
কেবল সমস্যাটি যদি ব্যবহারকারী আপনার ওয়েবসাইটটি 5 মিনিটের জন্য ছেড়ে যায়, তবে তাদের আবার লগইন করতে হবে
elipoultorak

21

আপনি কি পিএইচপি সুরক্ষা সম্পর্কিত কোনও বই পড়া বিবেচনা করেছেন? অত্যন্ত বাঞ্ছনীয়.

নন এসএসএল প্রত্যয়িত সাইটগুলির জন্য নিম্নলিখিত পদ্ধতিটি নিয়ে আমার অনেক সাফল্য আছে।

  1. আপনি একমাত্র আইপি ঠিকানার মাধ্যমে এটি পরীক্ষা করছেন না তা নিশ্চিত করে একই অ্যাকাউন্টের অধীনে একাধিক সেশনগুলিকে ডিস-মঞ্জুরি দিন। বরং লগইন নেওয়ার সময় উত্পন্ন টোকেন যা ব্যবহারকারীদের সেশনে ডেটাবেজে সংরক্ষণ করা হয় সেইসাথে আইপি ঠিকানা, HTTP_USER_AGENT এবং আরও

  2. রিলেশন ভিত্তিক হাইপারলিঙ্কগুলি ব্যবহার করে একটি লিঙ্ক উত্পন্ন হয় (উদাঃ http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) লিঙ্কটি এক্স-বিওয়াইটিই (পছন্দসই আকার) এলোমেলোভাবে সল্টেড এমডি 5 স্ট্রিং সহ পৃষ্ঠাটি পুনঃনির্দেশের উপর এলোমেলোভাবে উত্পন্ন হয়েছে টোকেন একটি অনুরোধ করা পৃষ্ঠার সাথে সম্পর্কিত।

    • পুনরায় লোড করার পরে, বেশ কয়েকটি চেক সম্পন্ন হয়।
    • মূল ঠিকানা আইপি ঠিকানা
    • HTTP_USER_AGENT
    • সেশন টোকেন
    • আপনি পয়েন্ট পেতে।
  3. শর্ট লাইফ-স্প্যান সেশন প্রমাণীকরণ কুকি। উপরে পোস্ট করা হিসাবে, একটি কুকি একটি সুরক্ষিত স্ট্রিং রয়েছে যা সেশনের বৈধতার প্রত্যক্ষ উল্লেখগুলির মধ্যে একটি হ'ল একটি ভাল ধারণা। প্রতিটি টাকেনটি পুনরায় প্রকাশ করে এবং নতুন ডেটা দিয়ে সেশনটি পুনরায় সিঙ্ক করে প্রতিটি এক্স মিনিটের মেয়াদ শেষ করুন। যদি ডেটাতে কোনও ভুল মেলে, হয় ব্যবহারকারীকে লগ আউট করুন, বা তাদের সেশনটি পুনরায় প্রমাণীকরণের মাধ্যমে।

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


4
আপনি সুপারিশ করবে কোন বই আছে?
রিককি

1
বিশেষত ওএইচপি বিশেষত পিএইচপি সম্পর্কে কিছু না জানায়, আমি বলব যে কেবল একটি সাধারণ সুরক্ষা বই দেখে নেওয়া ভাল (বিশেষত বিভিন্ন ভাষার মধ্যে সুরক্ষা কেবল বাস্তবায়নের বিশদগুলিতে পৃথক হলেও ধারণাগুলি একই থাকে)।
matts1

২০১ 2017 সালে, এমনকি ফেসবুক / জিমেইল ইত্যাদি একই অ্যাকাউন্টের অধীনে একাধিক সেশনের অনুমতি দেয় (বিশেষত মোবাইল ডিভাইস সহ) যদি না আপনি আপনার ব্যবহারকারীদের ঘৃণা করেন তবে # 1 কিছুটা পুরানো।
কাউয়ারবার্ট 24'18

20
// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();

// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);

// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
    end_session();
    header("Location: login.php");
    // add some fancy pants GET/POST var headers for login.php, that lets you
    // know in the login page to notify the user of why they're being challenged
    // for login again, etc.
}

এটি যা করে তা ব্যবহারকারীর সেশন সম্পর্কে 'প্রাসঙ্গিক' তথ্য ক্যাপচার করে, এমন একাধিক তথ্যের টুকরো যা একক অধিবেশন চলাকালীন পরিবর্তিত হয় না। একজন ব্যবহারকারী একই সাথে মার্কিন যুক্তরাষ্ট্রে এবং চীনে কম্পিউটারে যাবেন না, তাই না? সুতরাং যদি একই ঠিকানার মধ্যে আইপি ঠিকানাটি হঠাৎ পরিবর্তিত হয় যা একটি সেশন হাইজ্যাকিং প্রয়াসের দৃ strongly়তার সাথে বোঝায়, তাই আপনি সেশনটি শেষ করে এবং ব্যবহারকারীকে পুনরায় প্রমাণীকরণে বাধ্য করে সেশনটি সুরক্ষিত করুন। এটি হ্যাক প্রচেষ্টা ব্যর্থ করে, আক্রমণকারীটি সেশনে অ্যাক্সেস পাওয়ার পরিবর্তে লগইন করতে বাধ্য হয়। চেষ্টার ব্যবহারকারীকে অবহিত করুন (এটি কিছুটা সামান্য অ্যাজাক্স করুন) এবং ভোলা, সামান্য বিরক্ত + অবহিত ব্যবহারকারী এবং তাদের সেশন / তথ্য সুরক্ষিত।

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

এটি 100% নয়, তবে এটি বেশ জঘন্য কার্যকর।

সেশনগুলি সুরক্ষিত করার জন্য, তাদের মেয়াদ শেষ হতে, যখন কোনও ব্যবহারকারী কোনও ওয়েবসাইট ছেড়ে যায় এবং ফিরে আসে তখন তাদের আবার লগইন করতে বাধ্য করার মতো আরও অনেক কিছু রয়েছে। কোনও ব্যবহারকারী ফাঁকা HTTP_REFERER (ডোমেনটি ইউআরএল বারে টাইপ করা হয়েছিল) ক্যাপচার করে আপনি ফিরে আসতে এবং সনাক্ত করতে পারেন বা HTTP_REFERER এর মানটি আপনার ডোমেনের সমান কিনা তা পরীক্ষা করতে পারেন (ব্যবহারকারী আপনার কাছে যেতে বহিরাগত / খিলানযুক্ত লিঙ্কটি ক্লিক করেছে) সাইট)।

সেশনগুলির মেয়াদ শেষ করুন, তাদের অনির্দিষ্টকালের জন্য বৈধ থাকতে দেবেন না।

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


3
আমি এমন পরিস্থিতিতে পড়েছি যেখানে একটি নির্দিষ্ট (মোটামুটি বড়, তবে প্রযুক্তিগতভাবে পিছিয়ে) আইএসপি তাদের ব্যবহারকারীর সংযোগগুলি পুনরায় রাউটের উপর ভিত্তি করে ব্যবহারকারীর ব্রাউজারের আইপি-কে সময়ে-সময়ে পরিবর্তন করে। এটি আমাদের জন্য REMOTE_ADDR চেক রিটার্ন মিথ্যা নেতিবাচক করে তুলেছে।
goofballLogic

কেন একটি হ্যাশ তৈরি করতে বিরক্ত করবেন? $_SESSION['ident'] = $aip . $bip . $agent;ঠিক নিরাপদ হবে।
ড্যান ব্রে

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

প্রক্সি এবং ভিপিএন সম্পর্কে কী? যে কোনও টিওআর প্রক্সি ব্যবহার করে নিরন্তর তাদের অ্যাকাউন্টগুলি থেকে সাইন আউট করা হবে .. বাস্তবে প্রতি কয়েক মিনিটের মধ্যে।
ব্র্যাডলি

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

9

লিউ, কোভ্যাকস, হুয়াং এবং গৌদা এই কাগজে বর্ণিত সিকিউর কুকি প্রোটোকলটি ব্যবহার করে দেখুন :

নথিতে যেমন বলা হয়েছে:

একটি সুরক্ষিত কুকি প্রোটোকল যা একটি ক্লায়েন্ট এবং একটি সার্ভারের মধ্যে চলতে নিম্নলিখিত চারটি পরিষেবা সরবরাহ করতে হবে: প্রমাণীকরণ, গোপনীয়তা, অখণ্ডতা এবং অ্যান্টি-রিপ্লে।

স্থাপনার স্বাচ্ছন্দ্য হিসাবে:

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

সংক্ষেপে: এটি সুরক্ষিত, লাইটওয়েট, আমার জন্য দুর্দান্ত কাজ করে।


9
আপনার লিঙ্কটি প্রোটোকলের একটি বৈশিষ্ট - আপনার কোনও প্রয়োগের সাথে কোনও লিঙ্ক আছে? ধন্যবাদ দুর্দান্ত হবে - ধন্যবাদ
আদম

9

সেশনের হাইজ্যাকিং 100% রোধ করার কোনও উপায় নেই, তবে কিছু পদ্ধতির সাহায্যে আমরা আক্রমণকারীটির অধিবেশন হাইজ্যাক করার সময় হ্রাস করতে পারি।

সেশন হাইজিং প্রতিরোধের পদ্ধতি:

1 - সর্বদা এসএসএল শংসাপত্র সহ সেশন ব্যবহার করুন;

2 - কেবলমাত্র httponly সত্যে সেট করে সেশন কুকি প্রেরণ করুন (সেশন কুকিতে অ্যাক্সেস করার জন্য জাভাস্ক্রিপ্ট প্রতিরোধ করুন)

2 - লগইন এবং লগআউটে সেশন পুনর্জেট আইডি ব্যবহার করুন (দ্রষ্টব্য: প্রতিটি অনুরোধে সেশন পুনর্জন্মটি ব্যবহার করবেন না কারণ যদি আপনার একটানা এজাক্স অনুরোধ থাকে তবে আপনার একাধিক সেশন তৈরির সুযোগ রয়েছে))

3 - একটি সেশনের সময়সীমা নির্ধারণ করুন

4 - প্রতিটি অনুরোধে একটি ব্রাউজার ব্যবহারকারী এজেন্টকে request _SERVER ['HTTP_USER_AGENT'] এর সাথে একটি তুলনা করে একটি _S _SESSION ভেরিয়েবলে সঞ্চয় করুন

5 - একটি টোকেন কুকি সেট করুন এবং সেই কুকির মেয়াদোত্তীকরণের সময়টি 0 তে সেট করুন (ব্রাউজারটি বন্ধ না হওয়া পর্যন্ত)। প্রতিটি অনুরোধের জন্য কুকির মানটি পুনরায় তৈরি করুন ((এজাজার অনুরোধের জন্য টোকেন কুকিটি পুনরুত্পাদন করবেন না)। গো EX:

    //set a token cookie if one not exist
    if(!isset($_COOKIE['user_token'])){
                    //generate a random string for cookie value
        $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

        //set a session variable with that random string
        $_SESSION['user_token'] = $cookie_token;
        //set cookie with rand value
        setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
    }

    //set a sesison variable with request of www.example.com
    if(!isset($_SESSION['request'])){
        $_SESSION['request'] = -1;
    }
    //increment $_SESSION['request'] with 1 for each request at www.example.com
    $_SESSION['request']++;

    //verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
    if($_SESSION['request'] > 0){

        // if it's equal then regenerete value of token cookie if not then destroy_session
        if($_SESSION['user_token'] === $_COOKIE['user_token']){
            $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

            $_SESSION['user_token'] = $cookie_token;

            setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
        }else{
            //code for session_destroy
        }

    }

            //prevent session hijaking with browser user agent
    if(!isset($_SESSION['user_agent'])){
        $_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
    }

    if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
      die('session hijaking - user agent');
    }

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

- - সেশন হাইজিং প্রতিরোধের জন্য ইউজার আইপি ব্যবহার করা ভাল না, কারণ কিছু ব্যবহারকারী প্রতিটি অনুরোধের সাথে আইপি পরিবর্তন করে। ভ্যালিড ব্যবহারকারীর প্রভাব

7 - ব্যক্তিগতভাবে আমি ডেটাবেজে সেশন ডেটা সঞ্চয় করি, আপনি কোন পদ্ধতি অবলম্বন করবেন এটি আপনার বিষয়

আপনি যদি আমার পদ্ধতির কোনও ভুল খুঁজে পান তবে দয়া করে আমাকে সংশোধন করুন। আপনার যদি সেশন হাইজাকিং প্রতিরোধের আরও উপায় থাকে তবে দয়া করে আমাকে বলুন।


হাই, আমি অধিবেশন হাইজ্যাকিং প্রতিরোধের চেষ্টা করছি (এএসপি.নেট) এবং আপনি প্রস্তাবিত উপরের সমস্ত পদক্ষেপ বিবেচনা করেছেন। এটি আনুমানিক কাজ করে তবে যখন আমি ব্রাউজারের ইনপ্রাইভেট ব্রাউজিং / ছদ্মবেশী মোড ব্যবহার করি তখন সেশনটি হাইজ্যাক করা হয়। আপনি দয়া করে সেশনআইড স্ট্রিংয়ে যোগ করার জন্য কোনও অতিরিক্ত জিনিস প্রস্তাব করতে পারেন?
বিশ্বনাথ মিশ্র

4

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


3

সেশন হাইজ্যাকের বিরুদ্ধে সুরক্ষা তৈরির অনেকগুলি উপায় রয়েছে, তবে এগুলির সমস্তই হয় ব্যবহারকারী সন্তুষ্টি হ্রাস করছে বা নিরাপদ নয়।

  • আইপি এবং / অথবা এক্স-ফরওয়ার্ড-চেকগুলির জন্য। এই কাজগুলি, এবং বেশ সুরক্ষিত ... তবে ব্যবহারকারীদের বেদনা কল্পনা করুন। তারা ওয়াইফাই সহ একটি অফিসে আসে, তারা নতুন আইপি ঠিকানা পায় এবং সেশনটি হারাবে। আবার লগ ইন করতে পেরেছি।

  • ব্যবহারকারী এজেন্ট চেক। উপরের মতোই, ব্রাউজারের নতুন সংস্করণটি বাইরে চলে গেছে এবং আপনি একটি সেশন হারাবেন। অতিরিক্তভাবে, এগুলি "হ্যাক" করা সত্যিই সহজ। হ্যাকারদের পক্ষে নকল ইউএ স্ট্রিং প্রেরণ করা তুচ্ছ।

  • স্থানীয় স্টোরেজ টোকেন। লগ অন অন টোকেন উত্পন্ন, ব্রাউজার স্টোরেজ এ সঞ্চয় করুন এবং এটি এনক্রিপ্ট করা কুকি (সার্ভার সাইড এ এনক্রিপ্ট) এ সঞ্চয় করুন। এটির ব্যবহারকারীর জন্য কোনও পার্শ্ব-প্রতিক্রিয়া নেই (ব্রাউজার আপগ্রেডের মাধ্যমে লোকালস্টোরেশন বজায় থাকে)। এটি এতটা নিরাপদ নয় - এটি কেবল অস্পষ্টতার মধ্য দিয়ে সুরক্ষা। এটিকে আরও অস্পষ্ট করার জন্য আপনি জেএসে কিছু যুক্তি (এনক্রিপশন / ডিক্রিপশন) যুক্ত করতে পারেন।

  • কুকি পুনরায় বিতরণ। এটি সম্ভবত এটি করার সঠিক উপায়। কৌশলটি হ'ল কেবলমাত্র একটি ক্লায়েন্টকে একবারে কুকি ব্যবহার করার অনুমতি দেওয়া। সুতরাং, সক্রিয় ব্যবহারকারীর প্রতি ঘন্টা বা তারও কম সময়ে আবার কুকি দেওয়া হবে। পুরানো কুকি যদি নতুন জারি করা হয় তবে তা অবৈধ। হ্যাকগুলি এখনও সম্ভব, তবে করা আরও কঠিন - হ্যাকার বা বৈধ ব্যবহারকারীর দ্বারা অ্যাক্সেস প্রত্যাখ্যান করা হবে।


1

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


3
তবে আপনি কীভাবে ক্লায়েন্টের পক্ষে এই লবণ সংরক্ষণ করতে চান যে কেউ এটি চুরি করতে পারে না?
Dcortez

1

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

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

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

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

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpSession session = request.getSession();
    String sessionKey = (String) session.getAttribute("sessionkey");
    String remoteAddr = request.getRemoteAddr();
    int remotePort = request.getRemotePort();
    String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
    if (sessionKey == null || sessionKey.isEmpty()) {
        session.setAttribute("sessionkey", sha256Hex);
        // save mapping to memory to track which user attempted
        Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
    } else if (!sha256Hex.equals(sessionKey)) {
        session.invalidate();
        response.getWriter().append(Application.userSessionMap.get(sessionKey));
        response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId()); 
        response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
        return;
    }
    response.getWriter().append("Valid Session\n");
}

আমি SHA-2 অ্যালগরিদমকে SHAD-256 হ্যাশিংয়ে বেলডুঙে দেওয়া উদাহরণ ব্যবহার করে মানটি হ্যাশ করতে ব্যবহার করেছি

আপনার মন্তব্যের প্রত্যাশায়


@ জাফ আমি দুঃখিত, তবে আমি সুনাম অর্জনের উত্তরটি যোগ করি নি। পয়েন্টটি SHA-2 এনক্রিপশনও নয়। তবে সত্য যে আমি অন্য ব্যবহারকারীর সেশন আইডি কুকির ব্যবহার অন্য ব্যবহারকারীর সেশনে, যেমন, আসল প্রশ্নের মতো সেশন হাইজ্যাকিংয়ের ব্যবহার সনাক্ত করতে সক্ষম হয়েছি। আমি আমার সমাধানটি পরীক্ষা করে দেখেছি এটি কার্যকর হয়েছে। তবে আমি এতে বিশেষজ্ঞ নই, তাই আমি সম্প্রদায়টি আমার উত্তরটি যথেষ্ট ভাল কিনা তা পরীক্ষা করতে চাই। হতে পারে আপনি আমার কোড স্নিপেটটি কী দেখতে পারেন এবং এটি প্রশ্নের উত্তর দেয় কিনা তা সিদ্ধান্ত নিতে পারেন। ধন্যবাদ!
জেজেফ 13

@ জাফ ভুলটি নির্দেশ করার জন্য আপনাকে ধন্যবাদ আপনার পরামর্শ অনুসারে আমি আমার উত্তর আপডেট করেছি। উত্তরটি সহায়ক মনে হয় দয়া করে আপনার ডাউন ভোটটি সরিয়ে দিন।
জেজেফ

0

ঝুঁকি হ্রাস করতে আপনি সেশনটির সাথে উত্সপ্রাপ্ত আইপিও যুক্ত করতে পারেন। এইভাবে সেশনটি ব্যবহার করতে সক্ষম হওয়ার জন্য আক্রমণকারীকে একই বেসরকারী নেটওয়ার্কের মধ্যে থাকতে হবে।

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


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

1
পিএইচপি-নুকের তাদের অধিবেশন পদ্ধতির বিষয়ে একটি ভাল পৃষ্ঠা রয়েছে এবং আইপি-তে এটি কীভাবে হুক করা যায় তা সমস্ত ISP- এর সাথে কাজ করে না সে সম্পর্কে তারা বিশদ সাথে কথা বলেন phpnuke.org/…
সিম্বিয়েন্স

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

1
কিছুটা পুরানো পোস্ট তবে এটিকে আরও এগিয়ে। আইপি এর একটি খারাপ ধারণা উল্লেখ করা হয়। যেমন উল্লিখিত মোবাইল ব্যবহারকারীরা আইপি এর ঘোরাঘুরি করতে থাকে। অতীতে কিছু আইএসপি'রও আইপি এর রোমিং ছিল (যেমন এওএল) তবে আইপিভি 4 আইপি এর ঘাটতির সাথে এখন এই পদ্ধতিটি আরও জনপ্রিয় হয়ে উঠছে। এই জাতীয় আইএসপি'র প্লাস নেট এবং বিটি অন্তর্ভুক্ত রয়েছে
পিটার

-15

দ্বারা সুরক্ষিত:

$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;

12
আপনি এখানে কি করছেন তা দেখতে আমি ব্যর্থ।
সামায়ো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.