5 cuestiones sobre seguridad que siempre deberías tener en cuenta
Cada vez dependemos más del software. Está en todas partes, y no solo dentro de nuestras pantallas. Algunos fallos pueden ser catastróficos, y especialmente todos los que tienen que ver con la seguridad y la privacidad, que van siempre muy relacionadas. A pesar de ello sigue siendo muy frecuente que los programadores no tengan la seguridad presente todo el tiempo mientras desarrollan.
En ocasiones la actitud de los programadores hacia la seguridad es que ésta es cosas de la gente de sistemas, con sus cortafuegos, IDS y demás medidas de control. Sin embargo la mayor parte de las vulnerabilidades de seguridad tienen que ver con el código y cómo está escrito. Es indispensable hacerse a la idea de que la seguridad debe tenerse en cuenta en todas las fases de desarrollo de un proyecto de software, y no ser un pensamiento posterior, cuando ya lo principal está desarrollado.
Por eso hemos recopilado los 5 principales consejos sobre seguridad que deberías tener en mente siempre mientras programas, y que te ayudarán a conseguir sistemas más confiables y seguros:
- Jamás te fíes de ningún dato. Este parece obvio, pero luego no siempre se tiene en cuenta. Cualquier dato que llegue a tu código desde un sistema del que tú no tienes control debe ser considerado sospechoso por defecto. No llega con validar en el lado cliente los datos que introducen los usuarios, siempre debe validarse en el servidor también. Si recibes una cadena de texto ten en cuenta todas las posibilidades, incluyendo símbolos "raros", la longitud máxima que esperas (no se vaya a producir un desbordamiento), que estén intentando colarla a la base de datos para inyectar instrucciones SQL. Verifica todos los datos siempre. Punto. Es un fastidio pero es la regla número 1 de cualquier sistema seguro.
- Almacena exclusivamente lo que necesites. Ni un byte más de lo necesario. Cuando almacenas información que no necesitas estás ampliando la superficie de ataque posible. No solo nos referimos a almacenar esos datos en una base de datos o en un almacenamiento permanente (que también), sino incluso en memoria. Por ejemplo, un caso muy habitual es almacenar las contraseñas de los usuarios en claro en la base de datos. Esto aparte de ser un agujero de seguridad clarísimo es ilegal (al menos en Europa debido a las leyes de protección de datos). Almacena solamente un resumen digital de las claves y que ni siquiera vosotros conozcáis esas claves ni podáis recuperarlas.
- No reinventes la rueda. Y lo anterior nos lleva a otro fallo muy común que es de "No inventado aquí". Hay programadores (y empresas) a los que no les gusta que haya código ajeno en sus desarrollos, y al final acaban por hacer por su cuenta cosas que están solucionadas hace tiempo. Aparte de ser un error empresarial es un error importante cuando se trata de esquemas que tienen que ver con la seguridad. La encriptación, los resúmenes digitales, etc... están basados en matemáticas complejas, se producen avances constantemente... y tenemos la suerte de vivir en la era del Open Source, así que -especialmente en seguridad- haz uso de alguna de las maravillosas bibliotecas existentes y probadas. Incluso aunque se descubra algún fallo en algún momento van a funcionar mejor que cualquiera que puedas hacer tú.
- Limita los privilegios: lo más fácil, por ejemplo, es crear un usuario con acceso como administrador a la base de datos y utilizarlo desde nuestro código. Así nos evitamos errores por falta de permisos o el tener que hacer un ajuste fino tabla por tabla, campo por campo, para fijar los privilegios exactos que ese usuario necesita. El problema es que cuando se produce un problema de seguridad, nuestra aplicación actúa de intermediaria entre el atacante y la base de datos, dejándole las puertas abiertas de par en par. Grave error. Pues lo mismo en cualquier otro ámbito de la aplicación: hay que dar a cada usuario o proceso los privilegios exactos que necesite, y ni uno más. Es más trabajoso pero hará tus aplicaciones mucho más seguras.
- La seguridad es una carretera de dos sentidos. Esto es algo que se piensa mucho menos todavía que lo anterior. Cuando un usuario "normal" se conecta a nuestra aplicación de banca, por poner un caso extremo, no solo debemos asegurarnos de que es quien dice ser, sino que es igualmente importante que esa persona tenga claro que nosotros somos quiénes decimos ser. Un certificado digital asegura eso, pero la mayor parte de los usuarios no se fijan en estas cosas y si un malhechor los lleva a un sitio que suplanta el nuestro y que no usa SSL, el 90% jamás se percatarán. Algunas empresas lo que hacen es permitir a los usuarios la personalización de sus accesos, de modo que una vez que están dentro del sistema se les muestra junto a la aplicación una foto o una frase que ellos mismos han elegido. Un sitio de phishing no puede tener esa información por lo que si no aparece enseguida se dan cuenta de que no están en donde debieran. Este tipo de cuestiones es importante tenerlas en cuenta también al desarrollar.
http://stats2.mailcast.es/client/previewissue.asp?IssueId=31114
Comentarios
Publicar un comentario