en el blog de ModSecurity me encuentro con el siguiente post. No tiene desperdicio y la verdad es que es 100% verídico. No hay que dejarse guiar por las apariencias y extremar precauciones en lo que a seguridad informática se refiere. Traduzco:

Así que, ¿tu página web es segura? Pruébalo.

1. Sí, lo es.

Entonces, se oyen grillos (silencio para los colegas poco imaginativos). Esto es completamente inaceptable. El fallo está en proporcionar seguridad con palabras. Queremos seguridad, pero con hechos. Piénsalo de esta forma: ¿un auditor se conformaría con esa respuesta? ¿Podrías pasar una auditoría PCI con responder sí?. No verdad, entonces necesitas demostrarlo con hechos.

2. Sí lo es. Tenemos el producto X, Y, Z, etc.

Esto es mejor, pero es otra de las expresiones que se basan en las palabras y no en los hechos. El único hecho es que la tecnología puede ser manipulada, invertida y comprometida. Puede ser efectiva contra un modelo de ataque y complétamente débil contra otro.

Esto me recuerda a una respuesta que suelen dar mucho: “Sí, porque usamos un certificado SSL“. Ugh… déjame contarte algo sobre los certificados SSL que pude sufrir con una de estas webs. Hace tiempo decidí hacer una compra online de unas hierbas que pueden calentarse en el microondas, para los músculos. Cuando visité la página web del fabricante fuí sorprendido con un mensaje que decía: ¡Somos un sitio web seguro! Usamos un SSL de 128 bits. Esto demostraba que mi número de tarjeta de crédito no se enviaría en texto plano. Durante el proceso de compra, decidí verificad la información del certificado SSL. Hice doble click sobre el candado que aparece en la parte inferior derecha y verifiqué si el dominio al que pertenecía el certificado SSL era el correcto y coincidía con la dirección que estaba visitando el cual estaba firmado por una empresa de renombre como Verisign y que, finalmente, el certificado era válido. Todo parecía estar en orden así que procedí con la compra e introducí los datos de mi tarjeta de crédito. Pulsé el botón de comprar y me mostró un mensaje que hizo que mi estómago diera un vuelco. El mensaje viene a continuación, de cualquier forma, he modificado la información para protegerme a mí y a mi banco:

To:companyname@aol.com
From: RCBarnett@email.com
Subject:ONLINE HERBPACK!!!
name: Ryan Barnett
address: 1234 Someplace Ct.
city: Someplace
state: State
zip: 12345
phone#:
Type of card: American Express
name on card: Ryan Barnett
card number: 123456789012345
expiration date: 11/05
number of basics:
Number of eyepillows:
Number of neckrings: 1
number of belted: 1
number of jumbo packs:
number of foot warmers: 1
number of knee wraps:
number of wrist wraps:
number of keyboard packs:
number of shoulder wrap-s:
number of cool downz:
number of hats-black:         number of hats-gray:
number of hats-navy:         number of hats-red:
number of hats-rtcamo:         number of hats-orange:
do you want it shipped to a friend:
name:
their address:
their city:
their state:
their zip:

cgiemail 1.6

No podía creerlo. Tal y como pensaba han enviado mis datos bancarios en texto plano a una cuenta de correo de AOL. ¿Cómo es posible? Fueron lo intelitgentes como para que la información del usuario fuera enviada con SSL de 128 bits a la página web, ¿por qué no hicieron lo mismo con el proceso de envío de la información? Debe haber un error. En el correo se podía ver un mensaje que indicaba que la aplicación usada para el pedido era CGIMAIL 1.6. Al instante me puse a buscar información en Google. Encontré un enlace para webmasters acerca de CGIMAIL. Rápidamente revisé el contenido y encontré lo que estaba buscando: ¿qué consejos acerca de la seguridad de CGIMAIL existen?:

Intercepción de los datos enviados por un navegador al servidor y viceversa.

Riesgo: con CGIMAIL al igual que en muchos programas de envío de correos a través de formulario se puede esnifar en cualquier punto entre el servidor web y el usuario. Como no hay encriptación, no es recomendable usarlo para información confidencial o números de tarjetas de crédito.

Bingo, tal y como sospechaba. Gasté el resto del día intentando contactar con mi banco acerca de la posibilidad de que hubieran comprometido la información de mi tarjeta de crédito y para echarle un ojo a mi cuenta. También contacté con la compañía enviando un correo electrónico a la misma dirección de AOL haciendo incapié en la falta de seguridad que tenían en su proceso de compra. Resumiendo: usar SSL no es sinónimo de seguridad.

3. Sí, tenemos certificación PCI.

Generalmente hablando, son como requerimentos que se prueban con una lista de pruebas escritas en papel los cuales controlan ataques. PCI es la excepción e intenta ser más relevante en lo que a problemas de seguridad en una web se refiere. Aunque hay ciertos aspectos buenos de PCI, por favor ten esto presente siempre:

Es mucho más fácil aprobar una auditoría PCI si eres seguro que ser seguro porque tienes que pasar una auditoría PCI.

PCI, como otras muchas, es un estándar mínimo de cuidado y pasar el test hace tu sitio “unhackeable”. Para una empresa sería como meterse en en océano con unos chalecos y botes salvavidas, saliendo seco previamente del puerto. Si el cumplimiento de estas reglas y premisas va más allá de un papel escrito, nos vamos acercando a la verdadera evidencia. De todas formas, no he visto ninguno de estos con evidencia real. Revisa el post de Richard en su blog en cumplimiento de controles de seguridad para más detalle acerca de esto y qué está mal. Lo que realmente necesitamos es más “evaluacion de campo”. Hablaré acerca de esto en posts posteriores en mi blog.

4. Sí, tenemos logs indicando que hemos evitado ataques web X, Y y Z (SQL Injection, XSS, etc).

Esto se va acercando a la respuesta correcta, pero aún no es la respuesta adecuada. Por primera vez tenemos evidencia (logs) pero éstos probablemente no tienen el “retrato” correcto. Creo que la forma en que la gente monta y usa un WAF es incorrecta. La mayoría de la gente monta un WAF centrándose en dar alertas que sólamente proporciona logs cuando coincide una de nuestras reglas. Claro, esos WAF detectan y paran un ataque potencialmente peligroso pero, ¿qué hay de lo que hizo en todo el proceso? ¿Fueron ataques normales o hubo algún que otro potencialmente perligroso y no reconocido por el mecanismo de prevención? Montar un WAF a nivel HTTP es una opción muy buena raramente usada. Existe una antigua cita que recoge este concepto:

“En un incidente, si no tienes buenos logs (p.e auditar) deberás tener buena suerte.”

5. Sí, no tenemos ninguna indicación de que nuestras aplicaciones web estén respondiendo a los patrones de los ataques.

Alguien podría llamar a esto racionalmente el concepto de seguridad. El que esta pregunta sea aceptable o no depende de la naturaleza de las indicaciones. Si no tienes ningún indicio porque no estás monitoreando nada, entonces la escusa es absurda. Si no tienes ningún indicio y auditas el estado de una aplicación web, entonces estamos avanzando. Esto lidera parte de la respuesta siguiente, que se acerca mucho a la pregunta ideal.

6. Sí, no tenemos ningún indicio de que nuestra aplicación esté interactuando con el exterior respondiendo a patrones y estamos tomando, analizando y escalando redes, hosts y ataques a aplicaciones web y violaciones de éstas.

Estamos muy muy cerca de la respuesta correcta. La ausencia de evidencia de intrusión es significativa si estás seguro de que estás correctamente instrumentado y conoces a fondo la aplicación web. Debes monitorear concienzudamente el servidor para que la aplicación web sea “segura”. La falta de una fuerte auditoría de los logs es la razón más común por la que las empresas no pueden contestar de esta forma. Velo de la siguiente forma: Common Log Format (CLF) no so adecuados para una respuesta rápida y adecuada ante un incidente. Falta mucha información. Si esta respuesta está muy cerca de la correcta, ¿por qué no lo es?

7. Sí, no tenemos ningún indicio de que nuestra aplicación esté interactuando con el exterior respondiendo a patrones y guardamos, analizamos y escalamos una variedad de host, redes y evidencia basada en aplicaciones web de intrusiones. Habitualmente testeamos nuestra detección y equipo de repuesta, procesos y utilidades haciendo simulacros que coinciden o exceden las capacidades e intenciones de las amenazas que tenga nuestra empresa.

Aquí puedes ver por qué la respuesta seis era insuficiente. Si crees que la respuesta 6 es suficiente, olvidaste que tus van más allá que detectar y reportar las intrusiones. Periódicamente debes probar la efectividad de tu defensa con ejercicios neutrales. La respuesta final es una suma de las demás y de que conoces la aplicación que estás intentando asegurar. Piensa sobre este ejercicio, si realizas un ataque sin que los del equipo de respuesta lo sepa, ¿cómo responde tu empresa? ¿Se han dado cuenta de la prueba que hiciste ellos solos? ¿Escalaron el problema de forma correcta? ¿Cuánto tardaron después de adoptar las medidas oportunas? Si no tienes respuestas para este tipo de ataques en directo, seguramente no sabrás cuán efectiva es tu defensa.

Conclusión.

Indirectamente, este post tambin explica por qué sólo: escaneo de vulnerabilidades web, pruebas de penetración, montaje de un firewall para la aplicación web y análisis de logs no es suficiente para una buena “seguridad”. Mientras cada uno de estos puntos ayuda a la seguridad de un sitio web, son inefectivas en otras. Es el conjunto de todos esos esfuerzos lo que hace que algunas organizaciones tengan un sitio web “que se defiende”, como Richard dice.

Posteado por rcbarnett at January 30, 2008 12:45 PM y traducido por Jacob F.P

Fuente: ModSecurity Blog.