Mostrando entradas con la etiqueta seguridad web. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad web. Mostrar todas las entradas

domingo, 10 de abril de 2011

Incidentes para recordar de los últimos dos meses


Llevamos una temporadita fina y elegante en cuanto a hacking e incidentes varios de seguridad informática. Como sé que me perderé si no lo escribo, aquí va esta entrada como una especie de lista de sucesos interesantes a recordar. Sin otro orden más que lo que voy encontrando:
  • El de la empresa RSA, por el que pudo llegar a obtenerse información sobre su producto de autenticación SecurID. Aquí hay una carta abierta de RSA sobre el tema. La forma de perpetrar el ataque fue un phishing a uno de los empleados de la compañía, que recibió un correo con un fichero excel malicioso adjunto, que explotaba una vulnerabilidad en Adobe Flash. Se explica de forma extendida aquí y aquí.
  • El de los foros de Telecinco, se puede ver el defacement hecho aquí.
Ahí es nada.

Actualización 12/04/2011: ayer le tocó a Barracuda.
Actualización 27/05/2011: y durante el último mes, muy duramente a Sony.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, seguirlo en Twitter, o

domingo, 14 de noviembre de 2010

la especificación de las cookies


A cuento del post de hace un mes y algo sobre las cookies y sus tamaños, os dejo un post rapidito para mencionar un artículo muy bueno sobre las debilidades en la especificación de las cookies HTTP, en el blog de lcamtuf.

Nos cuenta sobre los orígenes de las cookies, de sus flags más conocidos, y una serie de problemillas de seguridad muy interesantes que surgen debido a la forma en que se especificó su uso. Para no perdérselo.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS o seguirlo en Twitter...

martes, 14 de septiembre de 2010

cookies y sus tamaños


Hoy que me han dejado algo de tiempo para leer y ponerme al día, he estado leyendo entre otras cosas, este magnífico paper de la presentación de Robert Hansen y Josh Sokol en Blackhat, sobre cómo HTTPS no es bastante para garantizar la confidencialidad de la información de un sitio web. En el paper, y después en este post, se menciona un detalle que llama la atención: es posible hacer una denegación de servicio, no a un sitio web entero, sino a una porción del mismo nada más.

¿Cómo?. Inyectando una cookie demasiado grande en el navegador del usuario. En el caso de que un sitio web reciba una cookie demasiado grande... ¿qué puede pasar?. Algunas opciones posibles para que se dé este DoS son:
  • el valor de la cookie malformada, una vez recibido por el servidor de web, es almacenada en una o más variables en el aplicativo web correspondiente. Podría darse el caso de que esta variable tenga un límite de tamaño, y por tanto que fuera posible realizar un overflow. Y por tanto, ser posible una denegación de servicio. Esta posibilidad depende, por supuesto, de cómo se haga la gestión de memoria a nivel de sistema y en el entorno de ejecución correspondiente. Aquí va un ejemplo (extraído de la guía Owasp Testing) , en que se usa esta posibilidad sobre un aplicativo web CGI (o sea, tecnológicamente más viejo que la tos)
  • en tecnologías más modernas, podría ocurrir que la cookie de marras, al tener un valor malformado, no fuera tratada adecuadamente por la lógica del programa y se disparara una excepción no controlada (el resto os lo podéis imaginar)
  • el servidor de web recibe una petición HTTP más grande de lo que puede tratar, y la rechaza
El tercer punto es el más curioso: ¿cuál es el tamaño máximo de una petición HTTP?. Se configura en cada servidor de web. IIS 6.0 tiene un valor predeterminado de 16 KB, de acuerdo a este artículo de la web de Symantec. Para aplicaciones ASP.NET, parece que es 4MB (es el valor por defecto del parámetro httpruntimesection.maxrequestlength). Apache Tomcat 5.5 tiene un valor por defecto de 4 KB, 8 KB en Tomcat 6.0, según su documentación (véase parámetro maxHttpHeaderSize). Y es diferente para otros servidores (me gustaría tener una lista más completa, pero no tengo más tiempo para hacerla, por desgracia).

