পিএইচপি সরাসরি ফাইল অ্যাক্সেস প্রতিরোধ


166

আমার একটি পিএইচপি ফাইল রয়েছে যা আমি অন্তর্ভুক্ত হিসাবে একচেটিয়াভাবে ব্যবহার করব। সুতরাং আমি যুক্ত করার পরিবর্তে ইউআরএল টাইপ করে সরাসরি এটি অ্যাক্সেস করা হলে এটি কার্যকর করার পরিবর্তে একটি ত্রুটি ফেলে দিতে চাই।

মূলত পিএইচপি ফাইলে আমাকে নিম্নলিখিত হিসাবে একটি চেক করতে হবে:

if ( $REQUEST_URL == $URL_OF_CURRENT_PAGE ) die ("Direct access not premitted");

এটি করার কোনও সহজ উপায় আছে?


10
ডাইয়ের পরিবর্তে () আপনার 'হেডার পরীক্ষা করা উচিত ("HTTP / 1.1 404 ফাইল পাওয়া যায় নি", 404); থেকে প্রস্থান; '। এটি (কমপক্ষে অ্যাপাচে) সার্ভারটি স্বাভাবিক 404 পৃষ্ঠাটি ফিরিয়ে আনবে।
gnud

আমি পিএইচপি অন্তর্ভুক্ত ফাইলগুলিতে সরাসরি অ্যাক্সেস অক্ষম করার জন্য এখানে দুটি সহজ পদ্ধতি ব্যাখ্যা করেছি - কোডপিডি.ডিজিয়েবল -ডাইরেক্ট -অ্যাক্সেস
ফারুক আহমেদ মল্লিক

উত্তর:


173

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

Deny from all

আপনার যদি সার্ভারের প্রকৃত নিয়ন্ত্রণ থাকে তবে (এই উত্তরটি আমি প্রথম যখন লিখেছিলাম তার চেয়ে কম অ্যাপ্লিকেশনের জন্যও এই দিনগুলিতে বেশি সাধারণ), আপনার ওয়েব সার্ভার যে ডিরেক্টরিটি থেকে সার্ভারটি দিচ্ছে তার বাইরে যে ফাইলগুলি আপনি রক্ষা করতে চান সেগুলি আটকে রাখাই সর্বোত্তম পন্থা is । সুতরাং যদি আপনার অ্যাপ্লিকেশনটি থাকে /srv/YourApp/, তবে ফাইলগুলি পরিবেশন করার জন্য সার্ভারটি সেট করুন /srv/YourApp/app/এবং এতে অন্তর্ভুক্তগুলি অন্তর্ভুক্ত করুন /srv/YourApp/includes, সুতরাং আক্ষরিকভাবে এমন কোনও URL নেই যা এগুলি অ্যাক্সেস করতে পারে।


1
ধন্যবাদ, যেহেতু আমি যেখানে এই অ্যাপ্লিকেশনটি চালাচ্ছি সেই সার্ভারের উপরে আমার সম্পূর্ণ নিয়ন্ত্রণ রয়েছে, তাই আমি এই উত্তরটি দিয়েছিলাম is
অ্যাল্টারলাইফ

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

22
এই উত্তরের অংশ হিসাবে একটি উদাহরণ .htaccess ফাইল থাকা ভাল লাগবে।
গ্রাহাম লিয়া

7
<Files ~ "\.inc$"> Order Allow,Deny Deny from All </Files>
ড্রাকোর্যাট

11
@ জেমস: এছাড়াও, সকলেই মনে করেন না যে স্ট্যাক ওভারফ্লো একটি "প্লিজ সেন্ড তেহ কোডজ" সাইট হওয়া উচিত। যদি এটি প্রশ্নের উত্তর পরিষ্কার করে দেয় তবে এটি একটি ভাল উত্তর। একটি উদাহরণ প্রদান করা যেখানে কোনওটিরই প্রয়োজন নেই কেবল অনুলিপি-এবং-পেস্ট কোডিংকে উত্সাহ দেয়।
চক

188

আপনি কেবল অন্তর্ভুক্ত করতে চান এমন পৃষ্ঠায় এটি যুক্ত করুন

<?php
if(!defined('MyConst')) {
   die('Direct access not permitted');
}
?>

তারপরে এটি যুক্ত হওয়া পৃষ্ঠাগুলিতে

<?php
define('MyConst', TRUE);
?>

