Y no solo IE, sino Firefox, Chrome, Safari y Opera. He encontrado un manual en internet que debe resolver todas tus dudas sobre como hacer tu experiencia de navegación en Internet mas segura.

Probablemente este manual va mas enfocado hacia aquellos que no son programadores, o usuarios expertos de computadoras, sin embargo siempre es util tener un manual de referencia. En el se incluye una reseña sobre los procesos de seguridad en general, seguido de como aplicarlo sobre los navegadores mas usados.

Es un PDF y lo puedes ver dando clic aquí.

Así es, el día de ayer miércoles, ha sido liberada la versión de Visual Studio 2010 Beta, está muy pero muy cool

Ahora mismo lo estoy probando, y me ha encantado, con lo que me gusta WPF, les recomiendo que lo prueben !

Link: Descarga Visual Studio 2010

Héctor Uriel Pérez Rojas

Hay muchas soluciones excelentes para sistemas de control de revisiones. SourceSafe no es una de ellas.

Después de haber usado SourceSafe durante años, he tenido experiencia mala tras experiencia mala. Nuevas versiones no trajeron mejoras considerables. Espero con este artículo persuadirte que no uses SourceSafe, librándote de los problemas que puede causarte.

Características que Faltan

SourceSafe no tiene soporte para revisiones alternas o de prueba (branching)

Un sistema de control de revisiones debe proveer soporte para branching (revisiones alternas). Con un sistema adecuado de branching los desarrolladores pueden hacer revisiones menores de versiones anteriores o actuales mientras se sigue el desarrollo con la version principal para una nueva versión. Permite probar actualizaciones a nivel proyecto sin afectar la versión funcional.

De igual manera debe tener un sistema de diferenciación entre “branches” o versiones para poder modificarlos, unirlos, o deshacer cambios. El “merge” de SourceSafe está integrado ampliamente con el check-in, haciendo que sea dificil validar las diferencias de una propuesta de merge antes de mandarlo a check-in.

No se puede extender a SourceSafe de manera segura

Debería ser posible añadirle funcionalidades al sistema de control de revisiones. Por ejemplo, envío de correos haciendo un resumen de check-ins es muy importante. Al trabajar con un equipo, emails con mensajes listando archivos actualizados así como las actividades realizadas en cada uno pueden mantener a todo el equipo al tanto de las actualizaciones. Quizá también se requiera agregar filtros para prevenir que se actualizen archivos que no cumplen con ciertos requerimientos. Sourcesafe apenas soporta algo remotamente parecido. Aún cuando es posible, cada usuario debe tener la funcionalidad instalada a nivel cliente. Si uno solo no lo tiene, el sistema deja de funcionar de la manera esperada.

SourceSafe silenciosamente deja archivos muertos en tu sistema

Cuando se actualizan los archivos de trabajo locales al servidor, los archivos que fueron eliminados en el servidor deberían ser mostrados, o eliminados, ya que de cualquier modo los archivos se podrían restaurar del sistema de control de versiones. No hacer esto causa que archivos viejos o no requeridos se queden colgados del lado de un cliente, integrandose nuevamente al hacer check-in.

SourceSafe no funciona adecuadamente sobre redes lentas y por medio de Internet

Se vuelve casi inusable sobre redes/conexiones lentas. Como SourceSafe funciona compartiendo sobre la red, si publicas un servidor de SourceSafe en la red se expone cualquier debilidad en la implementación del compartido de archivos que pueda tener el servidor.

Se vuelve extremadamente lento ver y regresar a versiones anteriores

No es extraño llegar a necesitar una version histórica del código fuente. Puedes necesitar una version anterior para verificar un reporte de un bug, o regresar a una versión funcional. SourceSafe soporta esta funcion, sin embargo es bastante lento para proyectos grandes. Para obtener una version histórica requieres generar el historial para todo el proyecto, y luego especificar la versión seleccionando el último check-in que requieres. Para un proyecto con cientos de archivos y un año de historia puede tomar mas de 5 minutos.

Es dificil mantener copias multiples de manera local de un mismo proyecto

Al hacer cambios de manera masiva sobre un proyecto puede ser que se requiera hacer un cambio sobre la solución entera. La manera mas eficiente de hacer esto es generar un duplicado para hacer el cambio. SourceSafe presenta un problema al hacer esto. SourceSafe solo reconoce una versión válida en tu sistema. Tendrás que hacer una copia del directorio físico, hacer el cambio, y darle la noción a SourceSafe de la ubicación de la copia.

