Estructura de archivos al usar el token

Question

Estructura de archivos al usar el token

#1 de deceze (2 votos)

0

Estoy usando un token de formulario para asegurar el proceso de validación de mi archivo php.

Básicamente, la estructura del archivo php tiene este aspecto:

if ($_POST) {//form has been submitted?

    if (validateFormToken) {
        //process form-data
    }

} else {

    //display form and generate token
    include 'includes/forms/form.php';

}

Me gustaría saber si sería más seguro si dividiera el archivo php en dos archivos:

el formulario en sí y
el archivo php de validación

Solo pregunto porque actualmente uso solo un archivo y se puede acceder a este archivo directamente. Si utilizo dos archivos (mencionados anteriormente) podría evitar el acceso directo del archivo de validación a través del token generado. Pero el archivo de formulario todavía se puede acceder directamente. ¿Hay alguna otra forma de evitar el acceso directo a través de .htaccess o algún otro método que no conozca?

web-application attack-prevention csrf php ajax

pregunta drpelz 27.11.2013 - 19:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application attack-prevention csrf php ajax

Virus extraño que infecta mi servidor ¿Cómo evita ssl los ataques MITM [duplicado]

score 2 · Accepted Answer

El código no va a ser más seguro por sí mismo al dividirlo de forma diferente en los archivos. Lo importante es qué código se ejecutará cuando alguien solicite una determinada URL. Si esto cambia porque su servidor web está ejecutando un archivo diferente o porque tiene una declaración if..else en un archivo es totalmente irrelevante. Los archivos separados pueden ayudar a codificar la organización y, por lo tanto, evitar posibles errores, pero no es más seguro en sí mismo.

Si es posible acceder a "archivos de inclusión" que generalmente no deberían ejecutarse por sí mismos, y esto permite que un atacante evite alguna protección u otra, es totalmente su culpa por haber expuesto públicamente este código ejecutable. Solo debe colocar el código "público" en el directorio webroot público. Si un visitante no debe ir a http://example.com/include/never/execute/this/directly.php , entonces esta URL debe solicitar una respuesta 404 por parte del servidor web en lugar de hacer que ejecute algún código. La forma sensata de hacer esto es no colocar el archivo allí en primer lugar, sino fuera de webroot:

myapp/
  includes/
    sensitive.php
    ...
webroot/
  contact.php
  index.php
  ...

Esto puede llegar a tener solo un index.php en el webroot, usando mod_rewrite para dirigir todas las solicitudes y un enrutador de solicitudes para manejar las solicitudes en PHP.

El servidor web responde a las solicitudes de URL. Esto no tiene nada que ver con los archivos físicos. Siempre mantén eso en mente. Qué solicitud de URL implica qué archivos depende completamente de usted. El punto es qué URL activará qué respuesta; La forma en que se distribuyen los archivos en el backend es completamente irrelevante.