3
আমার সত্যিই দ্রুত টাইপ করা শিখতে হবে। এটি আমি একইভাবে প্রস্তাব করব, এটি চেক করার জন্য একটি ভেরিয়েবল ব্যবহার করে এমন পদ্ধতির চেয়ে এটি আরও সুরক্ষিত। যেহেতু কিছু পিএইচপি সেটআপের সাহায্যে ভেরিয়েবলটিকে ওভাররাইড করা সম্ভব।
মার্ক ডেভিডসন

3
কয়েকটি 'মূলধারার' অ্যাপ্লিকেশন এটিকে পরিচালনা করে। আমি জানি জুমলা এইভাবে এটি করে এবং আমি ভিকি, ওয়ার্ডপ্রেস এবং অন্যদেরও মনে করি।
UnkwnTech

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

7
কেবল একটি 404 শিরোলেখ প্রেরণ করুন এবং প্রস্থান করুন - ত্রুটি পৃষ্ঠাটি স্বাভাবিক 404 পৃষ্ঠাগুলির মতো দেখাবে (কমপক্ষে অ্যাপাচে)।
gnud

4
@ হাসি.হুন্টার: এটি আপনার অন্তর্ভুক্ত / লাইব্রেরি স্ক্রিপ্ট ফাইলগুলি সরাসরি দেখার অ্যাক্সেসকে ব্লক করার বিষয়ে, উত্তরটি কাজ করে। যদি তারা somefile.phpআপনার সার্ভারে তৈরি করে এবং এতে আপনার সংজ্ঞাটি যুক্ত করে, তবে এটি তাদের সরাসরি অন্তর্ভুক্ত ফাইলটিতে অ্যাক্সেস করতে দেয় না। এটি তাদের আপনার লাইব্রেরি ফাইলগুলিকে "অন্তর্ভুক্ত" করতে দেবে, তবে তারা যদি আপনার সার্ভারে ফাইলগুলি তৈরি করতে এবং আপনার সংজ্ঞায়িত / স্ক্রিপ্টগুলি অন্তর্ভুক্ত করে জানার জন্য যথেষ্ট পরিমাণে পায় তবে আপনার অন্যান্য সমস্যা রয়েছে যা সম্ভবত প্রথম স্থানে আপনার সংজ্ঞায়িত করে তাদের নিজস্ব ফাইল লেখার বিষয়টি অস্বীকার করে ।
জেমস

114

আমার কাছে একটি ফাইল রয়েছে যা যখন এটি সরাসরি অ্যাক্সেস করা হয় যখন বনাম অন্তর্ভুক্ত করা হয় তখন আমার আলাদাভাবে অভিনয় করা প্রয়োজন ( এখানে একটি print()বনাম return()) এখানে কিছু সংশোধিত কোড দেওয়া হয়েছে:

if(count(get_included_files()) ==1) exit("Direct access not permitted.");

অ্যাক্সেস করা ফাইলটি সর্বদা একটি অন্তর্ভুক্ত ফাইল, তাই == 1।  


12
এটি আসলে একটি ধারণার নরক, অন্তর্ভুক্ত ফাইল গণনা পরীক্ষা করে। আমি ভাবছি কোনটি ভাল: সংজ্ঞায়িত ব্যবহার করে, বা এই পদ্ধতিটি ব্যবহার করে? এটি আরও স্ব-অন্তর্নিহিত বলে মনে হচ্ছে।
আকোই মেক্সেক্স

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

এটি সত্যিই দুর্দান্ত কারণ সমস্ত। পিএইচপি ফাইলগুলি ব্লক করতে .htaccess ব্যবহার করা সমস্ত সময় সম্ভব না হতে পারে কারণ একই ডিরেক্টরিতে কিছু ফাইল থাকতে পারে যা সরাসরি বা জাভাস্ক্রিপ্ট দ্বারা কল করা প্রয়োজন। এই দুর্দান্ত ধারণা জন্য ধন্যবাদ!
অনুজ

3
এটি কেবল পিএইচপি 5 এবং তারপরে কাজ করে। প্রাক-
পিএইচপি

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

34

ফাইলগুলিতে সরাসরি অ্যাক্সেস রোধ করার সর্বোত্তম উপায় হ'ল ওয়েব-সার্ভার নথি রুটের বাইরে রাখা (সাধারণত, উপরে একটি স্তর)। আপনি এখনও এগুলিকে অন্তর্ভুক্ত করতে পারেন তবে কোনও http অনুরোধের মাধ্যমে কেউ এগুলি অ্যাক্সেস করার সম্ভাবনা নেই।

