Impedir o acesso direto a um arquivo de inclusão php

166

Eu tenho um arquivo php que eu vou usar tão exclusivamente quanto uma inclusão. Portanto, eu gostaria de lançar um erro em vez de executá-lo quando acessado diretamente, digitando a URL em vez de ser incluída.

Basicamente, eu preciso fazer uma verificação da seguinte forma no arquivo php:

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

Existe uma maneira fácil de fazer isso?

Alterlife
fonte
10
em vez de die (), você deve testar o cabeçalho '("HTTP / 1.1 404 File Not Found", 404); Saída;'. Isso (pelo menos no apache) fará com que o servidor retorne a página 404 normal.
gnud 4/01/09
Aqui estão dois métodos fáceis que tenho explicar para acesso directo disable em PHP arquivos incluídos - codespeedy.com/disable-direct-access-to-the-php-include-file
Faruque Ahamed Mollick

Respostas:

173

A maneira mais fácil para a situação genérica de "aplicativo PHP em execução em um servidor Apache que você pode ou não controlar totalmente" é colocar suas inclusões em um diretório e negar acesso a esse diretório em seu arquivo .htaccess. Para poupar as pessoas do problema de pesquisar no Google, se você estiver usando o Apache, coloque isso em um arquivo chamado ".htaccess" no diretório que você não deseja que seja acessível:

Deny from all

Se você realmente tem controle total do servidor (hoje em dia, mais comum até em aplicativos pequenos do que quando escrevi esta resposta pela primeira vez), a melhor abordagem é manter os arquivos que você deseja proteger fora do diretório em que o servidor da web está servindo . Portanto, se seu aplicativo estiver ativado /srv/YourApp/, configure o servidor para veicular arquivos /srv/YourApp/app/e inclua as inclusões /srv/YourApp/includes, para que literalmente não exista URL que possa acessá-los.

Mandril
fonte
1
Obrigado, já que tenho controle total sobre o servidor em que executo este aplicativo, esta é a resposta que segui.
Alterlife
24
se você tiver controle total do servidor, é melhor colocar a configuração em uma diretiva de diretório no arquivo de configuração do host virtual. Apache lê-lo apenas uma vez na partida, .htaccess é lido em cada acesso e abrandar o servidor
Eineki
22
Seria bom ter um exemplo de arquivo .htaccess como parte desta resposta.
Graham Lea
7
<Files ~ "\.inc$"> Order Allow,Deny Deny from All </Files>
Dracorat 27/09/12
11
@ James: Além disso, nem todo mundo acha que o Stack Overflow deve ser um site "plz send the codez". Se responder a pergunta com clareza, é uma boa resposta. Fornecer um exemplo em que nenhum é necessário apenas incentiva a codificação de copiar e colar.
Chuck
188

Adicione isso à página que você deseja incluir apenas

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

depois, nas páginas que o incluem, adicione

<?php
define('MyConst', TRUE);
?>
UnkwnTech
fonte
3
Eu realmente preciso aprender a digitar mais rápido. É da mesma maneira que eu sugeriria, pois é mais seguro do que um método que usa uma variável para verificar. Como em algumas configurações do PHP, pode ser possível substituir a variável.
Mark Davidson
3
É assim que alguns aplicativos 'mainstream' lidam com isso. Eu sei que o Joomla faz dessa maneira e acho que o Wiki, Wordpress e outros também.
Unkwntech
1
Talvez a mensagem seja muito útil para um hacker (nenhum usuário real encontrará essas páginas), você pode simplesmente enviar um cabeçalho de redirecionamento e interromper o processamento do php.
bandi
7
Basta enviar um cabeçalho 404 e sair - a página de erro será idêntica às páginas 404 normais (pelo menos no Apache).
gnud
4
@ Smile.Hunter: trata-se de bloquear o acesso à visualização direta dos arquivos de script de inclusão / biblioteca, a resposta funciona. Se eles criaram somefile.phpem seu servidor e adicionaram sua definição a ele, isso ainda não permite que eles acessem diretamente o arquivo de inclusão. Isso permitirá que eles "incluam" seus arquivos de biblioteca, mas se eles chegarem longe o suficiente para criar arquivos em seu servidor e conhecer seus scripts de definição / inclusão, você terá outros problemas que provavelmente negam a gravação de seu próprio arquivo com sua definição em primeiro lugar. .
James
114

