Evitar el acceso directo a un archivo de inclusión de PHP


166

Tengo un archivo php que usaré de forma tan exclusiva como una inclusión. Por lo tanto, me gustaría lanzar un error en lugar de ejecutarlo cuando se accede directamente escribiendo la URL en lugar de ser incluido.

Básicamente, necesito hacer una verificación de la siguiente manera en el archivo php:

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

¿Hay una forma fácil de hacer esto?


10
en lugar de die (), debe probar el encabezado '("Archivo HTTP / 1.1 404 no encontrado", 404); salida;'. Esto (al menos en Apache) hará que el servidor devuelva la página 404 normal.
gnud

Aquí hay dos métodos fáciles que he explicado para deshabilitar el acceso directo en los archivos PHP incluidos: codespeedy.com/disable-direct-access-to-the-php-include-file
Faruque Ahamed Mollick

Respuestas:


174

La forma más fácil para la situación genérica de "aplicación PHP que se ejecuta en un servidor Apache que puede o no controlar completamente" es colocar sus inclusiones en un directorio y denegar el acceso a ese directorio en su archivo .htaccess. Para ahorrarle a la gente la molestia de buscar en Google, si está usando Apache, coloque esto en un archivo llamado ".htaccess" en el directorio al que no desea que esté accesible:

Deny from all

Si realmente tiene el control total del servidor (más común en estos días incluso para aplicaciones pequeñas que cuando escribí esta respuesta por primera vez), el mejor enfoque es pegar los archivos que desea proteger fuera del directorio desde el que está sirviendo su servidor web . Entonces, si su aplicación está activada /srv/YourApp/, configure el servidor para que sirva los archivos /srv/YourApp/app/y agregue las inclusiones /srv/YourApp/includes, para que literalmente no haya ninguna URL que pueda acceder a ellas.


1
Gracias, ya que tengo control total sobre el servidor donde ejecuto esta aplicación, esta es la respuesta que elegí.
Alterlife

24
si tiene el control total del servidor, es mejor si coloca la configuración en una directiva de directorio en el archivo de configuración del host virtual. Apache lo leyó solo una vez al inicio, .htaccess se lee en cada acceso y ralentiza el servidor
Eineki

22
Sería bueno tener un archivo .htaccess de ejemplo como parte de esta respuesta.
Graham Lea

77
<Files ~ "\.inc$"> Order Allow,Deny Deny from All </Files>
Dracorat

11
@ James: Además, no todo el mundo siente que Stack Overflow debería ser un sitio "por favor envíe el código". Si responde la pregunta con claridad, entonces es una buena respuesta. Proporcionar un ejemplo donde no se necesita ninguno solo fomenta la codificación de copiar y pegar.
Chuck

188

Agregue esto a la página que desea incluir solo

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

luego en las páginas que lo incluyen agregue

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

3
Realmente necesito aprender a escribir más rápido. Esto es lo mismo que sugeriría, ya que es más seguro que un método que utiliza una variable para verificar. Dado que con algunas configuraciones de PHP, es posible anular la variable.
Mark Davidson el

3
Así es como lo manejan algunas aplicaciones 'convencionales'. Sé que Joomla lo hace de esta manera y creo que Wiki, Wordpress y otros también.
UnkwnTech

1
Tal vez el mensaje sea demasiado útil para un hacker (ningún usuario real encontraría estas páginas), simplemente puede enviar un encabezado de redireccionamiento y detener el procesamiento de php.
bandi

77
Simplemente envíe un encabezado 404 y salga: la página de error se verá idéntica a las páginas 404 normales (al menos en Apache).
gnud

44
@ Smile.Hunter: se trata de bloquear el acceso para ver sus archivos de script de inclusión / biblioteca directamente, la respuesta funciona. Si crearon somefile.phpen su servidor y agregaron su definición en él, eso todavía no les permite acceder directamente al archivo de inclusión. Les permitirá "incluir" sus archivos de biblioteca, pero si llegan lo suficientemente lejos como para crear archivos en su servidor y conocer sus scripts de definición / inclusión, tiene otros problemas que probablemente nieguen escribir su propio archivo con su definición en primer lugar .
James

114

Tengo un archivo que necesito para actuar de manera diferente cuando se incluye vs cuando se accede directamente (principalmente un print()vs return()) Aquí hay un código modificado:

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

