2010-08-09 40 views
7

¿Cómo se evitan los ataques de script entre sitios?Cómo evitar "Ataques de secuencias de comandos entre sitios"

Cross-site script attacks (o de cross-site scripting) es que si, por ejemplo, tiene un libro de visitas en su página web y mensajes en el cliente un código JavaScript, que fx le redirige a otro sitio web o envía las cookies en un correo electrónico a una usuario malicioso o podría tratarse de muchas otras cosas que pueden resultar realmente dañinas para usted y las personas que visitan su página.

Estoy seguro de que se puede hacer fx. en PHP por validación de formularios pero no tengo experiencia suficiente para fx. prohibir javascript u otras cosas que pueden hacerte daño.

Espero que entienda mi pregunta y que pueda ayudarme.

+0

¿Marco objetivo? PHP? – Arthur

+0

Hay opciones para cualquier idioma/marco/etc. Obtendrá respuestas más específicas, como htmlencode, si proporciona más información sobre su configuración. (Apilar). – Tobiasopdenbrouw

+0

Tienes razón, Tobiasopdenbrouw, pero en realidad era más como una pregunta general de la que otras personas también podrían beneficiarse :) – Latze

Respuesta

12

Estoy seguro de que se puede hacer fx. en PHP validando formularios

No realmente. La etapa de entrada es completamente el lugar equivocado para abordar problemas de XSS.

Si el usuario escribe, digamos <script>alert(document.cookie)</script> en una entrada, no tiene nada de malo en eso. Acabo de hacerlo en este mensaje, y si StackOverflow no lo permitiera, ¡tendríamos grandes dificultades para hablar de JavaScript en el sitio! En la mayoría de los casos, desea permitir cualquier entrada (*), de modo que los usuarios puedan usar un carácter < para significar literalmente un signo menor que.

El hecho es que cuando escribe texto en una página HTML, debe escaparlo correctamente para el contexto en el que se encuentra. Para PHP, eso significa que el uso de htmlspecialchars() en la etapa salida:

<p> Hello, <?php echo htmlspecialchars($name); ?>! </p> 

[pista PHP: puede ser definida por una función con un nombre más corto que ver echo htmlspecialchars, ya que este es un buen montón de escribir para hacer cada hora en que desea poner una variable en algún código HTML.]

Esto es necesario independientemente de dónde provenga el texto, ya sea desde un formulario enviado por el usuario o no. Si bien los datos enviados por los usuarios son el lugar más peligroso para olvidar su codificación HTML, lo importante es que está tomando una cadena en un formato (texto plano) e insertándola en un contexto en otro formato (HTML).Cada vez que arroje texto a un contexto diferente, necesitará un esquema de codificación/escape apropiado para ese contexto.

Por ejemplo, si inserta texto en un literal de cadena de JavaScript, tendría que escapar del carácter de comillas, la barra diagonal inversa y las líneas nuevas. Si inserta texto en un componente de consulta en una URL, necesitará convertir la mayoría de los caracteres no alfanuméricos en secuencias %xx. Cada contexto tiene sus propias reglas; tienes que saber cuál es la función correcta para cada contexto en tu lenguaje/marco elegido. No se pueden resolver estos problemas manipulando los envíos de formularios en la etapa de entrada, aunque muchos programadores de PHP ingenuos lo intentan, razón por la cual muchas aplicaciones confunden su entrada en casos de esquina y aún no son seguras.

(*: bueno, casi cualquier. Hay un argumento razonable para filtrar los caracteres de control ASCII del texto enviado. Es muy poco probable que permitirlos sería bueno. Además, por supuesto, tendrá validaciones específicas de la aplicación que querrá hacer, como asegurarse de que un campo de correo electrónico se asemeje a una dirección de correo electrónico o que los números sean realmente numéricos. Pero esto no es algo que se pueda aplicar de manera general a todas las entradas para que no tenga problemas.)

9

Los ataques de scripts cruzados (XSS) se producen cuando un servidor acepta la entrada del cliente y luego escribe ciegamente esa entrada en la página. La mayor parte de la protección contra estos ataques implica el escape de la salida, por lo que el Javascript se convierte en HTML sin formato.

Una cosa a tener en cuenta es que no solo los datos que provienen del cliente pueden contener un ataque. Un ataque Stored XSS implica la escritura de JavaScript malicioso en una base de datos, cuyos contenidos son luego consultados por la aplicación web. Si la base de datos se puede escribir por separado del cliente, es posible que la aplicación no pueda asegurarse de que los datos se hayan escapado correctamente. Por este motivo, la aplicación web debe tratar TODA la información que escribe al cliente como si pudiera contener un ataque.

Ver este enlace para un recurso a fondo sobre la forma de protegerse a sí mismo: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

+0

Gran punto - Veo demasiado hablar de "borrar entradas", cuando en realidad eso no siempre es posible o incluso sabio, y no resuelve completamente el problema de todos modos. Las soluciones deben suceder en el momento de salida. Además, es importante tener en cuenta que HTML no es el único contexto vulnerable: SQL Injection es realmente una variación del mismo tema. – Pointy

+0

Validar entradas, salidas de escape –

Cuestiones relacionadas