Eu tenho um arquivo que eu preciso agir de forma diferente quando é incluído vs quando é acessado diretamente (principalmente um print()vs return()) Aqui está um código modificado:

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

O arquivo que está sendo acessado é sempre um arquivo incluído, portanto, o == 1.  

nulo
fonte
12
Na verdade, é uma ótima ideia verificar a contagem de arquivos incluídos. Gostaria de saber o que é melhor: usando define, ou usando este método? Isso parece mais independente.
Akoi Meexx
Primeira vez que vi alguém sugerir isso. Mas não sei por que, porque parece o mais contido possível e mede diretamente o que você realmente deseja saber (se está incluído ou não), em vez de medir algo que se supõe estar associado (como uma constante ou uma certa constante). local proibido por .htaccess). Lindo.
perfil completo de Jimbo Jonny
Este é realmente interessante porque o uso de .htaccess para bloquear todos os arquivos .php pode não ser possível o tempo todo, pois pode haver alguns arquivos no mesmo diretório que precisam ser chamados diretamente ou mesmo por javascripts. Obrigado por esta ótima idéia!
anuj
3
Isso funciona apenas no PHP5 e superior. Pré-PHP5 você quiser comparar novamente 0 em vez de 1.
jmucchiello
Essa é uma solução muito inteligente e permite controlar o acesso direto, não apenas bloqueá-lo - é disso que eu gosto. Normalmente, incluo o teste de unidade nos próprios arquivos, e desta maneira posso envolver meu teste de unidade nesta instrução if. Maravilha quão eficiente ele é ..
whiteatom
34

A melhor maneira de impedir o acesso direto aos arquivos é colocá-los fora da raiz do documento do servidor web (geralmente, um nível acima). Você ainda pode incluí-los, mas não há possibilidade de alguém acessá-los por meio de uma solicitação http.

Eu costumo percorrer todo o caminho e colocar todos os meus arquivos PHP fora da raiz do documento, além do arquivo de inicialização - um index.php solitário na raiz do documento que começa a rotear todo o site / aplicativo.

