Desarrollo seguro de aplicaciones web: Errores más comunes.

¿Qué errores de seguridad no deben hacer nunca durante desarrollo de aplicaciones web? Para ayudar a responder esta pregunta, existen algunas políticas de buenas prácticas y consejos de algunos expertos (yo no, por supuesto), en seguridad informática.

A continuación, aquí os detallo una lista con algunas de las más importantes, en mi modesta opinión:

1. Desarrollo de sus propios métodos de seguridad

Algunos desarrolladores hacen suposición errónea de que un algoritmo de cosecha propia para el método de autenticación en realidad hará más seguro. Después de todo, los hackers nunca lo han visto antes, así que tendrían más problemas en romperlo. Esto es incorrecto. Desarrollar su propio método de autenticación o métodos de entrada es un error porque usted hará errores que hacker descubrirá.

¿Por qué son las librarías existentes son más seguras? Porque se ponen a pruebas de penetración constantemente por la comunidad de seguridad. Como tales, son menos propensos a incluir grandes agujeros de seguridad que una persona pueda pasar por alto.

2. El acceso a la base de datos directamente con la información suministrada por el usuario. 

Al desarrollar aplicaciones, y en particular una aplicación web, muchos desarrolladores no adecuadamente validan los datos que reciben de los usuarios. Este es un problema de seguridad de datos, ya que podría invalidar toda su base de datos, pero aún tiene mayores implicaciones de seguridad. Según los expertos en seguridad informática, si no se validan las entradas, los ataques de cross site scripting, inyección de SQL, desbordamiento de búfer, y otros ataques comunes puedrán suceder.

Este es uno de los errores más comunes que se encuentran en cualquier aplicación web como los hackers pueden utilizar campos de entrada para inyectar código malicioso en su aplicación y acceder base de datos. Por supuesto, la mayoría de los usuarios nunca va a intentar nada malicioso, pero hay que acercarse a la entrada de datos con una mentalidad defensiva.

3. Centrarse en los componentes y no el sistema completo.

Con grandes proyectos de desarrollo, donde varios desarrolladores trabajan en diferentes partes de una aplicación, hay una tendencia a centrarse en los componentes individuales en lugar de en el sistema completo. Cada parte puede ser segura por sí sola, pero, ¿serán tan seguras cuando estén juntas? Por lo tanto, es importante comprobar la seguridad del sistema completo.

4. Adición de seguridad en el desarrollo final.

Adición de seguridad en la fase final de su desarrollo de aplicaciones podría ser un problema. No es algo que simplemente puede añadir al término de desarrollo. Es una función de toda la arquitectura de aplicación según experiencia de expertos de servicios de pruebas de penetración.

5. Permitiendo a los usuarios a crear contraseñas débiles.

Cada vez los hackers atacan una aplicación web y exponen las contraseñas de usuario, una cosa inmediatamente clara que los usuarios tienen horribles hábitos respecto a la seguridad. La contraseña más popular en la mayoría de instancias es 12345. Como desarrollador de aplicaciones web, no se puede permitir que los usuarios crean contraseñas débiles.

6. El almacenamiento de contraseñas en texto plano.

El error más común los desarrolladores de aplicaciones web es no almacenar las credenciales de autenticación de forma cifrada en bases de datos. Las credenciales de autenticación deben ser almacenados de forma cifrada según consejos de expertos de pruebas de penetración.

Referencias:

https://blog.sucuri.net/espanol/

http://www.webimprints.com/index_es.html

https://es.wikipedia.org/wiki/Cross-site_scripting

https://www.owasp.org/index.php?title=Cross-site_Scripting_(XSS)&setlang=es

https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/

https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL

http://php.net/manual/es/security.database.sql-injection.php

http://buzzupp.com/how-to-secure-your-wordpress-website-from-cross-site-scripting/

http://revista.seguridad.unam.mx/numero23/uno-de-los-cl-sicos-buffer-overflow