পিএইচপি সেশন নিরাপত্তা

পিএইচপি সহ দায়বদ্ধ সেশন নিরাপত্তা বজায় রাখার জন্য কিছু নির্দেশিকা কি? সমস্ত ওয়েব জুড়ে তথ্য আছে এবং এটি সব সময় এক জায়গায় অবতরণ সময়!

0
যোগ সম্পাদিত
মতামত: 2

14 উত্তর

এখানে আপনি কি মনে করেন আপনি কি করতে হবে

WP 3.0 এর সাথে নতুন "মাস্টার" ডোমেনে একটি নতুন মাল্টি সাইট ব্লগ তৈরি করুন

একটি নতুন খালি ব্লগটি তৈরি করুন url h..p: //www.mysite.com/oldblogname

নতুন ব্লগ আপনার পুরাতন সাইট এবং ইনপুট ইনপোর্ট রপ্তানি

আপনি যে সমস্ত ছবি নতুন সাইটতে কপি করবেন তা পরীক্ষা করতে হবে ঠিক আছে অন্যথায় ছবিগুলি পরিবেশন করার জন্য পুরাতন ব্লগটি রাখুন

এবং আপনি আমার কাছে সুন্দর নতুন ব্লগ পাবেন

এটি পরিষ্কার রাখার জন্য আপনাকে পুরাতন URL থেকে নতুন URL এ 304 টি পুনঃনির্দেশ স্থাপন করা উচিত

এই ধরনের কিছু (পরীক্ষা করা উচিত নয়) পুরানো ব্লগ ফোল্ডারে .htacces ফাইলের মধ্যে

RewriteEngine on
#
RewriteRule ^(.*)$ http://www.websiteA.com/oldblogname/ $1 [R=301,L]
1
যোগ

আমি মনে করি প্রধান সমস্যাগুলির একটি (যা পিএইচপি 6 এ বর্ণিত হচ্ছে) register_globals। এখন $ _ অনুরোধ , $ _ GET অথবা $ _ POST </কোড ব্যবহার করতে register_globals এড়াতে ব্যবহৃত একটি সাধারণ পদ্ধতিতে ব্যবহার করা হয়। > অ্যারে

এটি করতে "সঠিক" উপায় (5.2 হিসাবে, এটি একটি ছোট বাগি যদিও, কিন্তু 6 হিসাবে স্থিতিশীল, যা শীঘ্রই আসছে) ফিল্টারগুলি

এর পরিবর্তে:

$username = $_POST["username"];

আপনি কি করবেন:

$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);

বা এমনকি এমনকি:

$username = filter_input(INPUT_POST, 'username');
0
যোগ
আমি সম্মত হই, এটি সম্পূর্ণভাবে প্রশ্নের উত্তর দেয় না, তবে প্রশ্নটি উত্তর অবশ্যই স্পষ্টভাবে PART। আবার, এই স্বীকারোক্তিমূলক উত্তরটিতে একটি বুলেট বিন্দুকে উজ্জ্বল করে, "রেজিস্টার গবর্লগুলি ব্যবহার করবেন না"। এই পরিবর্তে কি করতে হবে তা বলে।
যোগ লেখক cmcculloh, উৎস
সত্যি? তাহলে কেন স্বাক্ষরকৃত উত্তরগুলিতে তারা তালিকাভুক্ত বিশ্বব্যাপী ব্যবহার না করে উল্লেখ করে? যতক্ষণ পর্যন্ত সর্বাধিক রান-অফ-মিল ডেভেলপাররা চিন্তিত হয় না কেন, গ্লোবালগুলি নিবন্ধন করে এবং ভেরিয়েবল হ্যান্ডলিং গঠন করে "সেশনের" ছাতা অধীনে নাওলেও তা "সেশন" বস্তুর টেকনিক্যালি অংশ না হলেও?
যোগ লেখক cmcculloh, উৎস
এই সব প্রশ্নের কোন সম্পর্ক নেই।
যোগ লেখক The Pixel Developer, উৎস
-1 এই প্রশ্নের উত্তর দেয় না।
যোগ লেখক Tomas, উৎস