Eran Galperin
fonte
3
Esta é uma ótima solução, se você puder fazer isso. Recentemente, tive que começar a trabalhar com webhosts compartilhados e descobri um dos muitos aborrecimentos: tudo deve estar dentro da documentação.
Beau Simensen
3
Em todos os provedores de hospedagem com os quais trabalhei, sempre tive acesso (exatamente) a um nível acima da raiz do documento.
Eran Galperin
3
Em alguns hosts (incluindo o atual), você pode apontar seu domínio para a pasta que desejar.
Dinah
1
Esta é uma boa alternativa também. Usando preg_match -> if (preg_match ("~ arquivo global \ .php ~ i", $ _SERVER ['PHP_SELF']))) {die ('<h3 style = "color: red"> Alerta de segurança do dispositivo - acesso direto não permitido! Seu IP foi registrado! <h3> '); // Interromper execução adicional}
MarcoZen
Esse URL devzone.zend.com/node/view/id/70 é um 404 agora. A resposta deve incluir o código que foi originalmente usado a partir desse URL inexistente.
Funk Quarenta Niner
31

1: Verificando a contagem de arquivos incluídos

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

Lógica: o PHP sai se a contagem mínima de inclusão não for atendida. Note que antes do PHP5, a página base não é considerada uma inclusão.


2: Definindo e Verificando uma Constante Global

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

Lógica: Se a constante não estiver definida, a execução não será iniciada a partir da página base e o PHP parará de executar.

Observe que, para garantir a portabilidade entre atualizações e alterações futuras, tornar esse método de autenticação modular reduziria significativamente a sobrecarga de codificação, pois as alterações não precisarão ser codificadas permanentemente em todos os arquivos.

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

Dessa forma, código adicional pode ser adicionado a checkdefined.php fins de registro e análise, bem como para gerar respostas apropriadas.

Crédito onde o crédito é devido: a brilhante idéia de portabilidade veio dessa resposta .


3: Autorização de endereço remoto

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

A desvantagem desse método é a execução isolada, a menos que um token de sessão seja fornecido com a solicitação interna. Verifique através do endereço de loopback no caso de uma configuração de servidor único ou de uma lista branca de endereços para uma infraestrutura de servidor com vários servidores ou com carga balanceada.


4: autorização de token

Semelhante ao método anterior, pode-se usar GET ou POST para passar um token de autorização para o arquivo de inclusão:

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

Um método muito confuso, mas também talvez o mais seguro e versátil ao mesmo tempo, quando usado da maneira correta.


5: Configuração específica do servidor da Web

A maioria dos servidores permite atribuir permissões para arquivos ou diretórios individuais. Você pode colocar todas as suas inclusões nesses diretórios restritos e ter o servidor configurado para negá-las.

Por exemplo, no APACHE, a configuração é armazenada no .htaccessarquivo Tutorial aqui .

Observe, no entanto, que configurações específicas do servidor não são recomendadas por mim porque são ruins para a portabilidade entre diferentes servidores da Web. Em casos como o Content Management Systems, em que o algoritmo de negação é complexo ou a lista de diretórios negados é bastante grande, isso pode tornar as sessões de reconfiguração bastante horríveis. No final, é melhor lidar com isso no código.


6: A colocação inclui em um diretório seguro FORA da raiz do site

Menos preferido devido às limitações de acesso em ambientes de servidor, mas um método bastante poderoso se você tiver acesso ao sistema de arquivos.

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

Lógica:

  • O usuário não pode solicitar nenhum arquivo fora da htdocspasta, pois os links estariam fora do escopo do sistema de endereços do site.
  • O servidor php acessa o sistema de arquivos de forma nativa e, portanto, pode acessar arquivos em um computador, exatamente como um programa normal com privilégios necessários.
  • Ao colocar os arquivos de inclusão nesse diretório, você pode garantir que o servidor php possa acessá-los, enquanto a ligação direta é negada ao usuário.
  • Mesmo que a configuração de acesso ao sistema de arquivos do servidor da web não tenha sido feita corretamente, esse método impediria que esses arquivos se tornassem públicos acidentalmente.

Por favor, desculpe minhas convenções de codificação não ortodoxas. Qualquer feedback é apreciado.

RiA
fonte
eu gosto do número 2
Baim Wrong
26

Uma alternativa (ou complemento) à solução de Chuck seria negar o acesso a arquivos que correspondam a um padrão específico, colocando algo assim no seu arquivo .htaccess

<FilesMatch "\.(inc)$">
    Order deny,allow
    Deny from all
</FilesMatch>
Kevin Loney
fonte
Seria melhor usar .inc.php Eu acredito, e é uma prática comum
Lis
14

Na verdade, meu conselho é fazer todas essas práticas recomendadas.

  • Coloque os documentos fora da raiz da web OU em um diretório de acesso negado pelo servidor da web E
  • Use nos documentos visíveis uma definição que os documentos ocultos verificam:
      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

Dessa forma, se os arquivos forem extraviados de alguma maneira (uma operação de ftp incorreta), eles ainda estarão protegidos.

jmucchiello
fonte
8

Eu tive esse problema uma vez, resolvido com:

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

mas a solução ideal é colocar o arquivo fora da raiz do documento do servidor da web, conforme mencionado em outra resposta.

mati
fonte
7

É melhor criar um aplicativo com um ponto de entrada, ou seja, todos os arquivos devem ser acessados ​​em index.php

Coloque isso em index.php

define(A,true);

Essa verificação deve ser executada em cada arquivo vinculado (via exigir ou incluir)

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

Eu queria restringir o acesso ao arquivo PHP diretamente, mas também poder chamá-lo via jQuery $.ajax (XMLHttpRequest). Aqui está o que funcionou para mim.

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;
    }
}
krasenslavov
fonte
3

