¿Puede el pirata informático eliminar mis archivos de servidor y la base de datos donde uso la siguiente función?

Question

¿Puede el pirata informático eliminar mis archivos de servidor y la base de datos donde uso la siguiente función?

#1 de Your Common Sense (4 votos)
#2 de CBHacking (1 votos)

1

Quiero saber cómo proteger mi sitio web de hackers. Soy un desarrollador de php-mysql. Para obtener datos de bases de datos siempre uso MySQLi. Para evitar que mi sitio web se inyecte SQL, siempre uso la función $db->real_esacpe_string() de PHP. Para evitar que mi sitio web se ejecute XSS (secuencias de comandos entre sitios), utilicé esta función:

function parsing($text)
{
global $db;
        $text=$db->real_escape_string($text);
 $text= @trim($text);
       $text= strip_tags($text);
 if(get_magic_quotes_gpc()) {
            $text= stripslashes($text);
        }
    $text=str_replace('<','',$text);
    $text=str_replace('>','',$text);   
       $text=htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
    return($text);
}
$name=parsing($_POST['name']);

Cualquier sugerencia de su lado es bienvenida. Gracias de antemano.

webserver xss php mysql

pregunta Dinesh Gurjar 24.12.2018 - 14:10

fuente

2 respuestas

Lea otras preguntas en las etiquetas webserver xss php mysql

AES Encryption ¿es este encriptado demasiado complicado? ¿Necesita un ejemplo y un Servicio de token de seguridad (STS) funcional?

score 4 · Answer 1

Para ser sumamente honesto, esta función es solo una recopilación arbitraria de procedimientos más o menos inútiles o dañinos y, en ocasiones, incluso contradictorios, la mayoría de los cuales no tiene nada que ver con la seguridad. Ahora a la parte más importante.

Inyección SQL

Para evitar que mi sitio web se inyecte en SQL, siempre uso $db->real_esacpe_string()

Que es lo que estas haciendo mal. Sin embargo, no estás solo, lo enumero como el la más infame ilusión de PHP . Citando de esa página:

esta función no tiene absolutamente nada que ver con la seguridad o las inyecciones, simplemente evita los caracteres especiales en los literales de cadena SQL, lo que los hace inmunes a la inyección SQL como efecto secundario, pero es completamente inútil para cualquier otra parte de la consulta, desde un nombre de tabla hasta Un literal numérico. Para protegerse de la inyección SQL, se deben seguir dos reglas simples:


Cualquier literal de datos variables (es decir, una cadena o un número) debe sustituirse por un parámetro, mientras que el valor real debe enviarse a la consulta por separado, mediante el proceso de enlace / ejecución.

Todas las demás partes de consulta que se agreguen a través de una variable, deben filtrarse explícitamente a través de una lista codificada de valores permitidos.

Dado que mysqli en bruto es bastante difícil con las declaraciones preparadas, sugeriría estrictamente utilizar DOP en su lugar.

Entonces, la idea principal de que nada relacionado con la seguridad de SQL debería estar en tal función.

XSS

Veamos qué estás haciendo con los caracteres maliciosos < y > :

primero, todas las etiquetas se eliminan con strip_tags($text);
entonces estos símbolos (ya extintos del texto) se reemplazan con una cadena vacía
finalmente esos caracteres no existentes se convierten en entidades HTML

Si alguna vez me pide que defina "exceso", le mostraré esta función. htmlspecialchars() solo debería ser suficiente para evitar XSS en el cuerpo de la página.

Lo que es más importante, parece que está utilizando esta función en la entrada de datos que es incorrecta. Un texto debe ser formateado justo antes de la salida, de acuerdo con las reglas de formato para el medio determinado. Si está generando en el cuerpo de la página HTML, sería htmlspecialchars . Si el texto va a JavaScript, debería ser otro formato, etc.

Cosas inútiles

trim() no tiene nada que ver con la seguridad, podría usar esta función para su comodidad.
- en una nota al margen, nunca uses este operador @ . Es perjudicial para su experiencia de programación.
stripslashes() también, no tiene nada que ver con la seguridad. Además, esta función es simplemente inútil, nunca haciendo nada sensato.
Sin mencionar que get_magic_quotes_gpc() es dos veces inútil, devolviendo un valor que se eliminó de PHP hace 10 años.

Conclusión

deshacerse de esta función
para evitar la inyección SQL siga las 2 reglas de arriba
para evitar que XSS use htmlspecialchars al generar sus datos o cualquier otro formato apropiado.

score 1 · Answer 2

La respuesta de @YourCommonSense es buena, pero para agregarle un poco: ¡SQLi y XSS no son las únicas amenazas de seguridad importantes de aplicaciones web! De hecho, hay algunos que pondría muy por encima de esos, como inyección de comando (un riesgo si su servidor ejecuta cualquier comando, especialmente en un shell, que contiene información proporcionada por el usuario) u otras formas para obtener potencialmente la ejecución de código arbitrario (cargar y ejecutar archivos ejecutables, ataques de deserialización, etc.). Es más probable que esos tipos de ataques permitan a alguien eliminar archivos del servidor que XSS o SQLi, de todos modos.

Sin saber más sobre lo que hace su sitio y su modelo de seguridad, no puedo crear una lista adecuada de vulnerabilidades de seguridad que corren riesgos, pero garantizo que es más que XSS y SQLi. Por ejemplo, CSRF es casi seguro un riesgo. Hay un montón de formas de hacer la autenticación y la gestión de sesiones mal. Las cargas de archivos de cualquier tipo son un riesgo potencial. Procesar XML es un riesgo. Hacer criptografía es muy difícil de hacer bien. El clickjacking es un riesgo. Esta no es una lista exhaustiva, de ninguna manera, pero espero que tengas la idea.

OWASP es un lugar decente para ir a aprender más sobre la variedad increíblemente amplia de formas en que una aplicación web puede ser insegura.