সাধারণ পিএইচপি সেটআপ নিরাপত্তাহীনতা?

Question

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

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

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

একটি সহজ উদাহরণ:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

ইহা কি একটি সাধারণ সমস্যা? এবং আপনি সাধারণত এটি কীভাবে সমাধান করবেন?

হালনাগাদ:

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

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

Comments

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

— ল্যাজে মেজেস্টে

আমি open_basedirপ্রোডাকশন শেয়ার্ড হোস্টিং সিস্টেমে নীচের সমাধানটি ব্যবহার করেছি , তবে আমরা সবাইকে তাদের নিজস্ব

— ভোস্টে

Answer 1

যে কেউ suphp ব্যবহার করতে পারে যা তার মালিকের uid দিয়ে পিএইচপি স্ক্রিপ্ট চালায়।

http://www.suphp.org

Comments

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

— ভোরেটাক 7

@ ভোরেটাক 7: আরও কয়েকটি বিধিনিষেধ প্রয়োগ করা যেতে পারে। যতদূর আমি মনে করি আপনি নিজের মালিকানাযুক্ত ফাইলগুলিতে অ্যাক্সেসও অস্বীকার করতে পারেন। সুতরাং এটি উপরোক্ত আক্রমণটিকে বাতিল করে।

— সিস্টামস

আমি জানি যে আপনি ফাইলগুলিতে অনুমতিগুলি সীমাবদ্ধ করতে পারেন ("গ্রুপ / অন্যান্য / অন্য কেউ দ্বারা লিখিত হতে পারে না"), তবে এফএস অনুমতিগুলির বাইরে পাঠ্য অবরুদ্ধ করার কোনও উপায় আমি জানি না। তাদের কাছে রয়েছে check_vhost_docroot, তবে এএফআইএকি যা কেবলমাত্র সম্পাদিত স্ক্রিপ্টের ক্ষেত্রে প্রযোজ্য (? আমি এতে ভুল হতে পারি)

— ভোরেটাক 7

আমি নিশ্চিত নই যে এই জাতীয় পরিবেশে সুফপ একটি ভাল সমাধান কিনা solution কোনও ব্যবহারকারীর কাছে www- ব্যবহারকারীর কাছে সমস্ত ধরণের অনুমতি থাকতে পারে। একজন আক্রমণকারী যা পিএইচপি এর মাধ্যমে একটি উপায় খুঁজে পেয়েছিল সে এসএসএস কী বা কীট্যাবগুলি খুঁজে পেতে পারে বা ব্যবহারকারীর লগইন স্ক্রিপ্টগুলিকে ব্যাকডোর তৈরি করতে পারে। প্রধান "ভার্চুয়াল হোস্টে" / ~ ব্যবহারকারীর নাম "এর মাধ্যমে পাবলিক_এইচটিএমএল ডিরেক্টরি উপলব্ধ হওয়ায়" vhosts "সেটিংসটি সহায়ক নয়। আমি ভাবছি পাবলিক_এইচটিএমএল এর স্ক্রিপ্টগুলি সম্পূর্ণ অক্ষম করা উচিত।

— পন্টস

Answer 2

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

একটি ডিরেক্টরি কাঠামো যেমন:

/Client
    /auth
    /site
        /www_root
        /www_tmp

এই প্রয়োজনীয়তাটি পূরণ করবে: নিরাপদে open_basedirচিহ্নিত করা যেতে পারে /Client/siteএবং htpasswdফাইলগুলিতে সঞ্চিত থাকতে পারে /Client/auth( .htaccessফাইলগুলির সাথে বা httpd.confপরিবর্তে উপযুক্ত স্থানে নির্দেশ করতে সংশোধিত)।
এটি আপনার ক্লায়েন্টদের অন্য কারও ফাইল খুলতে বাধা দেয় এবং সুবিধা হিসাবে ক্ষতিকারক ব্যবহারকারীরা স্টাফটিতে /Client/auth(বা আপনার সিস্টেমে অন্য কোনও কিছু যেমন /etc/passwd:-) পড়তে পারবেন না

ওপেন_বেসেডির এবং প্রতি-ভোস্ট বাস্তবায়নের বিষয়ে আরও তথ্যের জন্য http://php.net/manual/en/ini.core.php দেখুন ।

Comments

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

— voretaq7

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

— পন্টস

আমি open_basedir<< ডিরেক্টরি> নির্দেশিকাটির ভিতরে স্থাপনের চেষ্টা করি নি , তবে আমি মনে করি এটি অনুমোদিত হতে হবে ("এটি চেষ্টা করে দেখুন" - সবচেয়ে খারাপ এটি কাজ করতে পারে না :)

— ভোরেটাক 7

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

— ল্যাজে মেজেস্টে

Answer 3

না এটি কোনও সাধারণ সমস্যা নয় কারণ বেশিরভাগ ভাগীদার হোস্টগুলি প্রতিটি ব্যবহারকারীর পাবলিক_এইচটিএমএল ডিরেক্টরিতে (বা vhost এ যদি প্রতিটি ব্যবহারকারীর নিজস্ব vhost থাকে) htaccess ফাইলে একটি ওপেন-বেসডির কনফিগারেশন সংজ্ঞায়িত করে।

যেমন .htaccess ফাইল:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

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

আছে HTH

সি

Comments

এটি নতুন অ্যাকাউন্টগুলির কিছু প্রাথমিক সুরক্ষা সরবরাহ করতে সহায়তা করতে পারে। তবে কোনও ব্যবহারকারী এটি সম্পাদনা করতে পারে না তা .htaccess ফাইলটি সরানোর জন্য লোভনীয় করে তুলতে পারে (যা তারা করতে পারে যেহেতু এটিতে সর্বজনীন_এইচটিএমএল ডিরেক্টরিতে লেখার অ্যাক্সেস প্রয়োজন) এবং তাদের নিজস্ব তৈরি করতে পারে। প্রতিটি ব্যবহারকারীর জন্য মূল কনফিগারেশনে একটি "<ডিরেক্টরি>> -র ব্লক যুক্ত করা কাজ করবে তবে এখানে এখনও তাদের পিএইচপি থেকে বাহ্যিক কমান্ডগুলি ব্যাকটিক করার অনুমতি দেওয়া হয়েছে যার অর্থ ওপেন_ব্যাসাদির সহজেই সংক্ষিপ্ত হয়ে যায়।

— পন্টাস

@ পন্টাস: ফাইলটি মুছে ফেলার বিষয়ে ভাল পয়েন্ট (আফস্স অপরিবর্তনীয় ফাইল বৈশিষ্ট্য সমর্থন করে কিনা তা আমি নিশ্চিত নই)। আমি +1 দিয়েছি যদি আপনি বলে থাকেন যে ক্রুট কারাগারে ওয়েবসভারটি চালানো সমস্ত ধরণের প্রোগ্রামের প্রয়োগের দুর্বলতার বিরুদ্ধে সুরক্ষা দেয়।

— সিমকাবিয়ান

Answer 4

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