Zapobieganie bezpośredniemu dostępowi do pliku dołączającego php

Dodaj to do strony, która ma być uwzględniona

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

Następnie na stronach, które go zawierają dodaj

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

Mam plik, który muszę działać inaczej, gdy jest dołączony vs gdy jest dostępny bezpośrednio (głównie print() vs return()) Oto zmodyfikowany kod:

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

Dostęp do pliku jest zawsze dołączonym plikiem, stąd = = 1.  

Najlepszym sposobem, aby zapobiec bezpośredniemu dostępowi do plików, jest umieszczenie ich poza głównym serwerem (Zwykle o jeden poziom wyżej). Nadal możesz je dołączyć, ale nie ma możliwości, aby ktoś uzyskał do nich dostęp poprzez żądanie http.

Zwykle przechodzę całą drogę i umieszczam wszystkie moje pliki PHP poza głównym katalogiem dokumentu, oprócz pliku bootstrap - samotnego indeksu.php w katalogu głównym dokumentu, który rozpoczyna routing całej witryny/aplikacji.

1: sprawdzanie liczby dołączonych plików

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

Logika: PHP kończy działanie, jeśli minimalna liczba include nie jest spełniona. Zauważ, że przed PHP5 strona podstawowa nie jest uważana za include.

2: Definiowanie i weryfikowanie stałej globalnej

// 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');

Logika: Jeśli stała nie jest zdefiniowana, to wykonywanie nie rozpoczęło się od strony podstawowej i PHP przestałoby wykonywać.

Uwaga, że ze względu na przenośność między aktualizacjami i przyszłe zmiany, uczynienie tej metody uwierzytelniania modularnym znacznie zmniejszyłoby koszty kodowania, ponieważ zmiany nie będą musiały być kodowane na twardo do każdego pliku.

// 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');

W ten sposób można dodać dodatkowy kod do checkdefined.php do celów logowania i analitycznych, a także do generowania odpowiednich odpowiedzi.

kredyt, gdzie kredyt jest należny: genialny pomysł na przenośność przyszedł z to odpowiedź .

3: zdalna autoryzacja adresu

// 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');

Wadą tej metody jest wykonanie odosobnione, chyba że Token sesji dostarczony z wewnętrznym żądaniem. Zweryfikuj za pomocą adresu zwrotnego w pętli w przypadku konfiguracji pojedynczego serwera lub białej listy adresów dla infrastruktury serwerowej wieloserwerowej lub obciążonej.

4: Token autoryzacja

Podobnie jak poprzednia metoda, można użyć GET lub POST, aby przekazać token autoryzacji do pliku include:

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

Bardzo niechlujna metoda, ale być może najbardziej bezpieczna i wszechstronna w tym samym czasie, gdy jest używana we właściwy sposób.

5: Konfiguracja specyficzna dla serwera www

Większość serwerów umożliwia przypisywanie uprawnień do poszczególnych plików lub katalogów. Możesz umieścić wszystkie swoje pliki w takich zastrzeżonych katalogach i skonfigurować serwer tak, aby je odrzucał.

Na przykład w APACHE, konfiguracja jest przechowywana w pliku .htaccess. Tutorial tutaj .

zauważ jednak, że konfiguracje specyficzne dla serwera nie są przeze mnie zalecane, ponieważ są złe dla przenośności na różnych serwerach internetowych. W przypadkach, takich jak systemy zarządzania treścią, gdzie algorytm deny jest złożony lub lista odrzuconych katalogów jest dość duża, może to tylko sprawić, że sesje rekonfiguracji będą raczej makabryczne. W końcu najlepiej jest zająć się tym kodem.

6: umieszczenie zawartości w bezpiecznym katalogu Poza korzeniem strony

Najmniej preferowana ze względu na ograniczenia dostępu w środowiskach serwerowych, ale dość wydajna metoda, jeśli masz dostęp do systemu plików.

//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");

Logika:

• użytkownik nie może zażądać żadnego pliku poza folderem htdocs, ponieważ linki byłyby poza zakresem systemu adresowego witryny.
• serwer php uzyskuje natywny dostęp do systemu plików, a tym samym może uzyskać dostęp do plików na komputerze, tak jak normalny program z wymaganymi przywileje mogą.
• umieszczając pliki nagłówkowe w tym katalogu, możesz mieć pewność, że serwer php uzyska do nich dostęp, podczas gdy Hotlinkowanie zostanie zablokowane użytkownikowi.
• nawet jeśli konfiguracja dostępu do systemu plików serwera www nie została wykonana poprawnie, ta metoda zapobiegnie przypadkowemu upublicznieniu tych plików.

proszę wybaczyć moje niekonwencjonalne konwencje kodowania. Wszelkie opinie są mile widziane.

Alternatywą (lub dopełnieniem) rozwiązania Chucka byłoby zablokowanie dostępu do plików pasujących do określonego wzorca poprzez umieszczenie czegoś takiego w Twoim .plik htaccess

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

Właściwie, moja rada to robić wszystkie te najlepsze praktyki.

• Umieść dokumenty poza webroot lub w katalogu, do którego serwer nie ma dostępu Oraz
• Użyj zdefiniowania w widocznych dokumentach, które sprawdzają ukryte dokumenty:

      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

W ten sposób, jeśli pliki zostaną w jakiś sposób zagubione (błędna operacja ftp), nadal są chronione.

Miałem kiedyś ten problem, rozwiązany z:

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

Ale idealnym rozwiązaniem jest umieszczenie pliku poza głównym serwerem WWW, jak wspomniano w innym anwserze.

Chciałem ograniczyć dostęp do pliku PHP bezpośrednio, ale również móc go wywołać przez jQuery $.ajax (XMLHttpRequest). Oto, co mi się udało.

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;
    }
}

Lepiej zbudować aplikację z jednym punktem wejścia, tzn. wszystkie pliki powinny być osiągane z indeksu.php

Umieść to w indeksie.php

define(A,true);

To sprawdzenie powinno być uruchamiane w każdym połączonym pliku (poprzez require lub include)

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

Najprostszym sposobem jest ustawienie zmiennej w pliku wywołującej include, np.

$including = true;

Następnie w pliku, który jest dołączany, sprawdź zmienną

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

Moja odpowiedź jest nieco inna w podejściu, ale zawiera wiele odpowiedzi podanych tutaj. Polecam podejście wielopunktowe:

1. .ograniczenia htaccess i Apache na pewno
2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

Jednak podejście defined or die ma wiele wad. Po pierwsze, jest to prawdziwy ból w założeniach do testowania i debugowania. Po drugie, wiąże się to z przerażająco nudną refaktoryzacją, jeśli zmienisz zdanie. "Znajdź i wymień!"ty powiedz. Tak, ale czy jesteś pewien, że wszędzie jest napisane dokładnie tak samo, hmmm? Pomnóż to tysiącami plików... o. o

A potem jest .htaccess. Co się stanie, jeśli twój kod zostanie rozpowszechniony na stronach, w których administrator nie jest tak skrupulatny? Jeśli tylko na tym polegasz .htaccess, aby zabezpieczyć pliki, będziesz również potrzebował a) kopii zapasowej, b) pudełka chusteczek do osuszenia łez, c) gaśnicy, aby ugasić płomienie we wszystkich wiadomościach od osób korzystających z twojego kod.

Więc wiem, że pytanie prosi o "najłatwiejsze", ale myślę, że to wymaga bardziej "kodowania obronnego".

Proponuję:

1. przed którymś z Twoich skryptów require('ifyoulieyougonnadie.php'); (Nie include() i jako zamiennik dla defined or die)