একটি নির্দেশিকা হল প্রতিটি সময় একটি সেশনের নিরাপত্তা স্তর পরিবর্তন করার জন্য session_regenerate_id কল করা। এই সেশন হাইজ্যাকিং প্রতিরোধ করতে সাহায্য করে।

0
যোগ

আমি আইপি এবং ইউজার এজেন্ট উভয় দেখতে হবে যদি তারা পরিবর্তন দেখতে

if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
    || $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
    //Something fishy is going on here?
}
0
যোগ
@scotts আমি আইপি অংশের সাথে একমত কিন্তু ব্রাউজারের আপগ্রেডের জন্য, তারা লগইন করার সময় সেশনটি সেট করবে যাতে আমি দেখতে পাই না যে তারা আবার লগইন করলে নতুন সেশন তৈরি না করেই ব্রাউজারটি আপগ্রেড করবে কীভাবে।
যোগ লেখক JasonDavis, উৎস
@jasondavis Chrome নামে একটি ব্রাউজার আছে
যোগ লেখক Pacerier, উৎস
আমি বিশ্বাস করি UserGagent এছাড়াও IE8 মধ্যে compatibly মোড মধ্যে টগল যখন পরিবর্তন করতে পারেন। এটি জাল এমনকি খুব সহজ।
যোগ লেখক Heather Herbert, উৎস
ব্যবহারকারীর লোড-সমৃদ্ধ প্রক্সি খামারের পিছনে আইপি স্থায়ীভাবে পরিবর্তিত হতে পারে।
যোগ লেখক Kornel, উৎস
হ্যাঁ কিন্তু ব্যবহারকারীদের সম্পর্কে যা স্ট্যাটিক আইপি ইক জি জিএম এবং প্রতি অর্ধ ঘন্টা পরিবর্তিত হয়েছে। সুতরাং, সেশন + হোস্ট নাম আইপি, যখন আইপি! = REMOTE_ADDR চেক হোস্ট এবং হোস্ট হোস্টিং eq তুলনা। 1২.1২.1২.হোল্যান্ড.এনএল-> যখন holand.nl == সত্য হয়। তবে কিছু হোস্টের আইপি ভিত্তিক হোস্টেঞ্জের প্রয়োজন তারপর 88.99.২XXXX মাস্ক তুলনা করা প্রয়োজন
যোগ লেখক user956584, উৎস
এবং user_agent প্রত্যেকবার একটি ব্যবহারকারী তাদের ব্রাউজার আপগ্রেড করতে পারেন পরিবর্তন করতে পারেন।
যোগ লেখক scotts, উৎস

আপনার সেশন নিরাপদ রাখতে কিছু জিনিস আছে:

  1. ব্যবহারকারীদের প্রমাণীকরণ বা সংবেদনশীল ক্রিয়াকলাপ সম্পাদন করার সময় SSL ব্যবহার করুন।
  2. যখন নিরাপত্তা স্তর পরিবর্তন হয় (যেমন লগ ইন হিসাবে) তখন সেশন আইডি পুনরায় তৈরি করুন আপনি যদি ইচ্ছা করেন তবে আপনি প্রতিটি অনুরোধে সেশন আইডি পুনরায় তৈরি করতে পারেন।
  3. সেশন টাইম আউট আছে
  4. তালিকাভুক্ত গ্লোবাল ব্যবহার করবেন না
  5. সার্ভারের পাসওয়ার্ড প্রমাণীকরণের বিবরণ যে, কুকিতে ইউজারনেমের মতো বিবরণ পাঠাতে না।
  6. $ _ সার্ভার ['HTTP_USER_AGENT'] চেক করুন। এই অধিবেশন হাইজ্যাকিংয়ের জন্য একটি ছোট বাধা যোগ করে। আপনি আইপি ঠিকানা চেক করতে পারেন তবে এটি ব্যবহারকারীদের জন্য সমস্যার কারণ যা একাধিক ইন্টারনেট সংযোগ ইত্যাদি লোড ব্যালেন্সের কারণে IP ঠিকানা পরিবর্তন করে (যা এখানে আমাদের পরিবেশে ক্ষেত্রে)।
  7. ফাইল সিস্টেমে সেশনের অ্যাক্সেস বন্ধ করুন বা কাস্টম শাথ পরিচালনা ব্যবহার করুন
  8. সংবেদনশীল অপারেশনের জন্য ব্যবহারকারীদের তাদের অস্থায়ী বিবরণগুলি পুনরায় সরবরাহের জন্য লগ ইন করা প্রয়োজন
