php - texto - strip_tags wordpress

¿Cómo codifico HTML todo el resultado en una aplicación web?

Question

Quiero evitar ataques XSS en mi aplicación web. Descubrí que HTML Encoding the output realmente puede prevenir ataques XSS. Ahora el problema es que ¿cómo codigo HTML cada salida en mi aplicación? ¿Hay alguna forma de automatizar esto?

Aprecio las respuestas para JSP, ASP.net y PHP.

Answer 1

La única manera de protegerse realmente contra este tipo de ataque es filtrar rigurosamente todas las entradas que acepta, específicamente (aunque no exclusivamente) desde las áreas públicas de su aplicación. Le recomendaría que eche un vistazo a la clase de filtrado PHP de Daniel Morris (una solución completa) y también al paquete Zend_Filter (una colección de clases que puede usar para construir su propio filtro).

PHP es mi lenguaje de elección cuando se trata de desarrollo web, así que me disculpo por el sesgo en mi respuesta.

Kieran.

Answer 2

Mi preferencia personal es codificar diligentemente cualquier cosa que provenga de la base de datos, la capa de negocios o del usuario.

En ASP.Net esto se hace usando Server.HtmlEncode(string) .

La razón para codificar algo es que incluso las propiedades que suponga que sean booleanas o numéricas podrían contener código malicioso (por ejemplo, los valores de la casilla de verificación, si se hacen incorrectamente, podrían volver como cadenas. Si no los está codificando antes) enviando la salida al usuario, entonces tienes una vulnerabilidad).

Answer 3

No desea codificar todo el HTML, solo desea codificar en HTML cualquier entrada del usuario que esté generando.

Para PHP: htmlentities y htmlspecialchars

Answer 4

Puede envolver eco / impresión, etc. en sus propios métodos, que luego puede usar para escapar de la salida. es decir, en lugar de

echo "blah";

utilizar

myecho(''blah'');

incluso podría tener un segundo parámetro que se desactiva escapando si lo necesita.

En un proyecto, teníamos un modo de depuración en nuestras funciones de salida que hacía invisible todo el texto de salida que pasaba por nuestro método. ¡Entonces sabíamos que no quedaba nada escapado en la pantalla! Fue muy útil para rastrear esos bits sin protección travieso :)

Answer 5

Si realmente codificas HTML en cada salida, el usuario verá texto sin formato de & lt; html & gt; en lugar de una aplicación web en funcionamiento.

EDITAR: Si HTML codifica todas las entradas, tendrá problemas para aceptar una contraseña externa que contenga <etc.

Answer 6

Una buena forma en que solía escapar de todas las entradas del usuario es escribiendo un modificador para smarty que escapa todas las variables pasadas a la plantilla; a excepción de los que tienen | unescape unido a él. De esta manera, solo le da acceso HTML a los elementos a los que explícitamente le da acceso.

Ya no tengo ese modificador; pero sobre la misma versión se puede encontrar aquí:

http://www.madcat.nl/martijn/archives/16-Using-smarty-to-prevent-HTML-injection..html

En la nueva versión de Django 1.0 esto funciona exactamente de la misma manera, jay :)

Answer 7

Una cosa que no debe hacer es filtrar los datos de entrada a medida que ingresa. La gente suele sugerir esto, ya que es la solución más fácil, pero genera problemas.

Los datos de entrada se pueden enviar a múltiples lugares, además de ser enviados como HTML. Puede ser almacenado en una base de datos, por ejemplo. Las reglas para filtrar los datos enviados a una base de datos son muy diferentes de las reglas para filtrar la salida HTML. Si codifica en HTML todo en la entrada, terminará con HTML en su base de datos. (Esta es también la razón por la cual la función de "citas mágicas" de PHP es una mala idea).

No puedes anticipar todos los lugares en los que viajarán tus datos de entrada. El enfoque seguro es preparar la información justo antes de enviarla a algún lado. Si lo estás enviando a una base de datos, escapa de las comillas simples. Si está produciendo HTML, escapa de las entidades HTML. Y una vez que se envía a alguna parte, si todavía necesita trabajar con los datos, use la versión original sin escape.

Esto es más trabajo, pero puede reducirlo mediante el uso de motores de plantillas o bibliotecas.

Answer 8

Para las JSP, puede tener su pastel y comérselo también, con la etiqueta c: out, que se escapa de XML de manera predeterminada. Esto significa que puede vincular sus propiedades como elementos sin procesar:

<input name="someName.someProperty" value="<c:out value=''${someName.someProperty}'' />" />

Cuando se vincula a una cadena, someName.someProperty contendrá la entrada XML, pero cuando se envíe a la página, se escapará automáticamente para proporcionar las entidades XML. Esto es particularmente útil para enlaces para la validación de páginas.

Answer 9

OWASP tiene una buena API para codificar salida HTML, ya sea para usar como texto HTML (por ejemplo, párrafo o <textarea> contenido) o como el valor de un atributo (por ejemplo, para etiquetas <input> después de rechazar un formulario):

encodeForHTML($input) // Encode data for use in HTML using HTML entity encoding
encodeForHTMLAttribute($input) // Encode data for use in HTML attributes.

El proyecto (la versión de PHP) está alojado en http://code.google.com/p/owasp-esapi-php/ y también está disponible para algunos otros idiomas, por ejemplo, .NET.

Recuerde que debe codificar todo (no solo la entrada del usuario), y lo más tarde posible (no cuando se almacena en DB, pero cuando se envía la respuesta HTTP).

Answer 10

La codificación de salida es, con mucho, la mejor defensa. La validación de entrada es excelente por muchas razones, pero no es 100% de defensa. Si una base de datos se infecta con XSS a través de un ataque (es decir, ASPROX), la validación de la entrada de errores o malicia no hace nada. La codificación de salida seguirá funcionando.

Answer 11

hubo un buen ensayo de Joel sobre el software (hacer que el código incorrecto se vea mal, creo, estoy en mi teléfono, de lo contrario tendría una URL para ti) que cubría el uso correcto de la notación húngara. La versión corta sería algo así como:

Var dsFirstName, uhsFirstName : String;

Begin

uhsFirstName := request.queryfields.value[''firstname''];

dsFirstName := dsHtmlToDB(uhsFirstName);

Básicamente prefija sus variables con algo como "nosotros" para cadena insegura, "ds" para la base de datos segura, "hs" para HTML seguro. Solo quiere codificar y decodificar donde realmente lo necesita, no todo. Pero al usar los prefijos que infieren un significado útil mirando tu código, verás muy rápido si algo no está bien. Y va a necesitar diferentes funciones de codificación / decodificación de todos modos.