El archivo al que se accede siempre es un archivo incluido, de ahí el == 1.  


12
Esa es realmente una gran idea, verificar el recuento de archivos incluidos. Me pregunto cuál es mejor: ¿usando define o usando este método? Esto parece más autónomo.
Akoi Meexx

La primera vez que he visto a alguien pensar en esto. Sin embargo, no sé por qué, porque parece tan autónomo como puede ser, y está midiendo directamente lo que realmente quieres saber (si está incluido o no) en lugar de medir algo que se supone que está asociado (como una cierta constante o una cierta ubicación prohibida por .htaccess). Hermoso.
Jimbo Jonny el

Este es realmente genial porque usar .htaccess para bloquear todos los archivos .php puede no ser posible todo el tiempo, ya que puede haber algunos archivos en el mismo directorio que deben ser llamados directamente o incluso por javascripts. Gracias por esta gran idea!
Anuj

3
Esto solo funciona en PHP5 y versiones posteriores. Pre-PHP5 quiere comparar de nuevo 0 en lugar de 1.
jmucchiello

Esta es una solución realmente inteligente y le permite controlar el acceso directo, no solo bloquearlo, eso es lo que me gusta. Por lo general, incluyo pruebas unitarias en los propios archivos, y de esta manera puedo ajustar mi prueba unitaria en esta declaración if.
Me

34

La mejor manera de evitar el acceso directo a los archivos es colocarlos fuera de la raíz de documentos del servidor web (generalmente, un nivel por encima). Todavía puede incluirlos, pero no hay posibilidad de que alguien acceda a ellos a través de una solicitud http.

Por lo general, hago todo el camino y coloco todos mis archivos PHP fuera de la raíz del documento, aparte del archivo de arranque , un index.php solitario en la raíz del documento que comienza a enrutar todo el sitio web / aplicación.


3
Esta es una gran solución si puede hacerlo. Hace poco tuve que comenzar a trabajar con webhosts compartidos y descubrí que una de las muchas molestias es que todo debe estar dentro del docroot.
Beau Simensen el

3
En cada proveedor de alojamiento con el que trabajé siempre tuve acceso (exactamente) a un nivel por encima de la raíz del documento.
Eran Galperin

3
En algunos hosts (incluido el actual), puede apuntar su dominio a la carpeta que desee.
Dinah

