¿Cuáles son las medidas necesarias para evitar o detener las inyecciones de JavaScript en una aplicación web PHP para que no se proporcione información confidencial (mejores prácticas en PHP, HTML/XHTML y JavaScript?)?Prevención de inyecciones de JavaScript en una aplicación web PHP
Un buen primer paso es aplicar los métodos enumerados en el question Gert G linked. Esto cubre en detalle la variedad de funciones que se pueden utilizar en diferentes situaciones para limpiar de entrada, incluyendo mysql_real_escape_string, htmlentities(), htmlspecialchars(), strip_tags() y addslashes()
una mejor manera, siempre que sea posible, es evitar la inserción de la entrada del usuario directamente en su base de datos . Emplee whitelist input validation: en cualquier situación en la que solo tenga un rango limitado de opciones, elija entre los valores codificados para la inserción, en lugar de tomar la información de cualquier formulario que se encuentre del lado del cliente. Básicamente, esto significa tener solo ciertos valores que aceptas, en lugar de tratar de eliminar/contrarrestar el mal/mal formado/entrada maliciosa.
Por ejemplo: Si tiene un formulario con un menú desplegable para artículos, no use la entrada de este menú desplegable para la inserción. Recuerde que un cliente malintencionado puede editar la información enviada con el envío del formulario, incluso si cree que solo tienen opciones limitadas. En cambio, haga que el menú desplegable haga referencia a un índice en una matriz en su código del lado del servidor. Luego usa esa matriz para elegir qué insertar. De esta forma, incluso si un atacante intenta enviarle código malicioso, nunca llegará a su base de datos.
Obviamente, esto no funciona para aplicaciones de formato libre como foros o blogs. Para ellos, debes recurrir a las técnicas del "primer paso". Aún así, hay una amplia gama de opciones que se pueden mejorar a través de la validación de la entrada de la lista blanca.
También puede usar parameterized queries (también conocido como declaraciones preparadas con variables de vinculación) para sus interacciones sql siempre que sea posible. Esto le dirá a su servidor de base de datos que toda la entrada es simplemente un valor, por lo que mitiga muchos de los problemas potenciales de los ataques de inyección. En muchas situaciones, esto incluso puede cubrir aplicaciones de forma libre.
Si su nada que no pase que necesita ser formateada como html a continuación, utilizar:
strip_tags() <- Eliminates any suspicious html
y ejecute el siguiente para limpiar antes de guardarlo en el PP
mysql_real_escape_string()
Si el Ajax es el ahorro el usuario ingresó html a través de un cuadro de texto o wysiwyg y luego miró usando HTMLPurifier para quitar javascript pero permitir etiquetas html.
supongamos que en mi archivo csv tengo una columna en la que pongo el valor de la columna como entonces ¿cómo puedo eliminar este valor de columna y hacerlo nulo –
Trata cualquier valor que salga a html con htmlspecialchars() por por defecto.
La única excusa para no usar htmlspecialchars() es cuando necesita generar una cadena html que en sí misma contenga html. En ese caso, debe estar seguro de que esta cadena proviene de una fuente completamente segura. Si no tiene tanta confianza, debe pasarla a través del filtro html de la lista blanca que solo permite un conjunto de etiquetas, atributos y valores de atributos cuidadosamente limitados. Debe tener especial cuidado con los valores de los atributos. Nunca debe permitir que todo pase como valor de atributo especialmente para atributos como src, hef, style.
Debería conocer todos los lugares de su aplicación web en los que produce algo en html sin utilizar htmspeciachars(), asegúrese de que realmente necesita esos lugares y tenga en cuenta que a pesar de su confianza esos lugares son vulnerabilidades potenciales.
Si está pensando que esto es demasiada precaución: "¿Por qué necesito htmlspecialchar() esta variable que yo sé que contiene solo un número entero y perder todos los preciosos ciclos de CPU?"
Recuerda esto: no sabes, solo piensas que sabes, los ciclos de CPU son lo más barato del mundo y casi todos serán desperdiciados esperando la base de datos o el sistema de archivos o incluso el acceso a la memoria.
Además, nunca utilice filtros html de lista negra. Youtube cometió ese error y alguien descubrió de repente que solo se elimina el primer <script> y si ingresa el segundo en el comentario, puede inyectar cualquier código de Javascript en el navegador de los visitantes.
De forma similar, para evitar las inyecciones de SQL, trate con mysql_real_escape_string() todos los valores que pega a la consulta SQL, o mejor aún, use declaraciones preparadas con PDO.
No estoy totalmente de acuerdo con las otras respuestas proporcionadas, así que publicaré mis recomendaciones.
Lecturas recomendadas XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
HTML inyección: Siempre mostrar cualquier contenido enviado por los usuarios, es necesario limpiarlo adecuadamente con htmlspecialchars o htmlentities al especificar ENT_QUOTES si se usa dentro de las comillas simples. Yo recomendaría nunca encapsular en comillas simples y siempre encapsulando sus atributos entre comillas dobles (no las omita). Esto se aplica a cosas tales como:
<input value="<?php echo htmlspecialchars($var); ?>" />
<textarea><?php echo htmlspecialchars($var); ?></textarea>
<p><?php echo htmlspecialchars($var); ?></p>
<img width="<?php echo htmlspecialchars($var); ?>" />
Javascript inyección: Es una buena práctica (pero no siempre es práctico) para que nunca el contenido del usuario eco en eventos y Javascript. Sin embargo, si lo hace, hay algunas cosas que se pueden hacer para reducir el riesgo. Solo pasar ID enteros. Si necesita algo como un especificador de tipo, utilice una lista blanca y/o verificación condicional antes de la salida. Posiblemente forzar el contenido del usuario a alfanumérico solo cuando sea apropiado; preg_replace("/[^A-Za-z0-9]/", '', $string); pero tenga mucho cuidado con lo que permite aquí. Solo incluya contenido cuando esté encapsulado entre comillas y tenga en cuenta que htmlspecialchars/htmlentities no lo protege aquí. Se interpretará en tiempo de ejecución incluso si se ha traducido a entidades html. Esto se aplica a cosas tales como:
<a href="www.stackoverlow.com/?id=<?php echo (int)$id; ?>">Click</a>
href, src, style, onClick, etc.
No eco de cualquier contenido del usuario en otros ámbitos, como el cuerpo de etiquetas de script, etc., a menos que se ha visto obligado a un int o algún otro juego de caracteres muy muy limitado (si Sabes lo que estas haciendo).
inyección SQL: Uso Prepared statements, el contenido del usuario se unen a ellos, y nunca insertar directamente el contenido del usuario en la consulta. Recomendaría crear una clase para declaraciones preparadas con funciones auxiliares para sus diferentes tipos de declaraciones básicas (y mientras esté en el tema, funcionalice todas las declaraciones de su base de datos). Si decide no utilizar declaraciones preparadas, utilice mysql_real_escape_string() o similar (no addslashes()). Valide el contenido cuando sea posible antes de almacenarlo en la base de datos, como forzar/verificar el tipo de datos enteros, las verificaciones condicionales de los tipos, etc. Utilice los tipos y longitudes de columnas de bases de datos adecuadas. Recuerde que el objetivo principal aquí es evitar la inyección de sql, pero también puede optar por la protección de inyección html/javascript aquí.
Otros recursos He hecho algunas investigaciones en línea con la esperanza de encontrar una solución simple ya disponible al público. Encontré OWASP ESAPI pero parece bastante anticuado. Los enlaces a la versión php están rotos en varios lugares. Creo que lo encontré aquí; ESAPI PHP pero nuevamente está bastante anticuado y no es tan simple como esperaba. Sin embargo, puede ser útil.
En general, nunca más suponga que está protegido, como el uso de htmlentities en un atributo onClick. Debe usar la herramienta correcta en el lugar correcto y evitar hacer cosas en la ubicación incorrecta.
posible duplicado de [¿Cómo prevenir los ataques de inyección de código en PHP?] (Http://stackoverflow.com/questions/1205889/how-to-prevent-code-injection-attacks-in-php) –
@Gert G : Creo que la pregunta es acerca de las inyecciones de SQL y XSS ... no de las inyecciones de JavaScript. – Alerty
No se superponen completamente: se aplican esas técnicas, pero hay otras medidas que no están cubiertas por los elementos propuestos en esa pregunta. Vea abajo. –