La idea, entonces, es inyectar una cookie en el navegador del usuario (con un xss, por ejemplo), lo suficientemente grande como para que se rechace la petición HTTP, asignándole como ruta una parte determinada del sitio web atacado (/logout.aspx, por ejemplo). ¿Cuál es el tamaño máximo que puede tener una cookie, en un navegador web?. ¿Cuántas cookies puedo tener por dominio?. El RFC 2965 dice que un navegador debería ("should") permitir al menos 20 cookies por dominio, con un tamaño máximo garantizado para cada una de 4 KB al menos. Internet Explorer parece que cumple de sobra, de acuerdo a este post de IEBlog de 2007.

Con lo cual, pues parece que este tipo de DoS es perfectamente posible, aunque cantará muchísimo en los logs del servidor de web, proxies, IDS, etc. No he contado nada que no se supiera ya, pero espero que la información de este post sirva: yo mismo no me sabía los detalles de los tamaños, etc, y me ha costado lo mío buscarlos. Cualquier aportación (particularmente si hay erratas), es bienvenida. Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

viernes, 27 de agosto de 2010

sdl cc


Esta es una noticia para resaltar: Microsoft cambiará el modelo de licenciamiento de su SDL, que ahora tendrá una licencia Creative Commons. Este cambio permite a todas aquellas organizaciones que deseen implantar su propia metodología de desarrollo seguro, utilizar como base (de forma legal) la información que Microsoft acoja a esta licencia. De acuerdo al blog "The Security Development Lifecycle", será bastante.

Otros modelos y guías a seguir son (no necesariamente libres o gratuitos):
Si algún otro te parece interesante, no dejes de escribir un comentario :) .


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 10 de junio de 2010

I like it


Me ha gustado este ejemplo, publicado hace unos días en el diario de SANS sobre Clickjacking.

El Clickjacking es una técnica cuyo objetivo es engañar al usuario, haciéndole creer que pulsa en un determinado enlace, cuando en realidad está utilizando otro completamente diferente. En este caso, una página maliciosa usa esta técnica para agregarse a un sitio determinado al feisbuk del usuario, mediante el plugin "Like". Para ello, se situa mediante javascript un iframe completamente invisible por encima del enlace de la página legítima, y que contiene un enlace apuntando al plugin "Like" de Facebook con la url del site malicioso como parámetro. A continuación el usuario pincha en el enlace que ve, o eso cree, porque en realidad lo hace en el enlace malicioso que tenemos en el frame oculto... Lo cuenta también Social Hacking en More recent problems in Facebook platform, así como SpamLoco, Sophos, el CCN-Cert...

Buscando medidas de defensa contra este problema, veo que se proponen medidas de frame-busting (código javascript escrito en nuestra página, con el fin de evitar que esta pueda ser colocada en un iframe), así como el uso de una cabecera no-estándar, X-FRAME-OPTIONS, que propuso Microsoft como una de las medidas de seguridad de IE8. Podemos encontrar esto en la web de Owasp, aunque me parece un resumen escaso, porque no explica bien estas dos medidas.

Este paper de la universidad de Stanford detalla muchísimo mejor un buen número de medidas de frame-busting propuestas, cómo un atacante podría saltarselas, y cuál es la forma que los autores recomiendan. Habla también de X-FRAME-OPTIONS. Además, también se mencionan algunas medidas de defensa a nivel de navegador, que es útil conocer (al final del doc, son sólo un par de líneas). Me llama la atención el que algunas medidas de seguridad, como el filtro anti-XSS de IE8, o el atributo "sandbox" de la etiqueta iframe en Html5, pueden ser usadas para cargarse precisamente la medida de frame-busting, puesta también por seguridad.

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 4 de febrero de 2010

Guías rápidas de seguridad web de Microsoft


El sitio Microsoft Security Development Lifecycle presentó hace unos cuantos días unas nuevas guías para explicar los principales ataques de seguridad en web, según puede leerse en el blog de SDL.

Estas están diseñadas para aquél que no tiene idea sobre en qué consiste el ataque, como de grave podría llegar a ser, para qué podría ser utilizado, etc, y ofrece una visión diferente sobre el ataque descrito, en función del rol que desempeñe la persona que lo lea: desarrollador, arquitecto de software, tester, así como perfiles más gerenciales (denominados "Bussiness decision makers"). Se centra en tecnologías Microsoft, claro está, para ofrecer posibles soluciones y ejemplos.

