Question

Premisas:

Lenguaje(s) de programación: PHP, javascript, jquery, html
Bases de datos: SQL Server
Navegadores usados para testeos: Internet Explorer 10, Chrome (latest), Mozilla Firefox (Latest), Safari (latest)
Navegadores usados por los usuarios del sistema: mayoritariamente IE9 o superior pero hay de todo.

Mas que una pregunta este nuevo hilo va en relación a las buenas costumbres que tenéis a la hora de crear un formulario.

Este asunto surge a raíz de un test de penetración que ha hecho una compañía externa a nuestra web, en dicha web tenemos varios formularios e inputs y han detectado varios de ellos que admiten la inyección XSS con comandos como

<script>
alert('hello');
</script>

Me gustaría en esos campos realizar algún tipo de control pero sin que los valores lleguen a tocar el servidor ya que hay algunos comandos que de llegar al servidor se ejecutarían (supongo).

Es por esto que pregunto qué métodos utilizáis? Había pensado en HTML 5 y pattern pero ayer mi compañero se saltó con su navegador (Safari para Apple) el pattern type="email" de un input y metió es script a correr.

Cuales son buenas costumbres a la hora de construir un formulario y validar todos los campos para que no os inyecten ni XSS ni SQL-injection ni nada que os pueda suponer una brecha de seguridad?

SaludoS!!

Answer 1

En primer lugar mi estimado, si haces una consulta a una persona en particular mejor usa algo más privado, un MP por ejemplo.

Información

En primer lugar, toda validación hecha en el cliente puede ser fácilmente vulnerada porque el atacante puede modificarla y crear peticiones personalizadas. La validación debe estar en ambas partes, tanto en cliente como en servidor. La validación en el servidor debe ser muy estricta ya que si se logra ejecutar código malicioso aquí estaríamos en graves problemas.

XSS

Sin duda XSS persistente es el más peligroso ya que éste se almacena en la bbdd de tal manera que afecta a todos los usuarios y no solo a uno. Es tremendamente peligroso y útil para el atacante ya que puede realizar un ataque masivo.

SQLi

SQLi está en otro nivel: meramente ataques a la BBDD. Si tu aplicación o web está programanda careciendo de validaciones, tienes un 90% de probabilidades que sea vulnerable a SQLi. Algunos lenguajes disminuyen drásticamente la probabilidad de producirse este ataque como es Java, el cual mediante Java Persistence API (JPA) y JPQL ya que su modo de trabajar erradica prácticamente toda posibilidad de tener un SQLi, salvo que concatenes una consulta con un dato recibido.

Formas de prevención

XSS

Para prevenir un XSS es necesario tener en el servidor un código llamado sanitizador que sirve para validar todos los datos recibidos en el payload de una petición HTTP. Con ayuda de este script podemos comprobar si se está queriendo vulnerar nuestra web/aplicación. Por ejemplo, un sanitizador clásico y funcional debe de analizar lo siguiente:

• URL
• Objectos HTTP referidos
• Parámetros GET/POST de un form
• Window.location
• Cookies
• Headers (muy usados actualmente)

Y también algunas propiedades de document:

• Document.referrer
• document.location
• document.URL
• document.URLUnencoded

Con esto cubrirás la mayoría de vulnerabilidades.

SQLi

Para evitar un SQL injection es elemental tratar con consultas preparadas (Prepared Statements) y consultas parametizadas. En tu caso si estás usando PHP puedes utilizar herramientas que te provee el lenguaje como mysql_real_escape_string o UNHEX para un buen escape de parámetros. En otros lenguajes como Java, ya se cuenta con una API para acceso a BBDD que erradica gran parte de probabilidades de sufrir un SQLi.