Seguridad

SourceSafe se vuelve lento y problemático con proyectos grandes

Microsoft recomienda que tu base de datos de SourceSafe no exceda 5 GB en tamaño. (Fuente: Mejores Prácticas de Microsoft). Aunque 5GB es una base de datos bastante grande, es comun para un proyecto grande, especialmente cuando subes archivos binarios como documentos de word, etc.

Integración de SourceSafe con Visual Studio puede causar inestabilidad

SourceSafe puede colgarse o tronar cuando tu sistema pierde conexión con la base de datos SourceSafe. Mientras que esto puede ser irritante al usar Visual SourceSafe de manera directa, se vuelve insoportable al usar Visual Studio con integración con SourceSafe ya que puede hacerte perder trabajo.

SourceSafe depende de transferencia de archivos de manera peligrosa

SourceSafe no corre realmente como un servidor si no que como un set de archivos compartidos a través de SMB. Como resultado dependes en que cada cliente no debe de comportarse de manera errática. Una sola computadora que falle de hacer lo que debe puede corromper la base de datos. Un solo problema con el sistema para compartir archivos en tu computadora puede destrozar la base de datos.

Se debe escanear a SourceSafe para detectar corrupción semanalmente

Claro, con este riesgo grande de corrupción, Microsoft recomienda que corras el programa de diagnostico “Analyze” de manera semanal. (Fuente: Microsoft Best Practices). Mientras que Analyze está corriendo, todos los desarrolladores quedan encerrados fuera del sistema.

SourceSafe maneja zonas horarias multiples de manera inadecuada

Si tienes equipos usando el mismo repositorio SourceSafe en diferentes zonas horarias es muy probable que tengas problemas. (Ve el reporte de Microsoft sobre el bug de zona horaria). La unica solución que propone Microsoft es ajustar la hora de la computadora entre zonas a una misma hora, o comprar un producto de un tercero.

SourceSafe se corrompe

Tu sistema de control de revisiones debe ser digno de confianza. Estas poniendo tu trabajo en las manos de un sistema. Si los datos se corrompen el sistema es infuncional. El diseño fundamental de SourceSafe supone que los clientes funcionan adecuadamente todo el tiempo y nada se interpondrá entre la comunicación. Por lo tanto, SourceSafe es fragil y no es digno de confianza. Los datos se corrompen, se pierde el trabajo y se gasta tiempo en resolver el problema.

Conclusión

Si estas considerando usar SourceSafe, considera algo diferente. Si estas usándolo actualmente, migra tan pronto sea posible. Aquí puedes encontrar algunas soluciones diferentes. En mi opinión personal Team Foundation Server o VisualSVN con Tortoise SVN son las mejores opciones.

Si debes usar SourceSafe obligatoriamente, y estas usando SourceSafe 6.0, toma un momento para leer la lista de bugs actuales y la lista de bugs arreglados en SourceSafe 6.0 para que sepas que puedes esperar. Esta página puede ser útil para versiones posteriores (página de bugs de Microsoft).

Este artículo es una versión modificada y traducida al español de un artículo web escrito por Alan de Smet. Desafortunadamente comparto sus experiencias negativas con este sistema.

Vía: http://www.highprogrammer.com/alan/windev/sourcesafe.html

Según un reportaje por ZDNet, Safari 4 (beta) es el navegador mas rápido hasta la fecha. En efecto, es 42 veces mas rápido al interpretar Javascript que Internet Explorer 7. Ademas, superó a Google Chrome, Mozilla Firefox y Opera.

(Imagen y Artículo Original por Nate Lanxon CNET UK Crave)

Los resultados exactos de esta serie de pruebas fueron los siguientes:

1) Safari 4 (Total time: 910ms)
2) Mozilla Minefield 3.2a1 (1,136ms)
3) Google Chrome (1,177ms)
4) Firefox 3 (3,250ms)
5) Opera 9.6 (4,076ms)
6) Internet Explorer 8 (5,839ms)
7) Internet Explorer 7 (39,026ms)

Las pruebas fueron realizadas usando SunSpider para probar la ejecución de Javascript. Se realizaron tanto en una PC con Windows XP SP2 como una Mac con OS X 10.6.