0
যোগ
যদি আপনি সেশন আইডি পুনর্নির্মাণ করেন তবে সেভিটি আইডি যা একটি আক্রমণকারী অ-HTTPS অনুরোধে চুরি করে অর্থহীন হয়
যোগ লেখক grom, উৎস
@The রুক, এটি একটি তুচ্ছ বাধা (আক্রমণকারী একটি শিকার এর ব্যবহারকারীর এজেন্ট তাদের নিজস্ব সাইট ব্যবহার করে ধরতে পারে) এবং দুর্বলতা মাধ্যমে নিরাপত্তা উপর নির্ভর করে কিন্তু এটি এখনও একটি অতিরিক্ত বাধা। যদি ব্যবহারকারীর এজেন্ট HTTPটি সেশনে ব্যবহারের সময় পরিবর্তন করা হতো, তাহলে এটি অত্যন্ত সন্দেহজনক এবং বেশিরভাগ হামলার সম্ভাবনা ছিল। আমি কখনোই বলেছি না যে তুমি এটা একা ব্যবহার করতে পারবে। যদি আপনি এটি অন্য কৌশল সঙ্গে একত্রিত আপনি একটি আরো নিরাপদ সাইট আছে।
যোগ লেখক grom, উৎস
@ দ্য রুক, হ্যাঁ, ব্যবহারকারীর এজেন্ট চিত্তাকর্ষক হতে পারে। এর মাত্র একটি ছোট ছোট বাধা এবং কোনও উপায়ে আপনি কি বলতে পারেন কুকিটি HTTP এর উপর লিক করা যেতে পারে। হ্যাঁ এটা চুরি করা যাবে। HTTP প্লেইন টেক্সট হয়।
যোগ লেখক grom, উৎস
@গ্রোম ব্যবহারকারী যখন ব্যবহারকারী ব্রাউজার ব্যবহার করছে তখন পটভূমিতে চুপচাপভাবে আপগ্রেড করলে Chrome স্বয়ংক্রিয়ভাবে ব্যবহারকারীর এজেন্টকে পরিবর্তন করবে না? এই ভাবে আপনি বাস্তব ব্যবহারকারীদের জন্য কোন বাস্তব ভাল কারণ বন্ধ ব্লক করা হয়। বর্ধিত ব্যবহারযোগ্যতা এছাড়াও উন্নত নিরাপত্তা হয় যে ভুলবেন না।
যোগ লেখক Pacerier, উৎস
@ গ্রোম আমি মনে করি এটা যেন আপনার দরজা জুড়ে স্ক্র্যাচ টেপের একটি টুকরো লাগানো এবং বলছে এটি লোকেদের ভেতর থেকে বিরত থেকে বিরত করবে।
যোগ লেখক rook, উৎস
@ গ্ররম আপনার মন একমাত্র বাধা, আপনি কোন আক্রমণ বন্ধ করা হয়।
যোগ লেখক rook, উৎস
আমি আশা করি আমি এসএসএল ব্যবহার করার জন্য আপনাকে অন্য -1 দিতে পারে। কোনও বিন্দুতে কুকিটি HTTP এর উপর লিক করা যেতে পারে, যেগুলি OWASP A3 তে বেরিয়েছে।
যোগ লেখক rook, উৎস
-1 ব্যবহারকারীর এজেন্ট স্পুফ থেকে তুচ্ছ। আপনি কি বর্জ্য কোড বর্ণনা করছেন এবং একটি নিরাপত্তা সিস্টেম নয়।
যোগ লেখক rook, উৎস
কিছু অপারেশনের জন্য শুধুমাত্র SSL ব্যবহার করা যথেষ্ট নয়, যদি না আপনি এনক্রিপ্ট করা এবং অ্যানক্রিপটেড ট্র্যাফিকের জন্য পৃথক সেশন না থাকে। যদি আপনি HTTPS এবং HTTP তে একক সেশন ব্যবহার করেন, আক্রমণকারী প্রথম অ-HTTPS অনুরোধে এটি চুরি করবে।
যোগ লেখক Kornel, উৎস
প্রতিটি অনুরোধে সেশনের পুনরুজ্জীবিত করবেন না। এটা জাতি অবস্থার জন্য সন্দিহান এবং আপনি খুব শীঘ্রই বা পরে সময় হারাবেন।
যোগ লেখক Kornel, উৎস
আমি pornel সঙ্গে একমত এছাড়াও, নম্বর 6 এর জন্য, যদি কোনও আক্রমণকারীর আপনার সেশন আইডি থাকে তবে তাদের কাছে আপনার ব্যবহারকারী এজেন্টের অ্যাক্সেস থাকবে না?
যোগ লেখক Chad, উৎস
যদি আপনি ব্যবহারকারী এজেন্ট চেক করছেন, তাহলে আপনি IE8 ব্যবহারকারীদের থেকে সমস্ত অনুরোধ ব্লক করবেন যখন তারা সামঞ্জস্য মোড টগল করবে। আমার নিজের কোডে আমি এই সমস্যাটি নিখরচায় মজা করে দেখুন: serverfault.com/questions/200018/ HTTP-302-সমস্যা-অন-ie7 । আমি ব্যবহারকারী এজেন্ট গ্রহণ করছি চেক আউট, কারণ এটি যেমন একটি তুচ্ছ জিনিস ঠক্ঠক্ শব্দ হিসাবে, অন্যদের বলেছে।
যোগ লেখক bestattendance, উৎস

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