De momento, tenemos dos: para prevenir problemas de XSS, y para prevenir problemas de inyección SQL. Me ha gustado el enfoque :)

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

viernes, 22 de enero de 2010

Las 10 mejores técnicas de hacking web 2009


Jeremiah Grossman publica, desde 2006, un listado con las mejores técnicas de hacking en aplicaciones y servicios web que han aparecido el año anterior. Acaba de presentar la de este año: Top Ten web hacking techniques of 2009 (Official), elegida por algunos de los mejores expertos en seguridad (web) que podemos encontrar a escala internacional: el propio Jeremiah, Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Steven Christey, Jeff Forristal, Michal Zalewski, y Romain Gaucher.

La producción o innovación de nuevas técnicas en el año pasado ha sido bastante elevada, con un registro de hasta 82 nuevos ataques presentados en foros, conferencias, revistas, blogs, etc, con lo que lo han tenido difícil para elegir. Se puede consultar el top ten en el blog del propio Jeremiah.

Yo, personalmente, me quedo con estas, no por seguir orden particular, temática concreta, o hacer mi propio top ten, sino sencillamente porque me llaman la atención (advierto que no he podido leer detenidamente más que unos cuántos ataques de la lista de Jeremiah):

Slds!


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 11 de enero de 2010

domingo, 3 de enero de 2010

WASC Classification v2


Acaba de salir la versión 2 del diccionario de amenazas web de WASC, una clasificación de los distintos tipos de vulnerabilidades web que podemos encontrar, clasificadas según los ataques que se realizan, y las debilidades que permiten que estos ataques funcionen. La lista ha quedado de la siguiente manera:

Attacks Weaknesses
Abuse of Functionality Application Misconfiguration
Brute Force Directory Indexing
Buffer Overflow Improper Filesystem Permissions
Content Spoofing Improper Input Handling
Credential/Session Prediction

Improper Output Handling

Cross-Site Scripting Information Leakage
Cross-Site Request Forgery

Insecure Indexing

Denial of Service Insufficient Anti-automation
Fingerprinting Insufficient Authentication
Format String Insufficient Authorization
HTTP Response Smuggling Insufficient Password Recovery
HTTP Response Splitting Insufficient Process Validation
HTTP Request Smuggling Insufficient Session Expiration
HTTP Request Splitting Insufficient Transport Layer Protection
Integer Overflows Server Misconfiguration
LDAP Injection
Mail Command Injection
Null Byte Injection
OS Commanding

Path Traversal
Predictable Resource Location
Remote File Inclusion (RFI)
Routing Detour
Session Fixation
SOAP Array Abuse
SSI Injection
SQL Injection
URL Redirector Abuse
XPath Injection
XML Attribute Blowup
XML External Entities
XML Entity Expansion
XML Injection
XQuery Injection

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 24 de diciembre de 2009

Seguridad web por ley?


Hace unos días se celebraban las conferencias IBWAS'09, las primeras conferencias conjuntas de OWASP Spain y OWASP Portugal. La última de las mesas-coloquio, al parecer (no estuve, por desgracia), trató sobre lo que deberían hacer los gobiernos en el 2010 para mejorar la seguridad en aplicaciones de web. Se emitió este comunicado, del que me gustaría hacerme eco. (Lo cuenta mejor SecurityByDefault en Seguridad en aplicaciones web y gobiernos).

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 17 de diciembre de 2009

apuntes de CSRF


Veo hoy un par de blogs que hablan de CSRF, recordemos, una de las categorías de ataques listadas en Owasp Top Ten por lo menos seis años.

En CSRF isn't just for access, mckt nos explica cómo aprovechar un CSRF para realizar ataques de denegación de servicio distribuida, de múltiples maneras. Y en Cross-Site Request Forgery For POST Requests With An XML Body, el problema de ejecutar un CSRF en una petición SOAP o XMLRPC.

Muy claros e instructivos :)

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 29 de octubre de 2009

la ola de google


Todos llevamos algún tiempo oyendo hablar de Google Wave, la última innovación de Google para darnos a todos más capacidad de comunicación y de subir contenido a la red. De momento, está en fase beta y sólo accesible con invitación, pero ya ha dado mucho de qué hablar (aquí dos enlaces: alt1040 y El País).

