Cosas para buscar una puerta trasera en el código fuente de la aplicación web (archivos .PHP, .JS, etc.) [cerrado]

Me temo que no es tan simple. Algunas construcciones de lenguaje no son malas en sí mismas, pero su uso en algunos lugares puede hacer que la aplicación sea vulnerable. Considera, por ejemplo, Función strcmp de PHP: se ve bien, no hay vulnerabilidades reportadas, sin embargo, aún puede omitirla si se alimenta directamente con la entrada del usuario. Entonces, si yo fuera usted, consideraría una revisión profunda del código en lugar de un simple escaneo del globo ocular. Cuanta más experiencia tenga, más riesgos de seguridad "no tan obvios" podrá detectar.

Una breve lista para ayudarlo a comenzar con una revisión de la exploración del globo ocular:

• ¿La entrada del usuario se maneja de manera adecuada y segura?
• ¿Se realizan controles de igualdad con ===?
• ¿Se utilizan funciones en desuso?
• ¿Eres capaz de entender el código?

En general, hay muchas más cosas que debe tener en cuenta y la lista crece aún más con la complejidad de la aplicación. P.ej. puede (debería) querer asegurarse de que todos los algoritmos criptográficos se usen de manera adecuada y que la implementación utilizada sea correcta y segura. Existe una gestión de archivos, conexión de base de datos y potencialmente decenas de otras fuentes de datos con las que se está comunicando su aplicación.

Si siente que no puede manejarlo usted mismo debido a la falta de experiencia o algo así, le recomiendo pedir ayuda a alguien. En realidad, incluso si está seguro de poder hacerlo, pídale a alguien que compruebe dos veces: siempre es mejor tener dos pares de ojos en el código no confiable, que uno.

PHP

Por razones de seguridad, puede bloquear las funciones de PHP por nombre en su PHP.ini, por lo que si están en el código no se pueden ejecutar. Aquí hay una placa de caldera de lo que normalmente uso.

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

Puede haber usos legítimos a los anteriores. Pero lo mejor es descubrir por qué, antes de que los pongas en la lista blanca. Incluso si su programador no los está utilizando por razones negativas, podría haber partes mal codificadas que permiten a un pirata informático abusar de esas funciones.

Usted sabe eval pero debería notar shell_exec , exec , system y passthru . Esto le permitirá a su desarrollador interactuar con el sistema directamente. Y para la mayoría de las situaciones, su configuración de PHP no debería permitirlo. También tenga en cuenta cuántos les permitirían interactuar con los procesos en ejecución en su servidor.

Además, volvería a verificar cualquier requisito e incluye. Con una configuración PHP adecuada, no puede incluirlo de forma remota, pero no estaría de más. También buscaría lo mismo usando las funciones fopen y CURL. Si lo encuentra, tiene el potencial de cargar código remoto sin que usted pueda revisarlo o buscarlo.

JavaScript

No puede hacer una puerta trasera a un servidor, ya que JavaScript solo ejecuta el lado del cliente (asumiendo que no está usando Node.js). Pero podrían ponerte en riesgo de un ataque XSS. Asegúrese de que no estén intentando cargar scripts remotos a menos que provengan de un CDN aprobado y confiable. Y asegúrese de que su JavaScript no intente adjuntar ningún elemento de script a su documento que pueda cargarse en archivos JavaScript remotos.