আমি সাধারণত সমস্ত পথে যাই, এবং আমার সমস্ত পিএইচপি ফাইলগুলি ডকুমেন্টের মূলের বাইরে বুটস্ট্র্যাপ ফাইলের পাশে রাখি - ডকুমেন্টের রুটে একটি একক সূচক.এইচপিপি যা পুরো ওয়েবসাইট / অ্যাপ্লিকেশনটিতে রাউটিং শুরু করে।


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

3
প্রতিটি হোস্টিং সরবরাহকারীর সাথে আমি কাজ করেছিলাম আমার কাছে ডকুমেন্টের মূলের এক স্তরের (সর্বদা) অ্যাক্সেস ছিল।
ইরান গাল্পেরিন

3
কিছু হোস্টে (আমার বর্তমান একটি সহ) আপনি নিজের ডোমেনটি যে কোনও ফোল্ডারে চান তা নির্দেশ করতে পারেন।
দিনাহ

1
এটি পাশাপাশি একটি ভাল বিকল্প .. প্রেগ_ম্যাচ ব্যবহার করে -> যদি (প্রেগ_ম্যাচ ("~ গ্লোবাল ফাইল \। Php ~ i", $ _SERVER ['পিএইচপিএসএলএফ'])) {ডাই ('<h3 স্টাইল = "রঙ: লাল">) অ্যাপ্লায়েন্স সুরক্ষা সতর্কতা - সরাসরি অ্যাক্সেস অনুমোদিত নয়! আপনার আইপি লগ হয়েছে! <h3> '); // আরও কার্যকর করা বন্ধ করুন}
মার্কোজেইন

সেই url devzone.zend.com/node/view/id/70 এখন 404। উত্তরে সেই কোডটি অন্তর্ভুক্ত করা উচিত যা মূলত সেই অ-অস্তিত্বশীল url থেকে ব্যবহৃত হয়েছিল।
ফানকি চল্লিশ নাইনার

31

1: অন্তর্ভুক্ত ফাইলগুলির গণনা পরীক্ষা করা হচ্ছে

if( count(get_included_files()) == ((version_compare(PHP_VERSION, '5.0.0', '>='))?1:0) )
{
    exit('Restricted Access');
}

যুক্তি: পিএইচপি যদি সর্বনিম্ন অন্তর্ভুক্ত গণনাটি পূরণ না করে তবে প্রস্থান করে। নোট করুন যে পিএইচপি 5 এর আগে, বেস পৃষ্ঠাকে অন্তর্ভুক্ত হিসাবে বিবেচনা করা হয় না।


2: একটি গ্লোবাল ধ্রুবক সংজ্ঞায়িত এবং যাচাইকরণ

// In the base page (directly accessed):
define('_DEFVAR', 1);

// In the include files (where direct access isn't permitted):
defined('_DEFVAR') or exit('Restricted Access');

যুক্তি: যদি ধ্রুবকটি সংজ্ঞায়িত না করা হয়, তবে নির্বাহটি বেস পৃষ্ঠ থেকে শুরু হয় নি, এবং পিএইচপি মৃত্যুদন্ড কার্যকর করবে।

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

// Put the code in a separate file instead, say 'checkdefined.php':
defined('_DEFVAR') or exit('Restricted Access');

// Replace the same code in the include files with:
require_once('checkdefined.php');

এই ভাবে অতিরিক্ত কোড লগিং এবং বিশ্লেষণমূলক উদ্দেশ্যে, পাশাপাশি যথাযথ প্রতিক্রিয়া উত্পন্ন করার জন্য যুক্ত করা যেতে পারে checkdefined.php

ক্রেডিট যেখানে creditজমা আছে: বহনযোগ্যতার উজ্জ্বল ধারণাটি এই উত্তর থেকে এসেছে ।


3: দূরবর্তী ঠিকানা অনুমোদন

// Call the include from the base page(directly accessed):
$includeData = file_get_contents("http://127.0.0.1/component.php?auth=token");

// In the include files (where direct access isn't permitted):
$src = $_SERVER['REMOTE_ADDR']; // Get the source address
$auth = authoriseIP($src); // Authorisation algorithm
if( !$auth ) exit('Restricted Access');

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


4: টোকেন অনুমোদন

পূর্ববর্তী পদ্ধতির মতো, কেউ অন্তর্ভুক্ত ফাইলটিতে অনুমোদনের টোকেন পাস করতে GET বা POST ব্যবহার করতে পারেন:

if($key!="serv97602"){header("Location: ".$dart);exit();}

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


5: ওয়েবসভার নির্দিষ্ট কনফিগারেশন

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

উদাহরণস্বরূপ এপাচে, কনফিগারেশনটি .htaccessফাইলে সংরক্ষণ করা হয় । টিউটোরিয়াল এখানে

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


6: স্থাপনের একটি সুরক্ষিত ডিরেক্টরি অন্তর্ভুক্ত সাইট রুট বাইরে

সার্ভার পরিবেশে অ্যাক্সেস সীমাবদ্ধতার কারণে কমপক্ষে পছন্দ করা হয়েছে তবে ফাইল-সিস্টেমে আপনার অ্যাক্সেস থাকলে একটি শক্তিশালী পদ্ধতি।

//Your secure dir path based on server file-system
$secure_dir=dirname($_SERVER['DOCUMENT_ROOT']).DIRECTORY_SEPARATOR."secure".DIRECTORY_SEPARATOR;
include($secure_dir."securepage.php");

লজিক:

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

আমার অপ্রচলিত কোডিং কনভেনশন অনুগ্রহ করে দয়া করে। কোন প্রতিক্রিয়া প্রশংসা করা হয়।


আমি 2 নম্বরটি পছন্দ করি
বৌম ভুল

26

চকের সমাধানের বিকল্প (বা পরিপূরক) হ'ল আপনার .htaccess ফাইলে এই জাতীয় কিছু রেখে নির্দিষ্ট প্যাটার্নের সাথে মিলে যাওয়া ফাইলগুলিতে অ্যাক্সেস অস্বীকার করা হবে would

<FilesMatch "\.(inc)$">
    Order deny,allow
    Deny from all
</FilesMatch>

আমি বিশ্বাস করি .inc.php ব্যবহার করা আরও ভাল হবে, এবং এটি একটি সাধারণ অনুশীলন
লিস

14

আসলে আমার পরামর্শটি হ'ল এই সর্বোত্তম অভ্যাসগুলি করা।

  • ওয়েবরুট OR এর বাইরে ডকুমেন্টগুলি একটি ডিরেক্টরিতে রাখুন এবং ওয়েব সার্ভার অ্যান্ড দ্বারা অ্যাক্সেস অস্বীকার করা হয়েছে
  • আপনার দৃশ্যমান নথিগুলিতে একটি সংজ্ঞা ব্যবহার করুন যা লুকানো নথিগুলি যাচাই করে:
      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

এইভাবে যদি ফাইলগুলি কোনওভাবে ভুল জায়গায় স্থানান্তরিত হয় (ত্রুটিযুক্ত এফটিপি অপারেশন) তারা এখনও সুরক্ষিত থাকে।


8

আমার একবার এই সমস্যা হয়েছিল, এর সাথে সমাধান করা:

if (strpos($_SERVER['REQUEST_URI'], basename(__FILE__)) !== false) ...

তবে আদর্শ সমাধানটি হ'ল ওয়েব-সার্ভার ডকুমেন্টের মূলের বাইরে ফাইলটি রাখা, যেমনটি অন্য একটি আনসারে উল্লিখিত হয়েছিল।


7

আপনি একটি প্রবেশদ্বার সহ অ্যাপ্লিকেশনটি আরও ভালভাবে তৈরি করতে চাইবেন, অর্থাত্ সমস্ত ফাইল সূচি.পি.পি. থেকে পৌঁছানো উচিত

এটি index.php এ রাখুন

define(A,true);

এই চেকটি প্রতিটি সংযুক্ত ফাইলের মধ্যে চালানো উচিত (প্রয়োজনীয় বা অন্তর্ভুক্তের মাধ্যমে)

defined('A') or die(header('HTTP/1.0 403 Forbidden'));

7

আমি সরাসরি পিএইচপি ফাইলটিতে অ্যাক্সেস সীমাবদ্ধ রাখতে চেয়েছিলাম , তবে এটির মাধ্যমে কল করতেও সক্ষম হয়েছি jQuery $.ajax (XMLHttpRequest)। আমার জন্য যা কাজ করেছে তা এখানে।

if (empty($_SERVER["HTTP_X_REQUESTED_WITH"]) && $_SERVER["HTTP_X_REQUESTED_WITH"] != "XMLHttpRequest") {
    if (realpath($_SERVER["SCRIPT_FILENAME"]) == __FILE__) { // direct access denied
        header("Location: /403");
        exit;
    }
}

3

সবচেয়ে সহজ উপায় হ'ল কলগুলিতে অন্তর্ভুক্ত থাকা ফাইলগুলিতে কিছু পরিবর্তনশীল সেট করা

$including = true;

তারপরে যে ফাইলটি অন্তর্ভুক্ত করা হচ্ছে তাতে ভেরিয়েবলটি পরীক্ষা করে দেখুন

if (!$including) exit("direct access not permitted");

2
এটি যদি বিপজ্জনক হয় তবে যদি রেজিস্টার_গ্লোবালগুলি চালু থাকে।
jmucchiello

25
পিএইচপি বিপজ্জনক যদি রেজিস্টার_গ্লোবালগুলি চালু থাকে।
ডেভিড প্রিজিয়াস

3

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

app/
 |
 +--pub/
 |
 +--lib/
 |
 +--conf/
 |
 +--models/
 |
 +--views/
 |
 +--controllers/

আপনি পাব / ডকুমেন্ট রুট হিসাবে ব্যবহার করতে আপনার ওয়েব সার্ভার সেট আপ করেছেন। এটি আপনার স্ক্রিপ্টগুলিতে আরও ভাল সুরক্ষা সরবরাহ করে: যখন তারা প্রয়োজনীয় উপাদানগুলি লোড করতে ডকুমেন্টের মূল থেকে পৌঁছতে পারে তখন ইন্টারনেট থেকে উপাদানগুলি অ্যাক্সেস করা অসম্ভব। সুরক্ষা ছাড়াও আরেকটি সুবিধা হ'ল সবকিছুই এক জায়গায়।

এই সেটআপটি প্রতিটি অন্তর্ভুক্ত ফাইলটিতে কেবলমাত্র চেক তৈরির চেয়ে ভাল কারণ "অ্যাক্সেসের অনুমতি নেই" বার্তা আক্রমণকারীদের একটি চিহ্ন এবং এটি .htaccess কনফিগারেশনের চেয়ে ভাল কারণ এটি সাদা-তালিকা ভিত্তিক নয়: আপনি যদি ফাইলের এক্সটেনশানগুলি স্ক্রু করেন এটি lib /, conf / ইত্যাদি ডিরেক্টরিতে দৃশ্যমান হবে না।


দীর্ঘ সময় পরে আমি কেবল মন্তব্য করতে চাই যে আপনি উপরে বর্ণিত মডেলটিকে এমভিসি (মডেল - দেখুন - নিয়ন্ত্রণকারী) মডেল বলে। আপনি যদি দয়া করে, গুগল চেক করুন এবং আপনার উত্তরে আরও কিছু তথ্য যুক্ত করুন। এছাড়াও এমভিসি কেবল রেল এবং এএসপি.এনইটি অ্যাপ্লিকেশনগুলিতে নয়, পিএইচপি (ল্যাভেরেল, কেকপিএইচপি দেখুন) সমর্থন করে।

3

কী জুমলা! একটি রুট ফাইলে একটি কনস্ট্যান্টকে সংজ্ঞায়িত করা এবং অন্তর্ভুক্ত ফাইলগুলিতে একইরূপ নির্ধারিত কিনা তা পরীক্ষা করে দেখানো হয়।

defined('_JEXEC') or die('Restricted access');

অথবা

কোডআইগিনিটারের মতো বেশিরভাগ ফ্রেমওয়ার্ক যেমন সুপারমার্কেট হিসাবে সুপারিশ করা হয় সেহেতু ওয়েবরুট ডিরেক্টরিতে বাইরে রেখে সমস্ত ফাইল কোনও HTTP অনুরোধের নাগালের বাইরে রাখতে পারে keep

অথবা এমনকি অন্তর্ভুক্ত ফোল্ডার এবং রাইটিং বিধিগুলির মধ্যে একটি .htaccess ফাইল স্থাপন করে আপনি সরাসরি অ্যাক্সেস প্রতিরোধ করতে পারেন।



3

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

  1. .htaccess এবং অ্যাপাচি সীমাবদ্ধতার জন্য নিশ্চিত
  2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

তা যেdefined or die পদ্ধতির ব্যর্থতার একটি নম্বর আছে। প্রথমত, এটি পরীক্ষা করে এবং ডিবাগ করার অনুমানগুলির মধ্যে একটি আসল ব্যথা। দ্বিতীয়ত, এটি আপনার ভীতি পরিবর্তন করে যদি মনের অদ্ভুতভাবে বিরক্তিকর রিফ্যাক্টরিং জড়িত। "খুঁজুন ও প্রতিস্থাপন করুন!" তুমি বলো. হ্যাঁ, তবে আপনি কতটা নিশ্চিত যে এটি সর্বত্র হুটো ঠিক একই রকম লেখা হয়েছে, হুমম্ম? এখন এটি হাজার হাজার ফাইলের সাথে গুন করুন ... ওও

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

সুতরাং আমি জানি যে প্রশ্নটি "সবচেয়ে সহজ" জন্য জিজ্ঞাসা করেছে, তবে আমি মনে করি এটির জন্য "ডিফেন্সিভ কোডিং" বেশি প্রয়োজন।

আমার পরামর্শটি হ'ল:

  1. আপনার কোনও স্ক্রিপ্টের আগে require('ifyoulieyougonnadie.php');(এর পরিবর্তে নয় include() এবং হিসাবে defined or die)
  2. ইন ifyoulieyougonnadie.php, কিছু যুক্তিযুক্ত জিনিসগুলি করুন - বিভিন্ন ধ্রুবকগুলি, কলিং স্ক্রিপ্ট, লোকালহোস্ট টেস্টিং এবং এর জন্য পরীক্ষা করুন - এবং তারপরে আপনার die(), throw new Exception, 403ইত্যাদি বাস্তবায়ন করুন

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

    তবে আমি কী নতুন এন্ট্রি পয়েন্ট যুক্ত করব? কোন চিন্তা করো না. আমি কেবল পরিবর্তন করেছি ifyoulieyougonnadie.phpএবং আমার বাছাই করা হয়েছে, আরও 'সন্ধান এবং প্রতিস্থাপন' করব না। হুররে!

    আমি যদি কিছু স্ক্রিপ্টগুলি আলাদা কাঠামোতে একই ধ্রুবক না রাখার সিদ্ধান্ত নিয়েছি defined()? ... হুররে! ^: _ ^

আমি পেয়েছি এই কৌশলটি বিকাশকে আরও মজাদার এবং অনেক কম করে তোলে:

/**
 * Hmmm... why is my netbeans debugger only showing a blank white page 
 * for this script (that is being tested outside the framework)?
 * Later... I just don't understand why my code is not working...
 * Much later... There are no error messages or anything! 
 * Why is it not working!?!
 * I HATE PHP!!!
 * 
 * Scroll back to the top of my 100s of lines of code...
 * U_U
 *
 * Sorry PHP. I didn't mean what I said. I was just upset.
 */

 // defined('_JEXEC') or die();

 class perfectlyWorkingCode {}

 perfectlyWorkingCode::nowDoingStuffBecauseIRememberedToCommentOutTheDie();

2

যদি আরও সুনির্দিষ্টভাবে বলা যায় তবে আপনার এই শর্তটি ব্যবহার করা উচিত:

if (array_search(__FILE__, get_included_files()) === 0) {
    echo 'direct access';
}
else {
    echo 'included';
}

get_incused_files () সমস্ত অন্তর্ভুক্ত ফাইলের নামযুক্ত সূচকযুক্ত অ্যারে প্রদান করে (যদি ফাইলটি নির্বাহ করা হয় তবে তা অন্তর্ভুক্ত করা হয়েছিল এবং এর নাম অ্যারেতে রয়েছে)। সুতরাং, যখন ফাইলটি সরাসরি অ্যাক্সেস করা হয়, এর নাম অ্যারেতে প্রথম হয়, অ্যারের অন্যান্য সমস্ত ফাইল অন্তর্ভুক্ত ছিল।


1
<?php
if (eregi("YOUR_INCLUDED_PHP_FILE_NAME", $_SERVER['PHP_SELF'])) { 
 die("<h4>You don't have right permission to access this file directly.</h4>");
}
?>

উপরের কোডটি আপনার অন্তর্ভুক্ত পিএইচপি ফাইলের শীর্ষে রাখুন।

উদা:

<?php
if (eregi("some_functions.php", $_SERVER['PHP_SELF'])) {
    die("<h4>You don't have right permission to access this file directly.</h4>");
}

    // do something
?>

যদি (preg_match ("~ Globalfile f। php ~ i", $ _SERVER ['PHP_SELF'])) {ডাই ('<h3 স্টাইল = "রঙ: লাল"> অ্যাপ্লিকেশন সুরক্ষা সতর্কতা - সরাসরি প্রবেশ নিষিদ্ধ! আপনার আইপি লগ করা হয়েছে ! <h3> '); // আরও কার্যকর করা বন্ধ করুন} whre ~ হ'ল সীমানা
মার্কোজেইন

1

ফ্ল্যাটনাক্স সিএমএসে নিম্নলিখিত কোডটি ব্যবহার করা হয়েছে ( http://flatnux.altervista.org ):

if ( strpos(strtolower($_SERVER['SCRIPT_NAME']),strtolower(basename(__FILE__))) )
{
    header("Location: ../../index.php");
    die("...");
}

1

আমি এই পিএইচপি-কেবল এবং অদৃশ্য সমাধানটি পেয়েছি যা HTTP এবং ক্লিমে উভয়ই কাজ করে:

একটি ফাংশন সংজ্ঞায়িত করুন:

function forbidDirectAccess($file) {
    $self = getcwd()."/".trim($_SERVER["PHP_SELF"], "/");
    (substr_compare($file, $self, -strlen($self)) != 0) or die('Restricted access');
}

আপনি যে ফাইলটিতে সরাসরি অ্যাক্সেস আটকাতে চান তাতে ফাংশনটিতে কল করুন:

forbidDirectAccess(__FILE__);

এই প্রশ্নের উপরোক্ত বেশিরভাগ সমাধান ক্লায়াল মোডে কাজ করে না।


যেখানে এটি সিএলআই মোডে URL টাইপ করার কথা?
আপনার সাধারণ সংবেদন

এটি কেবল পিএইচপি স্ক্রিপ্টের প্রবর্তন / ক্লিপ মোডে অন্তর্ভুক্ত করার জন্য। একাধিক বিকাশকারী সহ একটি প্রকল্পে দরকারী হতে পারে।
কা।



1

ওয়েবে অ্যাক্সেসযোগ্য ডিরেক্টরি বাইরে আপনার অন্তর্ভুক্ত ফাইলগুলি সংরক্ষণ করার জন্য কয়েকবার উল্লেখ করা হয়েছে, এবং সম্ভবত এটি সম্ভব একটি ভাল কৌশল। যাইহোক, অন্য বিকল্পটি আমি এখনও উল্লেখ করে দেখিনি: আপনার অন্তর্ভুক্ত ফাইলগুলিতে কোনও চলমান কোড না রয়েছে তা নিশ্চিত করুন । যদি আপনার অন্তর্ভুক্ত ফাইলগুলি কেবল ফাংশন এবং ক্লাসগুলি সংজ্ঞায়িত করে এবং এর বাইরে অন্য কোনও কোড না থাকে তবে সরাসরি অ্যাক্সেস করা হলে এগুলি খালি পৃষ্ঠা তৈরি করবে will

ব্রাউজার থেকে এই ফাইলটিতে সরাসরি অ্যাক্সেসের অনুমতি দিন: এটি কিছুই করবে না । এটি কিছু ফাংশন সংজ্ঞায়িত করে, তবে তাদের কোনওটিকেই ডাকা হয় না, সুতরাং তাদের কোনওটিই চালিত হয় না।

<?php

function a() {
    // function body
}

function b() {
    // function body
}

এটি কেবলমাত্র পিএইচপি ক্লাস যুক্ত এমন ফাইলগুলিতে প্রযোজ্য এবং অন্য কিছুই নয়।


আপনার ফাইলগুলি যেখানে সম্ভব সেখানে ওয়েব ডিরেক্টরিের বাইরে রাখা এখনও একটি ভাল ধারণা।

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

0

এর মতো কিছু করুন:

<?php
if ($_SERVER['SCRIPT_FILENAME'] == '<path to php include file>') {
    header('HTTP/1.0 403 Forbidden');
    exit('Forbidden');
}
?>

এটি ব্রাউজারে লোড হতে আটকাবে না।
UnkwnTech

0

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

<?
if(!isset($_SERVER['HTTP_REQUEST'])) { include ('error_file.php'); }
else { ?>

আপনার অন্যান্য এইচটিএমএল কোডটি এখানে রাখুন

<? } ?>

এটি এর মতো শেষ করুন, সুতরাং ত্রুটির আউটপুট সর্বদা শরীরের বিভাগের মধ্যে প্রদর্শিত হবে, যদি আপনি এটির মতো এটি চান।


আমি বুঝতে পেরেছি যে সমস্ত HTTP_ * সার্ভার শিরোনামকে বিশ্বাস করা উচিত নয়, সুতরাং আপনি এই পদ্ধতিটি ব্যবহার না করা ভাল।
andreszs

0

আমি পরামর্শ দিচ্ছি যে $_SERVERসুরক্ষার কারণে ব্যবহার করবেন না ।
আপনি $root=true;প্রথম ফাইলের মতো একটি ভেরিয়েবল ব্যবহার করতে পারেন যাতে অন্য একটি অন্তর্ভুক্ত রয়েছে।
এবং isset($root)অন্তর্ভুক্ত করা হবে যে দ্বিতীয় ফাইলের শুরুতে ব্যবহার করুন।


0

আপনি যা করতে পারেন তা হ'ল পাসওয়ার্ড ডিরেক্টরিটি সুরক্ষা এবং আপনার সমস্ত পিএইচপি স্ক্রিপ্টগুলিকে সেখানে রাখুন, অবশ্যই index.php ফাইল ব্যতীত পাসওয়ার্ড অন্তর্ভুক্ত করার সময় প্রয়োজন হবে না কারণ এটি কেবলমাত্র http অ্যাক্সেসের প্রয়োজন হবে। এটি যা করবে তা হ'ল আপনার স্ক্রিপ্টগুলিতে অ্যাক্সেস করার অপশনও সরবরাহ করবে যদি আপনি এটি চান তবে যে ডিরেক্টরিতে অ্যাক্সেসের পাসওয়ার্ড আপনার হাতে থাকবে। আপনাকে ডিরেক্টরিটির জন্য .htaccess ফাইল এবং ব্যবহারকারীকে প্রমাণীকরণের জন্য একটি .htpasswd ফাইল সেটআপ করতে হবে।

ভাল, আপনি যদি মনে করেন যে এই ফাইলগুলি সাধারণত অ্যাক্সেস করার প্রয়োজন না হয় তবে আপনি সিপানেল ইত্যাদির মাধ্যমে সর্বদা এগুলি অ্যাক্সেস করতে পারবেন তবে উপরের যে কোনও সমাধান আপনি ব্যবহার করতে পারেন you

আশাকরি এটা সাহায্য করবে


0

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


0

.Htaccess এর সাথে পরামর্শগুলি আমি এত ভাল খুঁজে পাইনি কারণ এটি সেই ফোল্ডারে থাকা অন্য সামগ্রীগুলি ব্লক করতে পারে যা আপনি ব্যবহারকারীদের অ্যাক্সেস করার অনুমতি দিতে চাইতে পারেন, এটি আমার সমাধান:

$currentFileInfo = pathinfo(__FILE__);
$requestInfo = pathinfo($_SERVER['REQUEST_URI']);
if($currentFileInfo['basename'] == $requestInfo['basename']){
    // direct access to file
}

0
if ( ! defined('BASEPATH')) exit('No direct script access allowed');

কাজ মসৃণ করতে হবে


2
CodeIgnitor থেকে পেস্ট অনুলিপি করুন। এটি দুর্দান্ত তবে এটি নিজে থেকে কিছু করে না। BASEPATH const একটি সেট করা হয় index.phpযে ফাইলটি ট্রী কাঠামো নীচে টিম সীমানা। সিআই ইউআরএলগুলি পুনর্লিখন করে তাই কোনওভাবেই সরাসরি স্ক্রিপ্টগুলি অ্যাক্সেস করার প্রয়োজন নেই।
jimasun

আমি জানি কোন প্রয়োজন নেই তবে কেউ যদি
এটির

0

পিএইচপি সংস্করণ চেক সহ এর আগে উল্লিখিত সমাধানটি যুক্ত হয়েছে:

    $max_includes = version_compare(PHP_VERSION, '5', '<') ? 0 : 1;
    if (count(get_included_files()) <= $max_includes)
    {
        exit('Direct access is not allowed.');
    }

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