En mi experiencia personal, provee una navegación diferente a la de otros navegadores. La interfaz es muy distinta a Chrome o Firefox sin embargo provee muchas de las mismas funcionalidades. Uno de los grandes puntos que destacan a Safari 4 es la introducción de CoverFlow a su navegación de Favoritos/Historial.

En fin, ¡pruebalo tú mismo! Descarga Safari 4 aquí.

<< Via ZDNet

El siguiente artículo es verdaderamente interesante, el cual he traducido al Español con permiso del autor original “Sherri Davidoff“. Puede ser un poco largo, sin embargo vale la pena por el conocimiento adquirido al final.

¿De qué se trata? Adware, Programación, Internet Explorer, Windows y Seguridad en Informática.

Matt Knox, un instructor y desarrollador talentoso de Ruby nos habla de su inicio diseñando y desarrollando adware para Direct Revenue.

–

S: Tú desarrollaste adware. Bastardo.

M: [avergonzado] Si, lo hice. Escribí la mitad de él en Scheme, lo que significa que probablemente he implementado más código Scheme que cualquier otra persona en el planeta.

S: A ver, vamos desde el principio. ¿Por qué desarrollabas adware en el primer lugar?

M: Estuve completamente en la quiebra por un tiempo. Empecé a trabajar en software para filtrar SPAM. La empresa (Direct Revenue) se percató de mi trabajo y me contrató para analizar su cadena de distribución. Por un tiempo, el sitio por medio del cual sus ads (publicidad) corrían estaba dentro de los top 20 en Alexa. Tenía una cantidad impresionante de tráfico. Al llevar entre 4 y 5 meses trabajando ahí, un virus apareció que logró deshabilitar varias de las máquinas que usábamos para adware. Yo dije, “Se lo suficiente de C que podría remover el virus de las máquinas”, y lo hice. Ellos dijeron “Wow, eso fue impresionante. ¿Por qué no haces eso de nuevo?”. Entonces comencé a remover otros viruses, y ellos dijeron, “Bastante bueno que removiste todos los virus. ¿Por qué no remueves a la competencia también?”.

Fue divertido. Me mostró el poder realizar las cosas gradualmente. Es difícil lograr que personas hagan algo malo de un tirón, sin embargo, si puedes despedazarlo en suficientes piezas independientes, puedes hacer que la gente haga casi cualquier cosa.

S: ¿Sentiste que este era el inicio del descenso por el camino hacia el infierno?

M: ¡Oh si! Definitivamente. [Se ríe] De hecho creo que si sumamos todo lo que hice, el resultado es positivo, si solo porque removimos mucho mas adware de lo que yo instalé.

S: ¿Cuál era el modelo de negocios de Direct Revenue?

M: Su modelo de negocios era comprar un screensaver de alguien, o desarrollarlo ellos mismos. Era una tontería como un señor que esta lavando el vidrio. Dirían, “Oye, si quieres esto, instala nuestro adware y te lo damos gratis”. Una increíble cantidad de gente lo haría.

S: ¿Como le llamaban a eso? Supongo que no le llamaban “adware“.

M: Los buenos distribuidores diríamos “Este es software soportado por publicidad”. Aquellos que no eran tan buenos distribuidores lo hacían por medio de exploits en Windows. Además, algunos distribuidores de adware vendían el acceso. En sus términos de licenciamiento, el EULA, agregaban “Además, instalaremos cualquier otro software que creamos conveniente”. Claro está que nadie lee los EULAs, así que mucha gente aceptaba esos términos. Digamos, si tuvieran 4 millones de máquinas, lo cual es una red de adware de un tamaño bastante considerable, irían con cualquier otro distribuidor de adware y le dirían “¡Oye! Tengo 4 millones de máquinas. ¿Deseas pagar 20 centavos por máquina? Te pondré en todas”. En aquel tiempo no había leyes escritas para esto. Los EULAs eran reconocidos como contratos, así es básicamente cómo funcionaba toda la distribución.

S: ¿Tu empresa no era uno de esos que usaban exploits para lograr introducir software en las computadoras?

M: No, no hacíamos eso. Algunos de los distribuidores si lo hacían. Si encontrábamos que un distribuidor hacía eso, diríamos “Ya no vamos a distribuir contigo”, y salíamos de esas máquinas.