Como es de ley, ya se le ha empezado a sacar problemas de seguridad. En TheHarmonyGuy nos cuentan que su autor ha probado Beef en Google Wave, con éxito, lo que podría convertirlo en una buena herramienta para hax0rs.

Slds

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 19 de octubre de 2009

Estadísticas de WASC


Hace unos días WASC publicaba los resultados de la nueva edición de su proyecto Web Application Security Statistics. Este proyecto tiene como objetivos identificar las vulnerabilidades web más comunes en aplicaciones realizadas a medida, así como comparar cuál es el mejor método para detectarlas (pruebas automáticas, pruebas de caja negra, o pruebas de caja blanca).

Se basa en la información recopilada en auditorías de seguridad y tests de intrusión realizados por un conjunto de empresas, listadas en los resultados del informe, y que comprenden un total de 12186 aplicaciones revisadas con un total de 97554 vulnerabilidades descubiertas en ellas. Sus resultados son los siguientes:
  • El 13% de los sitios web analizados puede ser comprometido de forma automática
  • El 49% de los sitios web analizados contienen vulnerabilidades de carácter grave o crítico que pueden ser detectadas mediante pruebas automáticas, aumentando esta cifra al 80% cuando se realizan pruebas exhaustivas (pruebas automáticas y manuales con conocimiento previo del aplicativo, revisión de código, etc).
  • Los problemas más extendidos son XSS, revelado de información, inyección SQL y HTTP Response Splitting.
  • Es un 20% más probable que un agujero de seguridad sea debido a un problema de administración del sitio web, que a un fallo introducido por un diseño o codificación inadecuados
  • El 99% de las aplicaciones no cumplen con los requisitos de PCI-DSS para aplicaciones de web
  • Las pruebas de caja blanca permiten detectar hasta 91 vulnerabilidades por aplicación de web, y sólo podrían detectarse 3 mediante pruebas automáticas sin ningún tipo de conocimiento previo acerca del aplicativo.
Según nos cuentan, comparando estos resultados con los de 2007, el número de sitios con problemas de XSS y de inyección SQL ha caído un 13% y un 20% respectivamente, aumentando el número de sitios que revelaban información confidencial un 24%. Además, la probabilidad de comprometer un sitio web de forma automatizada ha pasado del 7% al 13%.

Tener estas estadísticas a mano siempre es muy útil, hay que felicitar a quien hace estas estadísticas por su esfuerzo. Permiten saber, por ejemplo, como de buenas son las herramientas utilizadas para hacer los análisis automáticos (son todas comerciales, por supuesto), ya sea con conocimiento previo del aplicativo o sin él. Sin embargo, a mí me gustaría que se detallara un poco el tipo de aplicativo analizado, porque creo que es también relevante saber qué se encuentra dónde. O con qué tecnología están desarrollados (PHP, Java, .Net, Colfusion…).

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 8 de octubre de 2009

El desarrollador educa también al usuario


Seguramente es una de las noticias más comentadas de los últimos días: el leak masivo de contraseñas de usuarios de correo electrónico. Primero fue Hotmail, advirtiendo Microsoft que la causa no tiene que ver con infiltraciones en sus sistemas, sino con un phishing de tomo y lomo. Después, se ha confirmado que Gmail, Yahoo o AOL han tenido el mismo problema (dos enlaces).

Este ataque de phishing, además de exponer el poco sentido común que tiene la mayoría de los mortales en Internet, también saca (como ya sabíamos) el poco cuidado que tiene la gente con sus contraseñas en todos los sitios de Internet, como puede verse en el análisis de las passwords encontradas realizado por Bogdan Calin en el blog de Acunetix, que deja claro que las contraseñas más utilizadas son bien sencillas: 123456, por poner un ejemplo.

Por ello, expertos de renombre mundial, nos vuelven a recordar que las contraseñas utilizadas por los usuarios no pueden ser demasiado complejas, porque si hay que poner una diferente en cada sitio (como medida de seguridad), pues van a acabar olvidando, así que podría ser mejor tener passwords complejas para los sitios más importantes, llevando las más necesarias escritas en un papel en la cartera.