1
Esta es una buena alternativa también ... usando preg_match -> if (preg_match ("~ globalfile \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Alerta de seguridad del dispositivo: acceso directo no permitido. ¡Su IP ha sido registrada! <h3> '); // Detener más ejecuciones}
MarcoZen

Esa url devzone.zend.com/node/view/id/70 es un 404 ahora. La respuesta debe incluir el código que se usó originalmente de esa url no existente.
Funk Forty Niner

31

1: comprobación del recuento de archivos incluidos

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

Lógica: PHP se cierra si no se cumple el recuento mínimo de inclusión. Tenga en cuenta que antes de PHP5, la página base no se considera una inclusión.


2: Definir y verificar una 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: si la constante no está definida, la ejecución no comenzó desde la página base y PHP dejaría de ejecutarse.

Tenga en cuenta que, en aras de la portabilidad a través de actualizaciones y cambios futuros, hacer que este método de autenticación sea modular reduciría significativamente la sobrecarga de codificación, ya que los cambios no necesitarán ser codificados en cada archivo.

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

De esta forma, se puede agregar código adicional para checkdefined.php fines de registro y análisis, así como para generar respuestas apropiadas.

Crédito donde se debe: la brillante idea de portabilidad surgió de esta respuesta .


3: autorización de dirección remota

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

El inconveniente de este método es la ejecución aislada, a menos que se proporcione un token de sesión con la solicitud interna. Verifique a través de la dirección de bucle de retorno en caso de una configuración de servidor único o una lista blanca de direcciones para una infraestructura de servidor con varios servidores o con equilibrio de carga.


4: autorización de token

Similar al método anterior, uno puede usar GET o POST para pasar un token de autorización al archivo de inclusión:

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

Un método muy desordenado, pero también quizás el más seguro y versátil al mismo tiempo, cuando se usa de la manera correcta.


5: configuración específica del servidor web

La mayoría de los servidores le permiten asignar permisos para archivos o directorios individuales. Puede colocar todas sus inclusiones en dichos directorios restringidos y configurar el servidor para que las denegue.

Por ejemplo, en APACHE, la configuración se almacena en el .htaccessarchivo. Tutorial aquí .

Sin embargo, tenga en cuenta que las configuraciones específicas del servidor no son recomendadas por mí porque son malas para la portabilidad en diferentes servidores web. En casos como Content Management Systems donde el algoritmo denegado es complejo o la lista de directorios denegados es bastante grande, solo puede hacer que las sesiones de reconfiguración sean bastante horripilantes. Al final, es mejor manejar esto en código.


6: La colocación incluye en un directorio seguro FUERA de la raíz del sitio

Menos preferido debido a las limitaciones de acceso en entornos de servidor, pero es un método bastante poderoso si tiene acceso al sistema de archivos.

//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:

  • El usuario no puede solicitar ningún archivo fuera de la htdocscarpeta ya que los enlaces estarían fuera del alcance del sistema de direcciones del sitio web.
  • El servidor php accede al sistema de archivos de forma nativa y, por lo tanto, puede acceder a los archivos en una computadora al igual que un programa normal con los privilegios necesarios.
  • Al colocar los archivos de inclusión en este directorio, puede asegurarse de que el servidor php pueda acceder a ellos, mientras que el enlace directo es denegado al usuario.
  • Incluso si la configuración de acceso al sistema de archivos del servidor web no se realizó correctamente, este método evitaría que esos archivos se hagan públicos accidentalmente.

Disculpe mis convenciones de codificación poco ortodoxas. Cualquier comentario es apreciado.


me gusta el número 2
Baim incorrecto

26

Una alternativa (o complemento) a la solución de Chuck sería negar el acceso a archivos que coincidan con un patrón específico al poner algo como esto en su archivo .htaccess

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

Creo que sería mejor usar .inc.php, y es una práctica común
Lis

14

En realidad, mi consejo es hacer todas estas mejores prácticas.

  • Ponga los documentos fuera del webroot O en un directorio de acceso denegado por el servidor web Y
  • Use una definición en sus documentos visibles que los documentos ocultos buscan:
      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

De esta manera, si los archivos se extravían de alguna manera (una operación ftp errante), todavía están protegidos.


8

Tuve este problema una vez, resuelto con:

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

pero la solución ideal es colocar el archivo fuera de la raíz del documento del servidor web, como se menciona en otra respuesta.


7

Será mejor que compile la aplicación con un punto de entrada, es decir, todos los archivos deben alcanzarse desde index.php

Coloque esto en index.php

define(A,true);

Esta verificación debe ejecutarse en cada archivo vinculado (a través de require o include)

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

7

Quería restringir el acceso al archivo PHP directamente, pero también poder llamarlo a través de jQuery $.ajax (XMLHttpRequest). Esto es lo que funcionó para mí.

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

La forma más fácil es establecer algunas variables en el archivo que incluyen las llamadas, como

$including = true;

Luego, en el archivo que se incluye, verifique la variable

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

2
Esto es peligroso si register_globals está activado.
jmucchiello 03 de

25
PHP es peligroso si register_globals está activado.
David Precious

3

Además de la forma .htaccess, he visto un patrón útil en varios marcos, por ejemplo, en ruby ​​on rails. Tienen un directorio pub / separado en el directorio raíz de la aplicación y los directorios de la biblioteca viven en directorios al mismo nivel que pub /. Algo como esto (no es ideal, pero entiendes la idea):

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

Configura su servidor web para usar pub / como documento raíz. Esto ofrece una mejor protección a sus scripts: si bien pueden llegar desde la raíz del documento para cargar los componentes necesarios, es imposible acceder a los componentes desde Internet. Otro beneficio además de la seguridad es que todo está en un solo lugar.

Esta configuración es mejor que simplemente crear comprobaciones en cada archivo incluido porque el mensaje "acceso no permitido" es una pista para los atacantes, y es mejor que la configuración .htaccess porque no se basa en una lista blanca: si arruinas las extensiones de archivo no será visible en los directorios lib /, conf / etc.


Después de mucho tiempo, solo quiero comentar que el modelo que describió anteriormente se llama modelo MVC (Modelo - Vista - Controlador). Si lo desea, consulte google y agregue más información a su respuesta. También MVC admite no solo Ruby on Rails y aplicaciones ASP.NET, sino también PHP (consulte Lavarel, CakePHP).

3

¡Qué joomla! does es definir una constante en un archivo raíz y verificar si la misma está definida en los archivos incluidos.

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

si no

uno puede mantener todos los archivos fuera del alcance de una solicitud http colocándolos fuera del directorio webroot como recomiendan la mayoría de los marcos como CodeIgniter.

o incluso colocando un archivo .htaccess dentro de la carpeta de inclusión y escribiendo reglas, puede evitar el acceso directo.


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

3

Mi respuesta es algo diferente en el enfoque, pero incluye muchas de las respuestas proporcionadas aquí. Yo recomendaría un enfoque múltiple:

  1. .htaccess y restricciones de Apache con seguridad
  2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

SIN EMBARGO, el defined or dieenfoque tiene una serie de fallas. En primer lugar, es un verdadero dolor en los supuestos para probar y depurar. En segundo lugar, implica una refactorización terriblemente aburrida y abrumadora si cambia de opinión. "¡Encontrar y reemplazar!" tu dices. Sí, pero ¿qué tan seguro estás de que está escrito exactamente igual en todas partes, hmmm? Ahora multiplique eso con miles de archivos ... oO

Y luego está .htaccess. ¿Qué sucede si su código se distribuye en sitios donde el administrador no es tan escrupuloso? Si confía solo en .htaccess para proteger sus archivos, también necesitará a) una copia de seguridad, b) una caja de pañuelos para secar sus lágrimas, c) un extintor de incendios para apagar las llamas en todo el correo de odio de las personas usando tu código.