Con lo que tenía un verdadero problema era con el trabajo de persistencia que estaba haciendo. Eso era para hacer que fuera más difícil que nuestra competencia nos sacara de la máquina. Era imposible que una persona nos pudiera sacar de la máquina- al menos de que pasaran por nuestro proceso de desinstalación. Tenías que ir a un sitio web, descargar el desinstalador, tomar un pequeño cuestionario sobre la razón por la que removerían el software de la computadora, y luego removía el software y dejaba una llave en el registro para asegurar que no volveríamos a instalar el software en esa PC. Desafortunadamente, algunos antivirus y anti-adware removían esa llave del registro por lo que nuestro programa a veces terminaba de vuelta en la máquina.

S: ¿Me puedes decir más sobre tus estrategias de persistencia?

M: Si. Probablemente debería explicar primero como funciona el adware. La mayoría del adware tiene como presa a usuarios de Internet Explorer (IE) porque conforman al sector más grande del mercado. Además, tienden a ser los menos conocedores de TI del mercado. Si usas IE, entonces no te importa o no conoces las vulnerabilidades que IE tiene.

IE tiene un mecanismo llamado Browser Helper Object (BHO) el cual es un bulto de código ejecutable al que se le informa de todas las llamadas web al ejecutarse. Corre en el proceso del navegador, lo que significa que puede hacer cualquier cosa que el navegador puede- lo cual básicamente significa lo que sea. Tendríamos un BHO que sirve los ads directamente, así que para poder borrarlo tendrías que remover todas las instancias del navegador. Eso es un poco de lo que llamo persistencia.

Agrégale a eso un instalador, que genera una entrada en el registro para que cada vez que inicie el sistema operativo, el instalador revisará que el BHO sigue ahí. Si lo está, bien. Si no lo está, entonces lo instalará. Eso está perfecto hasta que alguien va y elimina el ejecutable.

Lo siguiente que Direct Revenue hizo – de hecho debería decir yo hice, ya que estuve muy involucrado en esto – fue hacer un verificador, el cual revisa cada 10 segundos si el BHO sigue vivo. Si lo está, bien. Si no lo está, el verificador lo instalaría. Para hacer que fuera menos probable que detectaran al verificador, creamos un algoritmo para generar nombres de archivo aleatorios, el cual era igual por máquina, pero difícil de adivinar. Los primeros 6 caracteres eran la dirección MAC DES-codificado. Tomas la dirección MAC, lo codificas con DES, tomas los primeros 6 caracteres y listo. Era bastante bueno, excepto que el archivo era el mismo binario. Si hacías una suma md5 sobre el archivo, era igual donde sea, y siempre en la misma ruta.

Luego hicimos un revolvedor de funciones, el cual entraba en un archivo ejecutable, tomaba las funciones y las acomodaba al azar. Eso hace que la firma sea bastante diferente. También revolvíamos bastantes punteros dentro de las funciones. Eso cambiaba completamente la estructura del archivo.

Luego hicimos un bootstrapper, el cual era una pequeña sección de código escrito en Assembler el cual descifraba el ejecutable en memoria, y luego lo corría. Al mismo tiempo hicimos un proceso virtual ejecutable. Nunca he escuchado que alguien más haya hecho esto. Windows tiene esta  cosa llamada Create Remote Thread. Básicamente lo que hace es: Tú eres un proceso, yo soy otro proceso. Yo te llamo y te digo “¡Oye! Tengo este pedazo de código. Me gustaría mucho si pudieras correrlo”. Tú me respondes “Claro, porque eres un proceso de Windows – Eres todo hippie y amor gratis”. Los procesos de Windows, por cierto, son bastante promiscuos. Así, llamábamos un montón de procesos, les otorgábamos un pedazo de código, y lo ejecutábamos todo. Cada proceso sabía todo sobre dos de los otros. Eso les permitía generar un anillo… Soporte mutuo, ¿cierto?

Así que hemos progresado de tener una entrada en el registro, a tener un ejecutable, a tener un ejecutable con un nombre aleatorio, a tener un ejecutable que varía de máquina a máquina, a uno que está cifrado – bastante más de lo normal – a tener uno que ni siquiera corre como ejecutable. Corre como una secuencia de threads. Ahora esos threads pueden comunicarse el uno con el otro, y pueden revisar que el BHO está ahí y corriendo, y que nuestro software también está activo.