2. W ifyoulieyougonnadie.php, wykonaj kilka logicznych rzeczy-Sprawdź różne stałe, wywołanie skryptu, testowanie localhost itp. - a następnie zaimplementuj swoje die(), throw new Exception, 403, itp.

   Tworzę własny framework z dwoma możliwymi wpisami punkty-główny indeks.php (Joomla framework) i ajaxrouter.php (mój framework) - więc w zależności od punktu wejścia sprawdzam różne rzeczy. Jeśli prośba do ifyoulieyougonnadie.php nie pochodzi z jednego z tych dwóch plików, wiem, że są podejmowane oszustwa!

   Ale co jeśli dodam nowy punkt wejścia? Bez obaw. Po prostu zmieniam ifyoulieyougonnadie.php i jestem posortowany, plus nie "znajdź i zamień". Hura!

   Co jeśli zdecyduję się przenieść niektóre z moich skryptów do innego frameworka, który nie ma te same stałe defined()? ... Hura! ^_^

Odkryłem, że ta strategia sprawia, że rozwój jest o wiele przyjemniejszy i o wiele mniej: {]}

/**
 * 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();

Poza tym .sposób htaccess, widziałem użyteczny wzór w różnych frameworkach, na przykład w ruby on rails. Mają one oddzielny katalog pub/ w katalogu głównym aplikacji, a katalogi bibliotek znajdują się w katalogach na tym samym poziomie co pub/. Coś w tym stylu (nie idealne, ale masz pomysł):

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

Skonfigurowałeś swój serwer WWW, aby używał pub / jako głównego dokumentu. Zapewnia to lepszą ochronę skryptów: podczas gdy mogą one dotrzeć z dokumentu root aby załadować niezbędne komponenty nie jest możliwy dostęp do komponentów z Internetu. Kolejną zaletą oprócz bezpieczeństwa jest to, że wszystko jest w jednym miejscu.

Ta konfiguracja jest lepsza niż tylko tworzenie sprawdzeń w każdym dołączonym pliku, ponieważ komunikat "dostęp niedozwolony" jest wskazówką dla atakujących i jest lepszy niż .konfiguracja htaccess, ponieważ nie jest oparta na białej liście: jeśli zepsujesz rozszerzenia plików, nie będzie widoczna w lib/, conf / itd. katalogi.

What Joomla! does definiuje stałą w pliku głównym i sprawdza, czy ta sama jest zdefiniowana w dołączonych plikach.

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

Albo

Można przechowywać wszystkie pliki poza zasięgiem żądania http, umieszczając je poza katalogiem webroot, jak zaleca większość frameworków takich jak CodeIgniter.

Lub nawet przez umieszczenie .plik htaccess w folderze Dołącz i regułach zapisu można zapobiec bezpośredniemu dostępowi.

debug_backtrace() || die ("Direct access not permitted");

Jeśli dokładniej, należy użyć tego warunku:

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

Get_included_files () zwraca indeksowaną tablicę zawierającą nazwy wszystkich dołączonych plików (jeśli plik jest wykonywany beign, to został dołączony, a jego nazwa znajduje się w tablicy). Tak więc, gdy plik jest bezpośrednio dostępny, jego nazwa jest pierwsza w tablicy, wszystkie inne pliki w tablicy zostały włączone.

<?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>");
}
?>

Umieść powyższy kod na górze dołączonego pliku php.

Ex:

<?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
?>

Poniższy kod jest używany w CMS Flatnux ( http://flatnux.altervista.org):

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

Znalazłem to jedyne i niezmienne rozwiązanie php, które działa zarówno z http, jak i cli :

Zdefiniuj funkcję:

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

Wywołanie funkcji w pliku, do którego chcesz zapobiec bezpośredniemu dostępowi:

forbidDirectAccess(__FILE__);

Większość rozwiązań podanych powyżej na to pytanie nie działa w trybie Cli.

if (basename($_SERVER['PHP_SELF']) == basename(__FILE__)) { die('Access denied'); };

<?php       
$url = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
  if (false !== strpos($url,'.php')) {
      die ("Direct access not premitted");
  }
?>

Przechowywanie plików nagłówkowych poza katalogiem web accessible zostało wspomniane kilka razy i jest z pewnością dobrą strategią, jeśli to możliwe. Jednak inna opcja, o której jeszcze nie wspomniałem: upewnij się, że Twoje pliki nagłówkowe nie zawierają żadnego kodu. Jeśli Twoje pliki nagłówkowe definiują tylko funkcje i klasy i nie mają kodu innego niż ten, po prostu utworzą pustą stronę, gdy uzyskasz bezpośredni dostęp.

Za wszelką cenę Zezwalaj na bezpośredni dostęp do tego pliku z przeglądarka: to nic nie zrobi . Definiuje niektóre funkcje, ale żadna z nich nie jest wywoływana, więc żadna nie jest uruchamiana.

<?php

function a() {
    // function body
}

function b() {
    // function body
}

To samo dotyczy plików zawierających tylko klasy PHP i nic więcej.

To nadal dobry pomysł, aby trzymać swoje pliki poza katalogiem www, gdzie to możliwe.

• możesz przypadkowo dezaktywować PHP, w takim przypadku twój serwer może wysyłać zawartość plików PHP do przeglądarki, zamiast uruchamiać PHP i wysyłać wynik. Może to spowodować powstanie kodu (w tym hasła do bazy danych, klucze API itp.).
• pliki w katalogu www przykucają na adresy URL, których możesz użyć w swojej aplikacji. Pracuję z CMS, który nie może mieć strony o nazwie system, ponieważ byłoby to sprzeczne ze ścieżką używaną do kodu. To mnie denerwuje.

Zrób coś takiego:

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

Możesz użyć poniższej metody, chociaż ma ona wadę, ponieważ może być sfałszowana, chyba że możesz dodać kolejną linijkę kodu, aby upewnić się, że żądanie pochodzi tylko z twojego serwera za pomocą Javascript. Możesz umieścić ten kod w sekcji Body swojego kodu HTML, więc błąd jest tam widoczny.

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

Umieść tutaj swój drugi kod HTML

<? } ?>

Zakończ to w ten sposób, więc wynik błędu będzie zawsze widoczny w sekcji body, jeśli tak chcesz be.

Sugeruję, aby nie używać $_SERVER ze względów bezpieczeństwa .
Możesz użyć zmiennej takiej jak $root=true; w pierwszym pliku, który zawierał inną.
i użyj isset($root) na początku drugiego pliku, który zostanie dołączony.

Możesz również zabezpieczyć katalog hasłem i przechowywać w nim wszystkie skrypty php, oczywiście z wyjątkiem indeksu.plik php, ponieważ w momencie dołączania hasła nie będzie wymagany, ponieważ będzie wymagany tylko do dostępu http. to, co zrobi, to również opcja dostępu do skryptów w przypadku, gdy chcesz, ponieważ będziesz miał hasło dostępu do tego katalogu. musisz skonfigurować .plik htaccess dla katalogu i a .plik htpasswd do uwierzytelnienia użytkownika.

Dobrze, możesz również użyć dowolnego z powyższych rozwiązań, jeśli uważasz, że nie musisz normalnie uzyskiwać dostępu do tych plików, ponieważ zawsze możesz uzyskać do nich dostęp za pośrednictwem cPanel itp.

Hope this helps

Najprostszym sposobem jest przechowywanie swoich wpisów poza katalogiem www. W ten sposób serwer ma do nich dostęp, ale nie ma zewnętrznej maszyny. Jedyną wadą jest to, że musisz mieć dostęp do tej części serwera. Plusem jest to, że nie wymaga konfiguracji, konfiguracji ani dodatkowego stresu kodu/serwera.

Nie znalazłem sugestii z .htaccess tak dobry, bo może blokować inne treści w tym folderze, do których użytkownik może mieć dostęp, to jest moje rozwiązanie:

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

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

Zrobi to gładko

Wcześniej wspomniane rozwiązanie z sprawdzeniem wersji PHP dodane:

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