seguridad en la programacion web: conceptos

Ya sé que hace mucho tiempo que no escribo nada pero ahora les tengo un artículo que se que les va a gustar, en especial a los desarrolladores/programadores, sysadmins y demás. Se trata de la seguridad en la WEB a nivel de programación. Debo aclarar que los temas que tocare aqui son de parte del cliente, luego escribiré algo sobre seguridad en servidores.

En los 9 años que tengo como desarrollador web, he conocido muchísimas personas que de una manera u otra no están muy claro o convencidos de la importancia de este tema a la hora de desarrollar una aplicación, muchos de ellos incluso piensan que el internet es una utopía donde nadie tiene malas intenciones, que bonito seria si fuera cierto, pero no lo es.

No es que yo sea el más experto en el tema, pero he logrado entender ciertas cosas que pretendo explicar de manera conceptual para no encerrarme en un lenguaje u otro, pero bueno, a lo que vinimos.

XSS 

XSS o Cross-Site Scripting , nada tiene que ver con CSS, no es más que un agujero de seguridad que se basa en explotar vulnerabilidades en nuestro HTML. Básicamente es inyectar un código de parte del cliente en nuestro código web y de esta forma manipular los datos a nuestro antojo. Creo que la mejor forma de verlo es con un ejemplo:

Tenemos un formulario que al ser enviado remite a la url http://www.mipagina.com, sin embargo mediante alguna de las diversas técnicas logramos modificar el formulario y hacer que apunte a nuestra propia web http://www.mipaginafalsa.com, en ella recogemos la información recibida, la almacenamos/procesamos y luego hacemos con ella lo que queramos o incluso el caso contrario, nuestro mismo formulario que apunta a http://www.mipagina.com envía algún dato que queremos ver como "reacciona", pues clonamos el formulario en nuestro propio cliente y lo apuntamos a la misma url, de esta forma podemos darnos el lujo de manipular la forma en que los datos entran y ver como actúa la pagina destino.

Mediante esta técnica se pueden modificar cookies, sesiones, robar identidades, modificar funciones, clonar formularios y demás, todo lo que una página web NO segura nos permita.

Puede que vean esto como algo no tan peligroso o incluso inocente ya que todo se maneja de lado del cliente y podrán decir "si, pero el daño que me haga solo será para mí", pues se equivocan, ya que ahí entran técnicas como el phishing, los spyware, los bugs y la ingeniería social para extraer información de un usuario haciéndole creer que está en una página que realmente no está y luego redireccionandolo a la real e incluso mediante el uso de AJAX, es bien facil tomar el control de muchas cosas, si no se tiene la seguridad adecuada.

Como evitar el XSS en nuestro site

El primero paso es filtrar, filtrar caracteres especiales como: ( ) < > # $ " ' | ? & y cualquier otro caracter que se pueda interpretar como parte de un lenguaje de cliente. También es conveniente de alguna manera que la pagina destino (en el caso de formularios o AJAX) reconozca de alguna manera el origen de la información, ya sea con alguna clave encriptada, alguna sesión, cookie o algo que para el usuario mal intencionado no sea tan fácil de deducir. 

Es importante destacar que la encriptación mediante certificados de seguridad (HTTPS) NO es más seguridad que un website que no lo posea, pues como vengo diciendo desde el inicio, esto es algo puramente del lado del cliente y los certificados se manejan por el servidor.

PHISHING 

El PHISHING no es más que el robo de identidad de una empresa (mayormente bancos o proveedores de correo) para conseguir los datos personales de un usuario.

Esta es una técnica que recientemente está muy de moda debido a la facilidad con la que los usuarios caen.

Básicamente consiste en clonar nuestro sitio web pero hospedado en su servidor, luego utilizar algo de ingeniería social mediante un correo que se vea bastante convincente y dejarle entender al usuario que su información es requerida por alguna razón. El correo posee un enlace donde el usuario (por comodidad o alguna otra razón) simplemente da clic para no tener que digitar ninguna url y así cae en la trampa.

Como evitar el phishing

A nivel de programación no creo que haya mucho que podamos hacer, pues no podemos prevenir que alguien cree un diseño idéntico al nuestro y envíe los correos, sin embargo aun nos queda una esperanza. Podemos contraatacar los correos de phishing con correos de conciencia para el usuario, pedirles que escriban la url en lugar de dar clic a los enlaces del correo es una buena opción, así como dejarles entender cuál debe ser el servidor (host) al que deben entrar (Ej. www.mipagina.com y no www.otrapagina.com/mipagina), que revisen que (en caso de que aplique) la url posee certificado de seguridad (HTTPS en lugar de HTTP) e incluso me atrevería a sugerir que expliquen brevemente que significa la S al final del HTTP, no es tan difícil de entender y muchas personas podrían sentirse mucho más confiados de esto.