A maneira mais fácil é definir alguma variável no arquivo que as chamadas incluem, como

$including = true;

Em seguida, no arquivo que está sendo incluído, verifique a variável

if (!$including) exit("direct access not permitted");
Kyle Cronin
fonte
2
Isso é perigoso se o register_globals estiver ativado.
jmucchiello
25
O PHP é perigoso se o register_globals estiver ativado.
David Precious
3

Além da maneira .htaccess, vi um padrão útil em várias estruturas, por exemplo, em ruby ​​on rails. Eles têm um diretório pub / separado no diretório raiz do aplicativo e os diretórios da biblioteca estão vivendo em diretórios no mesmo nível que pub /. Algo assim (não é o ideal, mas você entendeu):

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

Você configurou seu servidor da web para usar pub / como raiz do documento. Isso oferece melhor proteção aos seus scripts: embora eles possam chegar da raiz do documento para carregar os componentes necessários, é impossível acessar os componentes da Internet. Outro benefício além da segurança é que tudo está em um só lugar.

Essa configuração é melhor do que apenas criar verificações em cada arquivo incluído porque a mensagem "acesso não permitido" é uma pista para os invasores, e é melhor que a configuração .htaccess porque não é baseada em lista branca: se você estragar as extensões de arquivo não estará visível nos diretórios lib /, conf / etc.

bandi
fonte
Depois de muito tempo, só quero comentar que o modelo que você descreveu acima se chamava modelo MVC (Model - View - Controller). Se desejar, verifique o google e adicione mais algumas informações à sua resposta. Além disso, o MVC suporta não apenas aplicativos Ruby on Rails e ASP.NET, mas também PHP (consulte Lavarel, CakePHP).
3

O que Joomla! does está definindo uma constante em um arquivo raiz e verificando se o mesmo está definido nos arquivos incluídos.

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

se não

é possível manter todos os arquivos fora do alcance de uma solicitação http, colocando-os fora do diretório webroot, como recomenda a maioria das estruturas, como o CodeIgniter.

ou mesmo colocando um arquivo .htaccess na pasta de inclusão e nas regras de gravação, você pode impedir o acesso direto.

Pradeesh kumar
fonte
3
debug_backtrace() || die ("Direct access not permitted");
Unirgy
fonte
3

Minha resposta é um pouco diferente na abordagem, mas inclui muitas das respostas fornecidas aqui. Eu recomendaria uma abordagem multifacetada:

  1. Restrições .htaccess e Apache com certeza
  2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

No entanto, a defined or dieabordagem tem várias falhas. Em primeiro lugar, é uma dor real nas suposições testar e depurar. Em segundo lugar, envolve uma refatoração horripilante e entediante, se você mudar de idéia. "Encontre e substitua!" você diz. Sim, mas como você tem certeza de que está escrito exatamente da mesma maneira em todos os lugares, hmmm? Agora multiplique isso por milhares de arquivos ... oO

E depois há .htaccess. O que acontece se o seu código for distribuído em sites onde o administrador não é tão escrupuloso? Se você confiar apenas no .htaccess para proteger seus arquivos, também precisará de a) um backup, b) uma caixa de lenços para secar suas lágrimas, c) um extintor de incêndio para apagar as chamas de todo o ódio das pessoas usando seu código.

Então eu sei que a pergunta pede o "mais fácil", mas acho que isso exige mais "codificação defensiva".