Entonces sé que la pregunta es la "más fácil", pero creo que lo que esto requiere es más "codificación defensiva".

Lo que sugiero es:

  1. Antes de cualquiera de sus scripts require('ifyoulieyougonnadie.php');( no include() y como reemplazo de defined or die)
  2. En ifyoulieyougonnadie.php, haga algunas cosas lógicas (verifique las diferentes constantes, el script de llamada, las pruebas de host local y demás) y luego implemente su die(), throw new Exception, 403, etc.

    Estoy creando mi propio marco con dos posibles puntos de entrada: el index.php principal (marco de Joomla) y ajaxrouter.php (mi marco), por lo que, dependiendo del punto de entrada, verifico si hay cosas diferentes. Si la solicitud ifyoulieyougonnadie.phpno proviene de uno de esos dos archivos, ¡sé que se están haciendo travesuras!

    ¿Pero qué pasa si agrego un nuevo punto de entrada? Sin preocupaciones. Solo cambio ifyoulieyougonnadie.phpy estoy ordenado, además de no 'buscar y reemplazar'. ¡Hurra!

    ¿Qué sucede si decidí mover algunos de mis scripts para hacer un marco diferente que no tenga las mismas constantes defined()? ... ¡Hurra! ^ _ ^

Descubrí que esta estrategia hace que el desarrollo sea mucho más divertido y mucho 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();

2

Si es más preciso, debe usar esta condición:

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

get_included_files () devuelve una matriz indexada que contiene los nombres de todos los archivos incluidos (si el archivo se ejecuta correctamente, se incluyó y su nombre está en la matriz). Entonces, cuando se accede directamente al archivo, su nombre es el primero en la matriz, se incluyen todos los demás archivos en la matriz.


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

coloca el código de arriba en la parte superior de tu archivo php incluido.

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

