5 cuestiones sobre seguridad en programación que siempre deberías tener en cuenta
Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

5 cuestiones sobre seguridad en programación que siempre deberías tener en cuenta

Seguridad-Codigo

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 cosa 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:

  1. 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.
  2. 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 las conozcáis ni podáis recuperarlas.
  3. No reinventes la rueda. Y lo anterior nos lleva a otro fallo muy común que es el síndrome 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ú.
  4. 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 proporcionar 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.
  5. 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.

Podrían ser muchos más, pero estos 5 son quizá los más importantes, así que no los pierdas de vista nunca.

campusMVP campusMVP es la mejor forma de aprender a programar online y en español. En nuestros cursos solamente encontrarás contenidos propios de alta calidad (teoría+vídeos+prácticas) creados y tutelados por los principales expertos del sector. Nosotros vamos mucho más allá de una simple colección de vídeos colgados en Internet porque nuestro principal objetivo es que tú aprendas. Ver todos los posts de campusMVP

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.

Archivado en: General

Comentarios (4) -

3.- No reinventes la rueda.
--------------------------
  Bueno, esto es una verdad a medias. Es cierto que ya hay funciones para muchas cosas y no sería bueno "reinventarlas", pero también en cierto que muchas de esas funciones fallan cuando más lo necesitas, sinó ahí esta la función nativa de VB.Net para generar números aleatorios, los datos los toma del reloj del sistema, tengan su equipo encendido por semanas y verán como esta función produce un overflow. Así que tuve que reinventar mi función aunque no quisiera.

Responder

¿Estás seguro de que era un bug del generador de números aleatorios de .NET? ¿O era un bug en la forma de utilizarlo? Que sepamos no ha habido nunca un bug en esta parte de .NET... aunque sí problemas por no utilizarlo adecuadamente (por ejemplo, instanciar Random varias veces seguidas en bucles y cosas similares).

En cualquier caso, crear un generador de números pseudo-aleatorios no es una tarea trivial y desde luego no es algo que esté al alcance de cualquiera. Uno no debería hacer eso jamás. Para eso están los frameworks.

Finalmente, que una afirmación sea cierta en la inmensa mayoría de los casos no quiere decir que no haya excepciones, aunque son necesariamente pocas y realmente deberían estar muy justificadas.

Saludos.

Responder

Pues no se, pero cuando yo requería ese número obtenía ese mensaje de error y francamente ya me desesperó en su momento. Yo se que no hay códigos perfectos y es por ello que no podemos afirmar que si Microsoft (o cualquier otro) libera una función, esta no va a fallar nunca, eso no es posible, no existe el sistema a prueba de fallas y en mi caso, quizá halla sido una mala implementación de mi parte,  pero si me vi en un problema que honestamente saca de casillas y más si estás con el tiempo encima.
  De cualquier forma gracias por las observaciones, saludos.

Responder

He visto varios articulos en este sitio, y de veras que el lenguaje utilizado es muy profesional, llega a todos, expertos o no en el tema informatico. No he podido salir de aqui pues me encuentro con consejos y noticias interesantes que aunque lleves tiempo en este mundo, siempre son validas y necesarias, sinceramente de los mas claros y explicitos que he visto, son una referencia, en serio.
He intercambiado con José M. Alarcón y admiro el trabajo que hacen, un saludo y continuen así. Gracias

Responder

Agregar comentario