Su Cerebro Sobre Google

Los motores de búsqueda como Google y IMDb pueden hacer papilla su memoria. Eso es lo que el  psicólogo Betsy Sparrow de la Universidad de Columbia dijo del uso de tales sitios. "Desde el advenimiento de los motores de búsqueda, estamos reorganizando la forma en que recordamos las cosas", dijo Sparrow. "Nuestro cerebro dependen de Internet para la memoria de la misma manera en que se puede confiar en la memoria de un amigo, familiar o compañero de trabajo.  Recordamos menos la información misma al saber dónde la podemos encontrar."  De Columbia's Research magazine: La investigación de Sparrow revela que nos olvidamos de las cosas que estamos seguros de que podemos encontrar en Internet. Somos más propensos a recordar lo que se cree que no está disponible en línea. Y somos más capaces de recordar dónde encontrar algo en Internet que recordar la información en sí.

Tomado de: http://www.infoworld.com/t/technology-business/20-the-weirdest-wackiest-and-stupidest-tech-stories-2011-so-far-167607-0

Error del desarrollador: Los errores de programación más peligrosos

Ningún lenguaje o plataforma garantizan la seguridad de las aplicaciones mientras que 

los desarrolladores repitan las mismas viejas equivocaciones. 

 
By Neil McAllister
Traducido by Andrea Lozada
A los programadores a menudo les gusta hablar de cómo una nueva herramienta o una nueva version de sus plataformas favoritas harán el código más rápido, fácil o elegante. Aunque esto puede ser cierto, se ignora cuán difícil y cuidadoso es actualmente el proceso de desarrolo de software de calidad.

Caso en cuestión: la  lista de CWE/SANS de los 25 errores de sofware más peligrosos. Cada año, los editores de la lista aprovechan la experiencia de los principales expertos en software de seguridad para clasificar los errores de programación por frecuencia, gravedad y la probabilidad en que estos conducirán a vulnerabilidades explotables. Este año la lista fue publicada esta semana, y las malas nociticias son unas pocas sorpresas que contiene.