Hay un paso más que íbamos a tomar, pero que no terminamos haciendo, y eso es que íbamos a remover el uso de threads completamente y en su lugar usar interrupt handlers. Al parecer, en Windows puedes acceder al interrupt handler sin mucha complicación. De hecho, puedes registrar con el SO un montón de código para manejar un interrupt. Después todo lo que haces es permitir que el interrupt se inicie, y cada vez que ese interrupt arranque, despiertas, haces tus cosas y te vas. Nunca lo hicimos, pero era algo que estábamos pensando en hacer.

Lo que si hicimos fue crear llaves en el registro y archivos que no se podían modificar, por medio de un exploit llamado “impedance mismatch” entre el Win32 API y el NT API. Windows, desde XP, esta construido encima del kernel de NT. NT es fundamentalmente un sistema Unicode, así que todas las cadenas internas son Unicode contado de 16-bit. El Win32 API es fundamentalmente Ascii. Hay cadenas que puedes mostrar en Unicode contado de 16-bit que no puedes desplegar en Ascii. Notablemente, puedes tener cadenas con un Nulo en medio de ellas.

Eso significa que podíamos, por ejemplo, crear una llave en el registro que tenga un valor nulo en medio. Como la interfaz de usuario está basada en el Win32 API, las personas podrían ver la llave, pero no podrían interactuar con él porque al solicitarle el nombre estarían solicitando aquél que termina el Nulo. Por eso mismo, podíamos hacer llaves que eran invisibles o inmutables para cualquier persona usando el Win32 API. Como dato interesante, esto no era nada más los usuarios y nuestra competencia, pero aquellos que desarrollan los antivirus.

También desarrollamos un driver de aparatos, y luego un driver para impresoras. Cuando desarrollas un driver haces bastantes cosas locas, aún más allá de las que haces comúnmente en Windows. Esto era alrededor del tiempo en que la compañía [fue demandada por Eliot Spitzer y empezó a desacelerar sus procesos]. Hicieron una decisión de negocios bastante inadecuada para ser visibles, y pusieron su marca sobre todos los anuncios al mismo tiempo que yo estaba removiendo a la competencia y estábamos haciendo el trabajo de persistencia.

Cabe mencionar que también esta Scheme. Llegó un momento en que nos cansamos de desarrollar un nuevo programa en C cada vez que queríamos remover a la competencia de una máquina. Todos decían, “Necesitamos algo que sea personalizable”. Yo dije, “Vamos a instalar un lenguaje Turing-complete“, y para eso usamos tinyScheme, el cual tiene una licencia BSD y es una implementación bastante pequeña y rápida de Scheme que puede compilarse a un ejecutable de 20K si sabes lo que estás haciendo.

Entonces, en vez de crear un nuevo ejecutable cada vez que salía un nuevo gusano de internet, escribía un poco de Scheme que ponía en el servidor, y luego todo tipo de cosas desaparecían en la oscuridad. Terminó siendo una guerra de código distribuido en una red de 4-10 millones de computadoras.

S: En tu opinión profesional, ¿Cómo podemos evitar tener adware?

M: Um, corre UNIX.

S: [Se ríe]

M: De hecho si pudimos hacer que el cliente de ads funcionara bajo Wine en Linux.

S: Parece que con eso se fueron un poco lejos, ¿no?

M: Yo diría que era un mercado bastante limitado.

S: ¿Cual es el futuro del adware?

M: Hasta el punto donde la publicidad es dirigida de manera hermosa deja de ser publicidad y se vuelve información. El más claro ejemplo de esto es Gmail. No veo más que trabajos de Ruby on Rails y de Scheme en Gmail.

S: ¿No te saca de onda que haya un script automático filtrando tu correo?

M: Cuando pienso sobre eso, a veces me asusta. La buena noticia es que he estado del otro lado de los scripts automatizados. Su capacidad es increíblemente peligrosa, pero en la realidad no tiende a serlo.

Hubiera sido cualquier cosa para mí obtener la información de las tarjetas de crédito. Tenía 4 millones de nodos. Pude haberlo sin que cualquier persona en la empresa lo notara. Yo era el que desarrollaba Scheme, así que pude haber puesto un archivo de texto en algún lado y luego hacer que desaparezca, y no hubiera habido ni un ejecutable por ahí.

Pero no lo hice. Hacer eso, por definición, significado que tendrías que convertirte en criminal, y eso es bastante raro. Así que no estoy muy atemorizado por eso. Creo que la publicidad se convertirá en algo que es una masa de algoritmos, donde alguien dice “este chavo puede estar interesado en este nuevo lenguaje de programación”.