এখানে একটি ভাল সেটাইটের উপর টিউটোরিয়াল () এবং clearTimer ()।

0
যোগ

আইপি অ্যাড্রেস ব্যবহার করা সত্যিই আমার অভিজ্ঞতাতে সেরা ধারণা নয়। উদাহরণ স্বরূপ; আমার অফিসে দুটি আইপি অ্যাড্রেস রয়েছে যা লোডের উপর ভিত্তি করে ব্যবহার করা হয় এবং আমরা IP ঠিকানাগুলি ব্যবহার করে ক্রমাগত সমস্যার সম্মুখীন হয়েছি।

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

0
যোগ

আমার দুই (বা আরও) সেন্ট:

  • কেউ বিশ্বাস করুন
  • ইনপুট ফিল্টার করুন, আউটপুট আউটপুট (কুকি, সেশন ডেটা আপনার ইনপুটও)
  • XSS এড়িয়ে চলুন (আপনার এইচটিএমএলটি সুবিন্যস্ত রাখুন, PHPTAL দেখুন বা HTMLPurifier ) করুন
  • গভীরতার মধ্যে সুরক্ষা
  • ডেটা প্রকাশ করবেন না

এই বিষয়ে একটি ছোট কিন্তু ভাল বই আছে: ক্রিস শিফট দ্বারা প্রয়োজনীয় পিএইচপি নিরাপত্তা

প্রয়োজনীয় পিএইচপি নিরাপত্তা http://shiflett.org/images/essential-php-security-small.png</একটি>