[Reciba las noticias de desarrollo de software y conocimientos desde  InfoWorld's Developer World newsletter. | Y agudice sus habilidades de Java con JavaWorld Enterprise Java newsletter.]

 
La lista de este año no sólo es predecible, es redundante. De los 25 errores citados, demasiados pueden ser atribuidos a los mismas fundamentales equivocaciones-- errores que han existido casi desde los albores de la programación. ¿Nunca vamos a aprender?

Los mismos errores una y otra vez
 

Encabezando la lista está la "inadecuada neutralización de elementos especiales usados en un comando SQL," también conocida como la temida vulnerabilidad de inyección SQL, la pesadilla de las aplicaciones Web en todas partes. Según el anual de IBM X-Force Trend y Risk Report, la frecuencia de los ataques de inyección SQL aumentó 200 veces entre 2008 y 2009, y los investigadores de IBM han visto por lo menos un ataque de inyección SQL en "escala global" cada verano durante los últimos tres años.

Inyección SQL es usualmente el resultado de una indebida validación de la entrada de un usuario, donde la aplicación analiza la forma de los datos en una consulta SQL sin comprobar si contiene código SQL potencialmente dañiño. Pero la inyección SQL no es la única manera en la que la entrada del usuario puede salir mal. De la lista de los 25 principales errores, mas o menos una cuarta parte de ellas pueden ser atribuidos a la inadecuada validación de entrada, incluyendo la inyección de comandos del sistema operativo, desbordamientos de búfer, cross-site scripting, falta de validación de rutas del directorio e incontroladas salidas de cadenas de formato.

Incluso más que los errores de validación de entrada, este año la lista de los 25 principales está plagada de errores de seguridad de aplicaciones de todo  tipo. Algunos de ellos suena esotericas, como "inclusion de funcionalidad de la no confiable esfera de control",  pero de todos estos errores,el de más alto rango en la lista es "falta de autenticación de función critica" -- en otras palabras, el atacante puede tener acceso porque no había ninguna cerradura en la puerta para empezar.

Que podes aprender de nuestros errores

Los desarrolladores cometen este tipo de errores por dos razones principales. En primer lugar, pueden estar operando bajo la errónea suposición  de que una determinada función es demasiado oscura para ser vulnerable; ellos no alcanzan a comprender el grado en que los atacantes pueden estar dispuestos a analizar el flujo de sus aplicaciones para encontrar debilidades. Más a menudo, sin embargo, simplemente no tienen consideración de como una importante función puede ser la seguiridad de su aplicación. Como las aplicaciones se vuelven más complciadas y sus funciones se distribuyen a través de múltiples sistemas y recursos, es particularmente fácil perder la pista de una idea grande de seguridad.

La lista completa CWE/SANS es detallada y completa, de facil lectura y lleno de asesoramiento específico y valios. Si usted maneja un proyecto de desarrollo de software, estaría bien pasar el enlace por todos los de su equipo y animarles a estudiarlo a fondo. Incluso una lectura superficial, sin embargo, abre paso a ideas de rendimiento que todo desarrollador debe tener en cuenta.

Primero, conocer sus herramientas y no aceptar sus características ciegamente. Entre las recomendaciones específicas dadas en la lista de CWE/SANS son joyas como " Si usted esta usando PHP, configurar la aplicación para que no se utilicen registros globales". Este consjo en particular es tan viejo como las montañas, y en reallidad ha sido la configuración por defecto a partir de PHP 4.2. A partir de PHP 5.3 la característica en cuetión ha qeudado en desuso. Los desarrolladores que persisten en usar las características de las plataformas de riesgo porque están ahí, a pesar de incontables recomendaciones, al contrario, merecen lo que reciben.

Segundo, no ponga demasiada fe en su plataforma solo porque dice que es más seguro. POr ejemplo, manejar lenguajes como Java y C# elimina la posibilidad de desbordamientos de búfer, haciendo los límites de comprobación en tiempo de ejecución. Esto significa que los programadores de java y C# son protegidos del tercer error en la lista de CWE/SANS . Pero ni Java ni C# hace nada para protegerse de las vulnerabilidades de la inyección SQL causads por la pobreza de validación de la entrada de un usuario, las cuales ocupan un lugar aún más alto en la lista de desbordamiento de bufer.  Cualquier plataforma  es tan segura como el código que se ejecuta en él.

En tercer lugar, los datos de seguridad es difícil. A menos que seas un especialista, la criptografía parece un arte arcano, y es tentador para tratarlo simplemente como polvo mágico que se puede espolvorear en sus aplicaciones para hacerlas más seguras. Del mismo modo, es muy fácil introducir puertas traseras en el esquema de autenticación si usted no trata la seguridad como un principio fundamental en el proceso de diseño de software. La aplicación incorrecta, inconsistente o ingenua de las técnicas de seguridad es especialmente insidiosa, ya que crea una falsa sensación de seguridad, incluso, ya que conduce a graves vulnerabilidades.

Por último, y lo más importante, la lista nos recuerda que  las vulnerabilidades de software están en todas partes, y prácticamente ningún proyecto de desarrollo es completamente seguro. Con el ritmo  acelerado de los ataques de Internet, ahora no es el momento de reducir  el personal de control de calidad o  escatimar en las pruebas y la revisión del código. Sin importar las herramientas que usted elija, el desarrollo de aplicaciones seguras es un retador y laborioso, pero muy importante, ahora más que nunca. Tengamos cuidado ahí fuera.

Este artículo, "Developer error: The most dangerous programming mistakes," originalmente apereció en InfoWorld.com. Lea más en Neil McAllister's Fatal Exception blog y siga las últimas noticias de programación en InfoWorld.com. Para las últimas noticias de las tecnologías de negocio, seguir InfoWorld.com enTwitter.