0150 como desarrollar_aplicaciones_seguras_con_gene_xus
•Télécharger en tant que ODP, PDF•
0 j'aime•1,131 vues
![Cómo desarrollar aplicaciones seguras con GeneXus Diego Rostagnol - Universal ST - [email_address] Twitter: @elrosti Martín Oliveri – Artech](https://image.slidesharecdn.com/0150comodesarrollaraplicacionessegurascongenexus-100915094230-phpapp01/85/0150-como-desarrollaraplicacionessegurascongenexus-1-320.jpg)
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (10)
Similaire à 0150 como desarrollar_aplicaciones_seguras_con_gene_xus
Similaire à 0150 como desarrollar_aplicaciones_seguras_con_gene_xus (20)
Plus de GeneXus
Plus de GeneXus (20)
0150 como desarrollar_aplicaciones_seguras_con_gene_xus
- 1. Cómo desarrollar aplicaciones seguras con GeneXus Diego Rostagnol - Universal ST - [email_address] Twitter: @elrosti Martín Oliveri – Artech
- 2. Dos áreas Servidor Aplicación
- 4. Autorización : Se produce después de la Autenticación y es el proceso por el cual obtenemos o no permisos para efectuar una determinada acción.
- 6. Evitar que personas no autorizadas puedan autenticarse ante mi aplicación.
- 7. Asegurar que los usuarios accedan solamente a los datos que que están autorizados a manipular.
- 9. No validar los roles en cada pantalla
- 10. Confiar en que el usuario llega a las pantallas de mi aplicación siguiendo los links en ella.
- 11. No usar las Transacciones o WebPanels como parte de mi aplicación pero quedan accesibles escribiendo la URL en el navegador.
- 12. Poner el código del usuario logueado en el form o pasarlo por parámetro
- 14. Las validaciones de los datos ingresados se deben hacer del lado del servidor.
- 15. Propiedades Visible y Enabled no aseguran que el valor de las variables o atributos no sea modificado.
- 16. No confiar en los registros cargados en las grillas.
- 18. Propiedad “Ajax Requests Security”
- 20. Se encarga de prevenir automáticamente ataques de tipo "SQL Injection".
- 21. En las Transacciones, las reglas se ejecutan en el servidor y en el cliente
- 23. Obligar al usuario a usar contraseñas fuertes.
- 24. Solicitar nuevamente el ingreso de la contraseña al modificar datos sensibles de los usuarios o acciones críticas.
- 25. Mantener un log de inicio de sesiones que el usuario pueda ver.
- 26. Controlar los intentos de acceso
- 28. ¿Que practicas de seguridad utilizan?
- 29. ¿Que parámetros evalúan para decidir cuanto esfuerzo deben poner en la seguridad de su aplicación
- 30. ¿Que problemas de seguridad han encontrado en aplicaciones de terceros?
Notes de l'éditeur
- * Cuando hablamos de seguridad en la web podemos hablar de 2 grandes areas. * El servidor, que involucra al sistema operativo, Servidor WEB, Base de Datos, etc. * La aplicación, que es con la que el usuario interactúa. * Nosotros como desarrolladores la mayoría de las veces solo deberemos preocuparnos de la seguridad dentro de la aplicación.
- La autenticación es el proceso por el cual demostramos ser quienes decimos ser. Por ejemplo mediante el nombre de usuario y contraseña. Si suponemos que digo ser "Diego" y solo yo se cual es mi contraseña y la ingreso correctamente, el sistema comprobaráque yo realmente soy "Diego". La autorización se produce luego de la autenticación y es el proceso por el cual obtenemos o no permisos para efectuar determinada acción, como puede ser acceder a ciertos datos.
- ¿ Que cosas implica encargarme de la seguridad de mi aplicación ? Mantener la seguridad de mi aplicación implica en primer lugar crear un manejo de los permisos de usuarios de mi sistema. Será mas avanzado o mas básico según nuestras necesidades. Esto nos permitirá evitar que personas no autorizadas puedan acceder a nuestra aplicación. También nos permitirá diferenciar a los usuarios de nuestro sistema y asignar los diferentes niveles de acceso a la información que nuestra aplicación maneja y de esa manera autorizar o desautorizar a los usuarios a realizar determinadas acciones.
- * No chequear que exista un usuario logueado en todas las pantallas de la aplicación. * No validar los roles en cada pantalla (a veces lo que se hace simplemente es limitar el menú a los permisos pero luego a nivel de aplicación solo se controla el usuario) * Confiar en que el usuario llega a las pantallas de mi aplicación siguiendo los links en ella y no escribiendo la URL directamente en el navegador Ej: Pongo un link a la pantalla de modificación de los datos del usuario a la que paso como parametro el ID del usuario logueado sin tener en cuenta que puedo escribir la URL del Link cambiando el código de usuario que se le pasa. * No usar las transacciones como parte de mi aplicación pero dejarlas accesibles y sin seguridad. (Escribiendo la URL en el navegador), esto permite acceso total a modificar la información existente en la base de datos de nuestra aplicación. Tambien muchas veces dejamos accesibles los webpanels generados por los pattern (ej: WorkWith) pero no los usamos todos como parte de la aplicación.
- * No se pueden confiar en las validaciones que se ejecutan en el browser. Olvidemonos por favor de hacer cosas como ocultar la barra de direcciones, poner javascript para que no pudan ver el código HTML de mi aplicación o cosas por el estilo. Continuando con lo dicho anteriormente debemos asegurarnos que las validaciones importantes se hagan del lado del servidor. Los chequeos que se jecutan del lado del servidor son mucho mas fiables. En lo posible que sean exactamente antes de hacer la inserción o modificación de los datos y en caso que sea una consulta de datos, el mejor lugar para hacer los chequeos es el evento Refresh. Usar MD5, SHA1 o similar para la encriptación de contraseñas. De esta manera es imposible que ni siquiera teniendo acceso total a la base de datos y a la aplicación la contraseña pueda ser desencriptada. También depende de cuan fuerte sea la contraseña del usuario, si es muy debil se puede descubrir mediante un ataque de fueza bruta. Tambien existen sitios que almacenan contraseñas encriptadas con MD5 generando una gran base de datos contra la cual luego se pueden comparar las contraseñas encriptadas.
- * GeneXus tiene una propiedad a nivel de objeto que nos permite automaticamente encriptar los parametros que se pasan de un objeto a otro evitando que sean manipulables facilmente. Si lo encriptamos con la opción "SiteKey" la URL de los objetos no va a cambiar durante las diferentes sessiones, esto quiere decir por ejemplo que si la dirección queda guardada en el historial del navegador, luego voy a poder usar esa misma URL para acceder a un objeto pasandole los parametros que haya usado esa vez. En cambio si utilizo "SessionKey" los parametros son encriptados con una clave diferente en cada session por lo cual la URL cambia en cada session que iniciamos. * El objeto WebSession nos permite almacenar información * Se encarga de prevenir automaticamente de ataques de "SQL Injection"
- * No se pueden confiar en las validaciones que se ejecutan en el browser. Olvidemonos por favor de hacer cosas como ocultar la barra de direcciones, poner javascript para que no pudan ver el código HTML de mi aplicación o cosas por el estilo. Continuando con lo dicho anteriormente debemos asegurarnos que las validaciones importantes se hagan del lado del servidor. Los chequeos que se jecutan del lado del servidor son mucho mas fiables. En lo posible que sean exactamente antes de hacer la inserción o modificación de los datos y en caso que sea una consulta de datos, el mejor lugar para hacer los chequeos es el evento Refresh. Usar MD5, SHA1 o similar para la encriptación de contraseñas. De esta manera es imposible que ni siquiera teniendo acceso total a la base de datos y a la aplicación la contraseña pueda ser desencriptada. También depende de cuan fuerte sea la contraseña del usuario, si es muy debil se puede descubrir mediante un ataque de fueza bruta. Tambien existen sitios que almacenan contraseñas encriptadas con MD5 generando una gran base de datos contra la cual luego se pueden comparar las contraseñas encriptadas.