Soy un poco nuevo en la codificación de PHP y soy consciente de que los usuarios malintencionados pueden piratear un sitio web si no has desinfectado tu código PHP. Lo que me pregunto es si necesitan un cuadro de entrada de datos (como para envíos de archivos o campos de entrada de nombre de usuario/contraseña).¿Qué tan seguro es PHP?
¿Los comandos como "include (header.php)" también necesitan algún tipo de seguridad o son innatamente seguros?
No confíes en el usuario.
include "a/literal/file.php";
es bastante seguro
include $someFile;
significa que quiere pensar en cómo $ somefile consigue el sistema. Si usa los datos que le dio un usuario para establecer el valor de $ someFile, será mejor que lo desinfecte.
... y si necesita seleccionar una inclusión basada en la entrada del usuario, siempre cree una lista de las que considere válidas y seguras, luego haga coincidir la entrada del usuario con un valor en esa lista y use solo el valor de la lista segura para el incluir. –
Al igual que en cualquier otro idioma, el código PHP es tan seguro como el programador lo escribe.
Al igual que en cualquier otro idioma, los riesgos de seguridad individuales (e incluso comunes) son demasiado numerosos y detallados para incluirlos en una respuesta de StackOverflow.
Encuentra un libro que cubra la codificación segura de PHP.
+1, muchas personas piensan que PHP es un lenguaje inseguro porque se ha escrito mucho código inseguro usando PHP. Esto se debe a que PHP tiene una curva de aprendizaje inicial bastante suave, que ofrece a los programadores inseguros la posibilidad de escupir un código inseguro. Además, PHP está muy ampliamente implementado, lo que le da una mayor probabilidad estadística de que los programadores inseguros lo recojan para un proyecto. – snicker
para un libro sobre la seguridad de PHP. Recomendaría "Essential PHP Security" de Chris Shiflett (http://oreilly.com/catalog/9780596006563/) - es bastante completo, y muestra que no es realmente difícil de seguir buenas, seguras, prácticas de código. – HorusKol
PHP es tan seguro como cualquier cosa. Pero no de forma predeterminada, depende de las habilidades del programador. A diferencia de .NET que tiende a ayudar con la seguridad de manera predeterminada.
Incluye son seguros solo tenga cuidado si las rutas se generan dinámicamente.
La continuación es inofensivo (en función del código en myfile.php)
include("mypath/myfile.php");
Esto puede ser cierto en los viejos tiempos (hace unos años), tenemos marcos de MVC seguros en PHP, que tiende a ayudar con la seguridad por defecto http://framework.zend.com/. –
Su pregunta es bastante amplio y general, pero para hacer frente a un punto específico que usted hizo:
include (header.php);es relativamente seguro, pero
include ($header);es potencialmente peligroso un agujero de seguridad en función de cómo $header fue asignado y si ha sido desinfectado.
Una ventaja más grande de la primera es que no tiene que buscar más: es localmente segura. (Como alguien que tiene que hacer auditorías en una base de códigos bastante grande, eso es importante para mí.) –
Para responder específicamente a la pregunta, PHP es un lenguaje muy seguro. Para el idioma en sí, se recomienda que utilice la última versión estable para mantenerse al tanto de la seguridad basada en el lenguaje. Los mantenedores de php son los que crean y corrigen errores;)
Estoy de acuerdo con todos aquí: PHP no es realmente más o menos seguro en sí mismo que en cualquier otro idioma.
Sin embargo, debería examinar a fondo su archivo php.ini. Probablemente deberías conocer todas las directivas. Aquí es donde mucha gente comete errores desde el principio.
En cuanto a los cuadros de entrada de datos, uno debería preocuparse por los ataques de inyección SQL, desbordamiento, caracteres defectuosos, etc. Para funciones de salida, consulte funciones como filter_var(), mysql_real_escape_string(), pg_escape_string().
Y 'htmlentities' cuando se hace eco de los datos de vuelta a la página web. – DisgruntledGoat
Para cotizar RSnake de un sla.ckers.org post back in 2006:
Pensé que lo interesante era que Stefan Esser se retiró del equipo de respuesta a incidentes de PHP. No comenzar una guerra religiosa en los foros, pero es interesante que el fundador del equipo de respuesta de seguridad de PHP esté harto de la falta de seguridad en PHP y deje de hacerlo como resultado. Su sitio está desactivado en el momento (inundaciones tráfico?): [Blog.php-security.org] Así que aquí es un corte y pega de la caché:
sábado 9 de diciembre de de 2006
Último La noche en que finalmente me retiré del Equipo de respuesta de seguridad de PHP, esa fue mi idea inicial hace unos años.
Las razones para esto son muchas, pero la más importante es que me he dado cuenta de que cualquier intento de mejorar la seguridad de PHP desde el interior es inútil. El Grupo PHP saltará a su barco tan pronto como intente culpar al usuario por los problemas de seguridad de PHP, pero en el momento en que critica la seguridad de PHP, se convierte en persona non grata. Dejé de contar las veces en que me llamaron traidor inmoral por revelar agujeros de seguridad en PHP o por desarrollar Suhosin.
Para el usuario PHP normal, esto significa que ya no ocultaré el tiempo de respuesta lento a los agujeros de seguridad en mis advertencias. También significará que algunos de mis avisos vendrán sin parches disponibles, porque el Equipo de respuesta de seguridad de PHP se negó a solucionarlos durante meses. También significará que habrá muchas más advertencias sobre agujeros de seguridad en PHP.
Publicado por Stefan Esser en PHP, Seguridad en 10:58
Bueno, aterrador como suena, estoy muy emocionado de finalmente conseguir el "auténtico" en la seguridad de PHP. Siempre he sido un poco cauteloso y será interesante ver lo que Stefan tiene para decir.
fuente: http://sla.ckers.org/forum/read.php?2,3976
que introduce muy bien el proyecto endurecido PHP, Suhosin http://www.hardened-php.net/suhosin/ y Esser del mes de PHP Bugs proyectar http://www.php-security.org/
Es posible que desee tomar el título de ser más específico. Creo que el título es demasiado vago o general para la pregunta que estás haciendo. – codingbear