if (preg_match ("~ globalfile \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Alerta de seguridad del dispositivo - ¡Acceso directo no permitido! Su IP ha sido registrada ! <h3> '); // Detener más ejecuciones} donde ~ es el delimitador
MarcoZen


1

Encontré esta solución invariable y solo para php que funciona tanto con http como con cli:

Definir una función:

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

Llame a la función en el archivo que desea evitar el acceso directo a:

forbidDirectAccess(__FILE__);

La mayoría de las soluciones dadas anteriormente a esta pregunta no funcionan en modo Cli.


donde se supone que debe escribir la URL en modo CLI?
Su sentido común el

Es solo para evitar el lanzamiento de php script / inlude en modo cli. Puede ser útil en un proyecto con múltiples desarrolladores.
Ka.

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

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

1

El almacenamiento de sus archivos de inclusión fuera del directorio web accesible se ha mencionado varias veces, y sin duda es una buena estrategia siempre que sea posible. Sin embargo, otra opción que aún no he visto mencionada: asegúrese de que sus archivos de inclusión no contengan ningún código ejecutable . Si sus archivos de inclusión simplemente definen funciones y clases, y no tienen otro código que ese, simplemente generarán una página en blanco cuando se acceda directamente.

De todos modos, permita el acceso directo a este archivo desde el navegador: no hará nada . Define algunas funciones, pero ninguna se llama, por lo que ninguna se ejecuta.

<?php

function a() {
    // function body
}

function b() {
    // function body
}

Lo mismo se aplica a los archivos que contienen solo clases PHP y nada más.


Sigue siendo una buena idea mantener sus archivos fuera del directorio web siempre que sea posible.

  • Puede desactivar PHP accidentalmente, en cuyo caso su servidor puede enviar el contenido de los archivos PHP al navegador, en lugar de ejecutar PHP y enviar el resultado. Esto podría provocar que su código (incluidas las contraseñas de la base de datos, las claves API, etc.) se filtre.
  • Los archivos en el directorio web están en cuclillas en las URL que puede utilizar para su aplicación. Trabajo con un CMS que no puede tener una página llamada system, porque eso entraría en conflicto con una ruta utilizada para el código. Esto me resulta molesto.

0

Haz algo como:

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

Esto no impedirá que se cargue en el navegador.
UnkwnTech

0

Puede usar el siguiente método a continuación, aunque tiene una falla, ya que puede ser falso, excepto si puede agregar otra línea de código para asegurarse de que la solicitud solo provenga de su servidor mediante JavaScript. Puede colocar este código en la sección Cuerpo de su código HTML, por lo que el error se muestra allí.

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

Coloque su otro código HTML aquí

<? } ?>

Termine así, para que la salida del error siempre se muestre dentro de la sección del cuerpo, si así es como quiere que sea.


Entiendo que no se puede confiar en todos los encabezados del servidor HTTP_ *, por lo que es mejor que no use este método.
andreszs

0

Sugiero que no lo use $_SERVERpor razones de seguridad.
Puede usar una variable como $root=true;en el primer archivo que incluye otra.
y usar isset($root)al comienzo del segundo archivo que se incluirá.


0

Lo que también puede hacer es proteger con contraseña el directorio y mantener todos sus scripts php allí, por supuesto, excepto el archivo index.php, ya que en el momento de incluir la contraseña no será necesaria, ya que solo será necesario para el acceso http. lo que hará es proporcionarle también la opción de acceder a sus scripts en caso de que lo desee, ya que tendrá una contraseña para acceder a ese directorio. necesitará configurar el archivo .htaccess para el directorio y un archivo .htpasswd para autenticar al usuario.

bueno, también puede usar cualquiera de las soluciones proporcionadas anteriormente en caso de que sienta que no necesita acceder a esos archivos normalmente porque siempre puede acceder a ellos a través de cPanel, etc.

Espero que esto ayude


0

La forma más fácil es almacenar sus inclusiones fuera del directorio web. De esa manera, el servidor tiene acceso a ellos pero no tiene una máquina externa. El único inconveniente es que necesita poder acceder a esta parte de su servidor. Lo bueno es que no requiere configuración, configuración o estrés adicional de código / servidor.


0

No encontré las sugerencias con .htaccess tan buenas porque puede bloquear otro contenido en esa carpeta a la que le gustaría permitir que el usuario acceda, esta es mi solución:

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

hará el trabajo sin problemas


2
Copie y pegue de CodeIgnitor. Eso es genial, pero en realidad no hace nada por sí solo. El BASEPATH const se establece en un index.phparchivo que se encuentra en la parte inferior de la estructura de árbol. CI reescribe las URL para que no haya necesidad de acceder a los scripts directamente de todos modos.
jimasun

Sé que no hay necesidad, pero si alguien intenta hacerlo
Varshaan

0

Solución mencionada anteriormente con verificación de versión de PHP agregada:

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

2
Realmente no entiendo cómo esto puede evitar el acceso directo
Adam Lindsay
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.