S: ¿Que tan privada es la información de la gente hoy en día?

M: Para nada.

S: ¿Crees que en nuestra sociedad nos hacemos creer que tenemos más privacidad de la que en realidad tenemos?

M: Oh, absolutamente. Si lo piensas, cuando yo uso una tarjeta de crédito, el modelo de seguridad es lo mismo que sacando tu cartera y diciendo “Saca todo lo que crees que ocupas y luego regrésamela”.

S: …Sin embargo, parece estar funcionando.

M: La mayoría de las cosas no tienen que ser perfectas. En lo particular, cosas que involucran interacciones humanas no tienen que ser perfectas, porque grupos de humanos tienen todas estas regulaciones y normas integradas. Si tú y yo tenemos un acuerdo y tú me quedas muy mal, siempre tendrás miedo a que aparezca en tu puerta con un bate y te mate. Por lo mismo, la gente no tiende a hacerse daño. Al menos no lo intentan. Un peligro, como sea, de encaminarse a una sociedad dirigida por algoritmos es que los algoritmos no tienen miedo de que aparezcamos y les demos unos golpes. Los algoritmos hacen lo que sea que están diseñados para hacer. Sin embargo, no me preocupo mucho de eso.

S: ¿Hay algo más sobre lo que desees comentar?

M: Lo bueno que tenga la gente es el reflejo de lo duro que trabajen por ello. Si deseas tener una máquina que esté limpio de software maligno, lo puedes tener. Si quieres privacidad personal, es posible – muy difícil, pero posible. Y yo creo que vale la pena.

–

Entrevista hecha y editada por Sherri Davidoff (Philosecurity). Copyright 2009, derechos reservados. Traducido con permiso del autor. Artículo original en Inglés: http://philosecurity.org/2009/01/12/interview-with-an-adware-author

*Ads: Técnica de promociones surtidas, cuyo objetivo fundamental es informar al público sobre la existencia de bien/es o servicio.

*Adware: Cualquier programa que automáticamente ejecuta, muestra o baja publicidad al computador después de instalado el programa.

*Virus: Malware que tiene por objeto alterar el normal funcionamiento de la computadora, sin el permiso o el conocimiento del usuario

*Scheme: Lenguaje de Programación funcional. Es un dialecto de LISP.

*Gmail: Es el servicio gratuito de correo electrónico ofrecido por Google.

*Ruby on Rails: Framework de aplicaciones web de código abierto escrito en el lenguaje de programación Ruby.

*Kernel: Centro principal del sistema operativo, encargado de hacer interactuar el software con el hardware.

*Bootstrapper: Un programa que puede actualizar al instalador antes de iniciar la instalación del programa.

*Screensaver: Programa de ordenador originalmente diseñado para conservar la calidad de imagen de las pantallas de ordenador.*Exploit: Método concreto de utilización de un bug, que nos permite entrar de forma ilegítima en un sistema informático.

*Direct Revenue: Empresa de Nueva York fundada en 2002 conocida por escribir adware.

*Assembler: Programa que se encarga de traducir un fichero fuente escrito en lenguaje ensamblador a código máquina ejecutable directamente por el ordenador.

*Interrupt: Un evento que causa que una computadora deje de hacer lo que estaba haciendo y le dé prioridad a una condición.

*Interrupt Handler: Procesos de software ejecutados para manejar cada tipo de interruptor.

La Agencia Nacional de Seguridad de Estados Unidos (NSA) ha ayudado, junto con mas de 30 organizaciones e individuos, a identificar los errores de programación de software más importantes que pueden llevar a hoyos de seguridad y áreas vulnerables que pueden convertirse en presas de criminales cibernéticos.

Expertos dicen que muchos programadores todavía no entienden muy bien algunos de estos errores.

Microsoft, NSA, Homeland Security y Symantec, entre otros, fueron quienes publicaron el documento.

“Necesitamos asegurarnos que todo programador sepa escribir codigo que esté libre de los 25 errores más importantes.” – Dice el director de SANS, Mason Brown.

Posteriormente agregó que “Luego debemos verificar que cada equipo de programación implementa procesos para buscar y arreglar estos problemas.”

Los 25 errores de programación mas peligrosos son:

• CWE-20: Falta de Validación de Datos Capturados
• CWE-116: Encodificación Incorrecta y/o Falta de Escape de Salida
• CWE-89: Falla al conservar la Estructura de Consultas SQL
• CWE-79: Falla al conservar la Estructura de Páginas Web
• CWE-78: Falla al conservar la Estructura de Comandos del SO
• CWE-319: Envío de información crítica como texto plano
• CWE-352: Envío/Recepción de Información mediante métodos “Cross-Site” (Sitios Cruzados)
• CWE-362: Condiciones tipo “Race”
• CWE-209: Fuga de Información al presentar Mensajes de Error
• CWE-119: Falla al Contener Operaciones dentro de los limites de un Buffer de Memoria
• CWE-642: Control Externo de Datos de Estados Críticos
• CWE-73: Control Externo de Nombre de Archivo o Ruta
• CWE-426: Ruta de Busqueda No Confirmado o Inseguro
• CWE-94: Falta de Control sobre la Generación de Código
• CWE-494: Descarga de Código sin Revisión de Integridad
• CWE-404: Eliminación, Cierre o Liberación de Recursos Inapropiado
• CWE-665: Inicializacidn Inapropiada
• CWE-682: Cálculos Incorrectos
• CWE-285: Control de Acceso Inadecuado
• CWE-327: Uso de un Algorítmo de Encriptación Roto o Peligroso
• CWE-259: Contraseñas establecidas mediante ‘Código Duro’
• CWE-732: Asignación Inseguro de Permisos para Recursos Críticos
• CWE-330: Uso Insuficiente de Valores Aleatorios
• CWE-250: Ejecución sin Privilegios Establecidos o sin su Verificación
• CWE-602: Aplicación de Seguridad de Servidor del lado del Cliente

Traducción: LeMiffe
Noticia: BBC
Foto: moty66
Artículo/Lista: SANS

LeMiffe

Entonces quizá esta información te pueda interesar:

TFS: Team Foundation Server

• Herramienta para Administración de Versiones y Cambios para Proyectos.
• Compilación/Deployment integrado, historial de cambios, administración de elementos de trabajo.
• Fácil adaptación de proyectos actuales de VS y SourceSafe a TFC: Copia, Pega, Agrega a Source Control y dale Check In.
• Es usado internamente en Microsoft para el control de sus proyectos.

MSDN Team

• Suscripción a todo el software MS Dev, OS, DB, VisualStudio y Office
• Cuesta $2,200 USD, igual que Visual Studio solo, pero incluye todos los “extras” además de cierto numero de incidentes de sopórte con Microsoft.
• Incluye 5 licencias de uso de TFS (5 CALs)

SourceGear

• Herramientas de Control de Versiones para equipos pequeños y medianos.
• Alternativa viable a TFS manteniendose mejor que Visual Source Safe.
• http://www.sourcegear.com

SubVersion

• Otra alternativa a TFS y SourceSafe
• Puede ser complejo para instalar/empezar a usar pero es mejor que Visual Source Safe.
• Tiene una integración buena con Explorer y Visual Studio.
• El plugin para usarlo con Visual Studio se llama Visual SVN y cuesta $30 USD.

Así que si la empresa para la que trabajas tiene dinero, y quiere optimizar sus sistemas y herramientas para mejorar la calidad y el tiempo de producción de software… Ya sabes que sugerirles… Microsoft Team Foundation Server!

LeMiffe

Para simular el navegador de Safari del iPhone o iPod Touch en windows se recomienda seguir los siguientes pasos. Lo que hace esto es afectar el user agent por lo que páginas diseñadas para navegadores para PDA/iPhone se mostrarán somo si estuvieses en el aparato mismo.

1. Descarga Safari para Windows -> http://www.apple.com/safari/download/
2. Habilita el Menu Debug (Develop en 3.2+)
   - Edita el archivo c:\Program Files\Safari\Safari.resources\preferences.plist
   - Agrega lo siguiente justo antes de </dict>:

   <key>IncludeDebugMenu</key>
   <true/>

   - Guarda el archivo y reinicia Safari.
   - Si no aparece has lo mismo en C:\Documents and Settings\user\Application Data\Apple Computer\Safari\WebKitPreferences.plist

3. Por último selecciona Develop > User Agent > Mobile Safari – iPhone o iPod Touch.
4. ¡Disfruta!

- LeMiffe