A mí, que soy un pelo desconfiado para estas cosas, no me parece muy buena idea, la verdad, y prefiero aplicaciones como Keepass para guardar mis passwords y además cambiarlas periódicamente. Llevarlas en papel en la cartera me parece igual que llevar el número PIN de tu tarjeta de crédito en el mismo sitio.

Por otra parte, no creo que la solución pase únicamente por protestar continuamente de la poca educación en seguridad informática que tiene el usuario, e intentar educarlo, sino también en obligarle a que se eduque a sí mismo cuando utilice las aplicaciones web que desarrollamos. Así, si ve en todas las aplicaciones que utiliza que se le indica la fortaleza de su contraseña, quizás se pregunte por qué. Y si se le obliga a que tenga un nivel mínimo, pues más todavía. Cada desarrollador puede aportar su granito de arena, aportando a su aplicación todas las medidas de seguridad que pueda en tema de passwords, ya no sólo en beneficio de la seguridad de su desarrollo, sino en beneficio del usuario. En definitiva: enseñar con el ejemplo.


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 24 de septiembre de 2009

Mejorando frameworks de desarrollo


Me gustó hace unos meses este paper: A gap analysis of application security in struts2, desarrollado por el Owasp Intrinic Security Working Group . En él nos contaban cómo el framework Struts2 puede ser utilizado para implementar determinados aspectos de seguridad, como puede ser la validación de entrada, y cómo este framework puede ser mejorado agregándole algunos aspectos que sí están en Owasp ESAPI. (Posteé sobre esto en seguridad en struts).