বইয়ের হোম পেজে আপনি কিছু আকর্ষণীয় কোড উদাহরণ এবং নমুনা অধ্যায় পাবেন।

You may use technique mentioned above (IP & UserAgent), described here:

How to avoid identity theft

0
যোগ
XSS- প্রতিরোধের জন্য +1 যেহেতু CSRF এর বিরুদ্ধে সুরক্ষা করা অসম্ভব, এবং এইভাবে সেশন আইডি এমনকি সেশন ছাড়া কেউ "সাইড" করতে পারে।
যোগ লেখক Kornel, উৎস

আপনি যদি session_set_save_handler() ব্যবহার করেন তবে আপনি আপনার নিজের সেশন হ্যান্ডলার সেট করতে পারেন। উদাহরণস্বরূপ, আপনি ডাটাবেসের মধ্যে আপনার সেশন সঞ্চয় করতে পারে। একটি ডাটাবেস সেশন হ্যান্ডলার উদাহরণ জন্য php.net মন্তব্য পড়ুন।

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

0
যোগ

This session fixation paper has very good pointers where attack may come. See also session fixation page at Wikipedia.

0
যোগ

php.ini

session.cookie_httponly = 1
change session name from default PHPSESSID

ek অ্যাপার্যাব হেডার যোগ করুন:

X-XSS-Protection    1
0
যোগ
সচেতন থাকুন যে X-XSS- সুরক্ষা সত্যিই সব সময়ে দরকারী নয় আসলে, সুরক্ষিত অ্যালগরিদমটি আসলেই শোষিত হতে পারে, এটি আগের চেয়ে আরও খারাপ করে তুলছে
যোগ লেখক Pacerier, উৎস
তুমি কি বিস্তারিত বলতে পারো?
যোগ লেখক domino, উৎস
httpd.conf -> হেডার সেট X-XSS- সুরক্ষা "1" </ FilesMatch>
যোগ লেখক user956584, উৎস

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

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

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

0
যোগ

আপনি সেশন তথ্য নিরাপদ নিশ্চিত করা প্রয়োজন। আপনার php.ini অথবা phpinfo() ব্যবহার করে আপনি অধিবেশন সেটিংস খুঁজে পেতে পারেন। _session.save_path_ আপনাকে বলছে সে কোথায় সংরক্ষিত হবে।

ফোল্ডার এবং তার পিতা-মাতার অনুমতি পরীক্ষা করে দেখুন। এটি পাবলিক (/ tmp) না হওয়া উচিত বা আপনার ভাগ করা সার্ভারে অন্য ওয়েবসাইটের দ্বারা অ্যাক্সেসযোগ্য হবে না।

ধরুন আপনি এখনও PHP session ব্যবহার করতে চান, আপনি _session.save_path_ পরিবর্তন করে _session.save_handler_ পরিবর্তন করে ডেটাতে তথ্য সংরক্ষণ করতে অন্য একটি ফোল্ডার ব্যবহার করতে PHP সেট করতে পারেন।

আপনি আপনার php.ini (কিছু প্রদানকারীরা এটির অনুমতি) বা apache + mod_php- এ আপনার সাইটে root ফোল্ডারে একটি .htaccess ফাইলের মধ্যে _session.save_path_ সেট করতে সক্ষম হতে পারে: php_value session.save_path "/home/example.com/html/session" । আপনি _session_save_path() _ এর সাথে রান সময় সেট করতে পারেন

চেক করুন ক্রিস শিফটট এর টিউটোরিয়াল বা Zend_Session_SaveHandler_DbTable সেট করতে এবং বিকল্প শাথ হ্যান্ডলার।

0
যোগ

আমি এই মত আমার সেশন আপ সেট -

লগ ইন পৃষ্ঠায়:

$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);

(একটি কনফিগ পাতা সংজ্ঞায়িত ফ্রেজ)

তারপর শিরোনাম যে বাকি সাইট জুড়ে হয়:

session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
    header('Location: http://website login page/');
    exit();     
}
0
যোগ