SQL INJECTION 

En mi opinión, el más uno de los más terribles ataques web a nivel de capa 7 (aplicaciones). Se basa en introducir código maligno en nuestra entrada de forma que este código se filtre al nuestro y modifique nuestros parámetros. Nuevamente, es más fácil verlo con un ejemplo:

Si tenemos un formulario A, que va a una página B, y queda una url del tipo:

www.mipagina.com/B.php?i=3&a=prueba

y esta genera la siguiente consulta:

SELECT * FROM mitabla WHERE AND nombre='prueba'

Pero si logramos modificar el formulario de forma que nos quede la url:

www.mipagina.com/B.php?i=3&a=' OR ''='

Al interpretar quedaria algo asi:

SELECT * FROM mitabla WHERE AND nombre='' OR ''=' ';

Y como sabemos que null=null, se cumple la sentencia y traeria todos los registros de nuestra tabla mitabla, fácil y rápidamente.

Claro está que en ese simple ejemplo traeríamos los registros, pero el SQL INJECTION también aplica para inserts, updates  o simplemente para traer información que realmente queremos como números telefónicos, números de tarjetas de créditos, contraseñas, etc.

¿Que hacer para prevenirlo?

Siempre escapar los datos que el usuario entra, al igual que en el XSS, en el SQL INJECTION se deben reemplazar los caracteres especiales y sustituirse por su equivalente HTML y de ser posible, al ahora de enviar variables por la url, codificarlas.

También es importante tener en cuenta la forma como estructuramos nuestras consultas a las bases de datos. Ponérsela incómoda al intruso siempre es buena opción.

JAVASCRIPT INJECTION

Un tema tal vez un poco comentado en la web es el del JAVASCRIPT INJECTION, esta técnica es bastante similar al SQL INJECTION, solo que se basa en inyectar código javascript a una url mediante la barra de direcciones del navegador. De que nos sirve esto? para modificar funciones, objetos, valores, cookies, sesiones y demás.

Es más peligroso de lo que puede sonar pues unido con AJAX, podría enviar datos "sucios" al servidor para así extraer lo que sea de interés.

No creo que deba profundizar mucho al respecto, pues es bastante similar al SQL INJECTION.

¿Cómo evitar que me inyecten javascript?

Hay tantas formas y posibilidades de ataques que en realidad no hay una respuesta directa de cómo evitarlo, así que tratare de cubrir los casos más comunes y si tienen algún problema en particular no duden dejármelo saber en los comentarios, junto con su correo y les puedo enviar alguna que otra sugerencia (pero ojo, no soy ningún genio de seguridad).

En el caso de formularios, siempre es bueno encriptar o al menos codificar la información a enviar, escaparla para evitar caracteres que se puedan concatenar con los nuestros.

En caso de autenticación manejada por la aplicación (y no por el servidor como tal o por el protocolo) creo que sobra decir que los datos siempre deben estar encriptados

En lo posible, si pueden definir sus propias "pseudo etiquetas" pues mejor. Por ejemplo, en lugar de usar como el tag, tal vez sea más conveniente usar [html] y que su lenguaje de servidor, encargado de procesar la información interprete estas etiquetas y aplique las equivalentes. Sé que puede sonar muy complejo pero la verdad a medida que la seguridad aumento, lo simple y la comodidad disminuye.

En resumen

Algunos consejos generales que ayuda en todo:

• SIEMPRE escapen los valores que los usuarios envíen por su equivalente en HTML. Como ejemplo, en php lo pueden hacer usando la función HTML2ENTITIES, de esta forma evitamos concatenaciones
• Limiten en lo posible la información que muestran al usuario. URL, Actions de formularios y demás, dentro de lo posible es bueno ocultarlo o apuntarlo a direcciones no reales que despisten al usuario malintencionado.
• Testing, tests, tests, tests y mas tests! muchas pruebas antes de salir a ambiente real, pídanle a varios usuarios que entren a la etapa beta de su aplicación, que la usen, que inventen y les reporten que sucedió.
• Utilicen herramientas de monitoreo y simuladores. Un simulador de SQL INJECTION es una buena herramienta, un medidor de stress es muy util, pues sabemos que tan fácil o difícil nuestra aplicación web es derrotada.
• Siempre encripten la información sensible, codifiquen la que no lo sea tanto, pero traten de nunca enviar información en su forma plana, pues recuerden que este articulo es solo para el lado de aplicaciones, pero también hay fallas de seguridad del lado del servidor y/o del cliente.

Creo que será todo por ahora, cualquier cosa no duden en dejarme saber mediante sus comentarios, siempre son bien recibidos.

Gracias y hasta la próxima...