Como uno no deja de descubrir cosas nuevas, acabo de descubrir gracias a la entrevista a Andrés Riancho en elladodelmal sobre HDIV (HTTP Data Integrity Validator, un proyecto cuyo objetivo es ampliar frameworks de desarrollo como Struts2 o Spring MVC y dotarles de características de seguridad de las que no dispongan. En particular, tiene como misión dar mecanismos para proporcionar:
  • Integridad de todos los datos generados por el servidor y que no deben ser modificados en el lado cliente (enlaces, campos ocultos, etc)
  • Validación de los datos de entrada: para aquellos datos que sean editables por el usuario (campos de texto), se establecen controles de validación genéricos
  • Confidencialidad: garantizar la confidencialidad de datos no editables, pues pueden representar información a proteger: nombres de tablas de BBDD, directorios web, nombres de máquinas de la red interna de la empresa, y un largo etcétera
  • Token anti-csrf: en cada formulario y enlace se puede poner un token generado aleatoriamente, como medida de protección adicional contra problemas de CSRF.
entre otras cosas de interés. Merece la pena echarle un vistazo al manual para informarse.

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

martes, 8 de septiembre de 2009

Para saber si el navegador del usuario está virtualizado


Aquí va una entrada, a modo de apunte rápido, sobre cómo emplear los recursos del navegador para detectar si un usuario está navegando o no desde un entorno virtualizado. Jeremiah Grossman escribía sobre esto hace unas semanas.

J.G nos sugiere dos trucos para detectar entornos virtualizados: ver el tamaño de la ventana del navegador mediante Javascript, y ver la dirección MAC del equipo. El tamaño de la ventana puede obtenerse mediante Javascript, y al parecer, en el caso de entornos virtualizados suelen obtenerse tamaños un tanto extraños. La dirección MAC del equipo no puede obtenerse mediante Javascript, pero sí mediante un applet Java, y ocurre que los primeros octetos de la dirección MAC son fijos, e identifican al fabricante (por ejemplo VMWare).

Además de saberse si un navegador se encuentra virtualizado, también es posible saber por ejemplo si está usando el modo “privado” del navegador (“InPrivate” de IE8, “Private Browsing” de Firefox, o “Incognito” en Chrome). Un usuario empleará este modo en el caso de que se encuentre usando un equipo público, por ejemplo un PC de un cibercafé. Le permite controlar la información que se guarda en el histórico del navegador, cookies, etc. Una última utilidad interesante podría ser conocer si el usuario está usando plugins de seguridad como Noscript.

La conocida herramienta “beef”, que permite explotar vulnerabilidades en los navegadores, incorpora un módulo para detectar si el navegador Internet Explorer está o no virtualizado, mirando la dirección MAC mediante Javascript.

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

miércoles, 29 de julio de 2009

Dos utilidades básicas


Siempre tenemos muchas noticias sobre herramientas de seguridad de mil clases y tipos, y es imposible (además de poco innovador) hacer un post cada vez que sale una, salvo que sea novedosa o particularmente relevante. Hoy toca un pequeño post por darse el segundo caso, pues ha habido novedades en dos imprescindibles: Nmap y SQLMap. Ambas forman parte de la caja de herramientas imprescindibles de todo aquél que se dedique a tests de intrusión.

Nmap, por excelencia una de las herramientas imprescindibles para el análisis de red y servicios, ha incluido numerosas mejoras (aunque como nos dicen en SecurityByDefault, de muchas cosas ya disfrutábamos desde versiones anteriores), entre las que se incluyen: motor mejorado, libro sobre la herramienta (parte de él está gratis en Internet, si lo quieres entero hay que comprarlo), la herramienta Ncat para hacer las funciones de la ya antigua netcat, y NDiff para poder comparar dos escaneos y ver las diferencias (útil para administradores de sistemas y departamentos de seguridad, que han de hacer una vigilancia continuada). Además, y aunque no sean exclusivas de esta versión, hay dos mejoras que me gustan mucho: el interfaz gráfico mejorado Zenmap, y los scripts NSE, que incluyen muchísimas utilidades.

SQLMap es imprescindible en la realización de test de intrusión sobre aplicaciones web, para explotar vulnerabilidades de inyección SQL, razón por la que la suite w3af la utiliza. Hace unos días se publicó la versión 0.7 (publicitada vía mensajes a diversas listas de correo, entre otros medios), y por lo que veo en el Changelog, los últimos cambios son para dar estabilidad a la herramienta, e incluir numerosas mejoras que permiten aprovechar mejor la integración con metasploit, entre otras cosas. Su autor, B.Damele, es un crack en esto del hacking web y en particular de la inyección SQL, como muestra, se puede ver su material sobre el tema.

¡Que aprovechen!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 13 de julio de 2009

Owasp Testing en español


Un post rápido para decir que acaba de ser publicada la traducción al castellano de la guía de pruebas web Owasp, versión 3 (Owasp Testing Project). Con el tiempo, esta guía se ha conformado como el estándar de facto a seguir para la realización de test de intrusión sobre aplicaciones de web, por lo que su disponibilidad en español es sin duda una buena noticia.

Kudos para el grupo de Owasp Spanish, que se encarga de la traducción al español de las guías de Owasp.

Slds!


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 8 de junio de 2009

Seguridad en Struts


¡Buenas a todos!. Como prometí hace ya bastantes días voy a tomar de nuevo algo más de actividad en "Informático y Segurata", que he tenido algo abandonado en los últimos tiempos. El trabajo y algunas otras cosillas no me dejan mucho tiempo para trastear y escribir en el blog, aunque espero que la cosa cambie.

Últimamente ha salido bastante material interesante sobre desarrollo seguro en el sitio web de OWASP. Hace ya un par de semanas se celebraron las conferencias Appsec Europe Conference y hay muchísimas cosas fresquitas para ir leyendo y mirando sobre desarrollo seguro. Pero no es esto lo que quería destacar, sino un trabajo de un grupo menos conocido, el Intrinsic Security Working Group, que ha realizado un estudio sobre los mecanismos de seguridad disponibles en Struts 2, y cómo ampliarlos.

Es una práctica habitual recomendar, como opción predeterminada, el uso de los mecanismos de seguridad que ofrezca el framework sobre el que se desarrolla una aplicación. Es una cuestión de sentido común: mejor no reinventar la rueda. Sin embargo, conviene estudiar cuáles son estos mecanismos, pues es posible que no sean completos. Este estudio compara Struts 2 con OWASP ESAPI, en cuestiones como autenticación centralizada, validación de entrada o defensa contra XSS (por poner tres ejemplos). Altamente recomendable :)

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 5 de marzo de 2009

Más de SSLStrip


Hace unos días hacían una pequeña entrevista al Sr. del SSLStrip. Está en Youtube, aquí la dejo también:




Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...