O que eu sugiro é:

  1. Antes de qualquer um dos seus scripts require('ifyoulieyougonnadie.php');( não include() e como substituto defined or die)
  2. Em ifyoulieyougonnadie.php, faça algumas coisas de lógica - verifique se há diferentes constantes, chamando scripts, testes de host local e outros - e implemente o seu die(), throw new Exception, 403, etc.

    Estou criando minha própria estrutura com dois possíveis pontos de entrada - o principal index.php (estrutura do Joomla) e ajaxrouter.php (minha estrutura) - portanto, dependendo do ponto de entrada, procuro coisas diferentes. Se o pedido ifyoulieyougonnadie.phpnão vier de um desses dois arquivos, eu sei que estão sendo feitas travessuras!

    Mas e se eu adicionar um novo ponto de entrada? Não se preocupe. Eu apenas mudo ifyoulieyougonnadie.phpe sou classificado, além de não 'encontrar e substituir'. Viva!

    E se eu decidisse mover alguns dos meus scripts para criar uma estrutura diferente que não tenha as mesmas constantes defined()? ... Viva! ^ _ ^

Eu descobri que essa estratégia torna o desenvolvimento muito mais divertido e muito menos:

/**
 * 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();
Simplesmente alto
fonte
2

Se mais precisamente, você deve usar esta condição:

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

get_included_files () retorna uma matriz indexada que contém nomes de todos os arquivos incluídos (se o arquivo for executado beign, ele foi incluído e seu nome está na matriz). Portanto, quando o arquivo é acessado diretamente, seu nome é o primeiro da matriz, todos os outros arquivos da matriz foram incluídos.

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

coloque o código acima na parte superior do seu arquivo php incluído.

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
?>
Dicas de blogs
fonte
if (preg_match ("~ arquivo global \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Alerta de segurança do dispositivo - acesso direto desabilitado! Seu IP foi registrado ! <h3> '); // Pare ainda mais a execução} whre ~ é o delimitador
MarcoZen
1

O código a seguir é usado no Flatnux CMS ( http://flatnux.altervista.org ):

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

Eu encontrei esta solução php-only e invariável que funciona com http e cli:

Defina uma função:

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

Chame a função no arquivo que você deseja impedir o acesso direto a:

forbidDirectAccess(__FILE__);

A maioria das soluções dadas acima para esta pergunta não funciona no modo Cli.

Ka.
fonte
onde é suposto digitar o URL no modo CLI?
Seu senso comum
É apenas para impedir o lançamento do script php / inlude no modo cli. Pode ser útil em um projeto com vários desenvolvedores.
Ka.
1
if (basename($_SERVER['PHP_SELF']) == basename(__FILE__)) { die('Access denied'); };
andy
fonte
1
<?php       
$url = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
  if (false !== strpos($url,'.php')) {
      die ("Direct access not premitted");
  }
?>
Matt Bettiol
fonte
1

O armazenamento dos arquivos de inclusão fora do diretório acessível da Web foi mencionado algumas vezes e, certamente, é uma boa estratégia sempre que possível. No entanto, outra opção que ainda não vi mencionada: verifique se os arquivos de inclusão não contêm nenhum código executável . Se seus arquivos de inclusão apenas definirem funções e classes e não tiverem código além disso, eles simplesmente produzirão uma página em branco quando acessados ​​diretamente.

Por todos os meios, permita o acesso direto a esse arquivo a partir do navegador: ele não fará nada . Ele define algumas funções, mas nenhuma delas é chamada e, portanto, nenhuma delas é executada.

<?php

function a() {
    // function body
}

function b() {
    // function body
}

O mesmo se aplica aos arquivos que contêm apenas classes PHP e nada mais.


Ainda é uma boa idéia manter seus arquivos fora do diretório da Web sempre que possível.

  • Você pode desativar acidentalmente o PHP; nesse caso, o servidor pode enviar o conteúdo dos arquivos PHP para o navegador, em vez de executar o PHP e enviar o resultado. Isso pode resultar em vazamento do seu código (incluindo senhas do banco de dados, chaves de API etc.).
  • Os arquivos no diretório da web estão ocupados nos URLs que você pode usar para o seu aplicativo. Eu trabalho com um CMS que não pode ter uma página chamada system, porque isso entraria em conflito com um caminho usado para o código. Eu acho isso irritante.
TRiG
fonte
0

Faça algo como:

<?php
if ($_SERVER['SCRIPT_FILENAME'] == '<path to php include file>') {
    header('HTTP/1.0 403 Forbidden');
    exit('Forbidden');
}
?>
kmkaplan
fonte
Isso não impedirá que ele seja carregado no navegador.
Unkwntech
0

Você pode usar o método a seguir abaixo, embora ele tenha uma falha, pois pode ser falsificado, exceto se você puder adicionar outra linha de código para garantir que a solicitação venha apenas do seu servidor usando Javascript. Você pode colocar esse código na seção Corpo do seu código HTML, para que o erro seja exibido lá.

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

Coloque seu outro código HTML aqui

<? } ?>

Encerre-o assim, para que a saída do erro sempre seja exibida na seção do corpo, se é assim que você quer que seja.

Príncipe encantado
fonte
Entendo que todos os cabeçalhos de servidor HTTP_ * não são confiáveis, portanto é melhor você não usar esse método.
andreszs
0

Eu sugiro que não use $_SERVERpor razões de segurança.
Você pode usar uma variável como $root=true;no primeiro arquivo que incluiu outra.
e use isset($root)no início do segundo arquivo que está incluído.

M Rostami
fonte
0

O que você também pode fazer é proteger com senha o diretório e manter todos os seus scripts php lá, é claro, exceto o arquivo index.php, pois no momento da inclusão da senha não será necessário, pois será necessário apenas para acesso http. o que ele fará é também fornecer a opção de acessar seus scripts, caso você queira, pois terá senha para acessar esse diretório. você precisará configurar o arquivo .htaccess para o diretório e um arquivo .htpasswd para autenticar o usuário.

bem, você também pode usar qualquer uma das soluções fornecidas acima, caso sinta que não precisa acessar esses arquivos normalmente, porque sempre poderá acessá-los através do cPanel etc.

Espero que isto ajude

RohitG
fonte
0

A maneira mais fácil é armazenar suas inclusões fora do diretório da web. Dessa forma, o servidor tem acesso a eles, mas nenhuma máquina externa. A única desvantagem é que você precisa acessar essa parte do seu servidor. O lado positivo é que não requer instalação, configuração ou estresse adicional de código / servidor.


fonte
0

Não achei as sugestões com .htaccess tão boas, pois podem bloquear outro conteúdo nessa pasta que você deseja permitir que o usuário acesse, esta é a minha solução:

$currentFileInfo = pathinfo(__FILE__);
$requestInfo = pathinfo($_SERVER['REQUEST_URI']);
if($currentFileInfo['basename'] == $requestInfo['basename']){
    // direct access to file
}
talsibony
fonte
0
if ( ! defined('BASEPATH')) exit('No direct script access allowed');

fará o trabalho sem problemas

Varshaan
fonte
2
Copie e cole do CodeIgnitor. Isso é legal, mas na verdade não faz nada por si só. O BASEPATH const é definido em um index.phparquivo que fica na parte inferior da estrutura da árvore. O IC reescreve os URLs, para que não seja necessário acessar os scripts diretamente.
jimasun
eu sei que não há necessidade, mas se qualquer um tenta fazê-lo
Varshaan
0

Solução mencionada anteriormente com a verificação da versão do PHP adicionada:

    $max_includes = version_compare(PHP_VERSION, '5', '<') ? 0 : 1;
    if (count(get_included_files()) <= $max_includes)
    {
        exit('Direct access is not allowed.');
    }
Milo Wanrooij
fonte
2
Eu realmente não entendo como isso pode impedir o acesso direto
Adam Lindsay