26 de noviembre de 2008

Los Fuzzy URLs y el Phishing

Dentro de la lista de vulnerabilidades que normalmente existen en los sitios cuyos usuarios han sido victimas de phishing se encuentra una que aunque muy simple, es culpable en gran parte de que los ataques de phishing sean más eficientes.

Ya que lo más importante a la hora de hacer el phishing (desde el punto de vista del atacante) es ocultar la verdadera dirección a donde se está enviando al usuario al hacer clic, una de las técnicas más comunes es la del uso del "fuzzy URL" o lo que serían direcciones muy parecidas en las que una simpe letra puede ser colocada en otra posición o reemplazada por otra parecida.

Por ejemplo:

WWW.MIBANCO.COM puede ser reemplazado por
WWW.MIBANC0.COM o por
WWW.MlBANCO.COM

¿Dónde está la diferencia? ¿Puede el ojo del usuario convencional verificar la diferencia?
La verdad no es fácil, incluso para el usuario experimentado. Además recuerde que cuando se muestran en el la barra de dirección estas variantes no se pueden comparar una al lado de la otra. En el primer caso hemos reemplazado la "O" con un cero y en el segundo la "i" mayúscula con una "L" minúscula (las escribo precisamente al revés ahora para que pueda apreciar la diferencia).

Este tipo de cambios es muy normal en los dominios de los phishers, sin embargo hay otros casos interesantes de los que debemos tener cuidado.

Normalmnete se peude leer perfectamnete un tetxo si se manteinen la cantdiad de lertas de cada palbara y la priemra y últmia lerta de cada una, como etse ejemlpo lo demeustra...

Por tanto aunque no sea tan evidente como en el ejemplo anterior (y esa es precisamente la ventaja) se puede confundir con facilidad por ejemplo www.soficredito.com con www.socifredito.com ¿Cierto?

Lo anterior solo demuestra que una protección simple de las empresas para proteger a sus usuarios contra el phishing debe ser el adquirir una serie de dominios (al costo actual no es gran esfuerzo y menos para un banco) para evitar que los phishers los usen. Normalmente no pasan de 3 o 4 variantes por dominio que al costo actual no son más de 35 a 40 dólares anuales.

Es importante recordar que la seguridad no debe depender de una gran super solución ya que en caso de que esta fuese violada el sistema quedaría completamente indefenso, sino por el contrario debe conformarse de una serie de soluciones eficientes que entorpezcan el camino del atacante.



26 de octubre de 2008

Los BHO (Browser Helper Objects) y su seguridad personal

Hace ya tiempo que Microsoft liberó el API de desarrollo para una tecnología llamada BHO o Browser Helper Objects, sin embargo ha sido en los dos últimos años que esta tecnología empezó a ser utilizada por parte de los amigos de lo ajeno o cybercriminales para tratar de obtener acceso al robo de datos confidenciales en línea.

Para empezar hay cosas que explicar: ¿Qué es un BHO?
No hay forma más sencilla de explicarlo que mostrando el ejemplo de la conocida e inofensiva Barra de Google. Un BHO es una extensión programada que se utiliza para "mejorar" las capacidades del navegador, específicamente Internet Explorer, que aún a pesar de sus nuevos competidores y la población creciente de usuarios Firefox y Chrome, ocupa casi el 80% del mercado.

Si aquellos que instalaron la barra de Google en IE tienen buena memoria, recordarán que el sistema de instalación les solicitó permiso para poder transmitir sus hábitos de navegación a Google y así alimentar los sistemas estadísticos como PageRank. Si la instaló y no lo recuerda, usted es de los que instala y no lee lo que está instalando, y para usted este artículo posiblemente será más útil aún.

Independientemente de que se le haya o no otorgado permiso a la Barra de Google (o de Alexa otro conocido ejemplo) mi punto demuestra que este tipo de objetos tiene la capacidad para conectarse desde su navegador a un sitio externo, y no puede ser detectado por los cortafuegos o "firewalls" ya que usan al Internet Explorer para ello, y éste tiene indudablemente permisos para navegar y comunicarse al exterior de su equipo ya que de lo contrario usted no podría ver las páginas que solicita.

Compliquemos el escenario: Imaginemos que la empresa ahora ya no es ni Google ni Alexa sino un tercero mal intencionado que desea obtener información confidencial de su computadora. Este personaje ha creado una barra con algunas utilidades o "caprichos" para usuarios que parece ser bastante útil. Usualmente un bloqueador de POPups, unos cuantos emoticons o caritas, el estado del tiempo o alguna otra información dirigida al público al que desea llegar.

Al igual que sus serios contrapartes, este BHO específico también colecta información de navegación y en ella sus números de cuenta, sus claves de acceso bancarias y otra buena cantidad de información personal cuya pérdida puede convertir su vida en un infierno.

¿Recuerdan la película "La Red" con Sandra Bullock? ¿Quién imaginaría en 1995 que un poco más de un decenio después la realidad superaría a la ficción y por mucho?

Estos amigos de lo ajeno no solo desarrollan este tipo de "utilidades" sino las venden en el mercado negro, y además del BHO incluyen una interfaz administrativa en la que el atacante puede ver en tiempo real lo que hacen sus victimas.

Un problema adicional es que con este tipo de intruso en nuestro navegador, de nada sirve la conexión encriptada o SSL que utilizamos a la hora de entrar en una página que requiere cierto nivel de privacidad, ya que el BHO toma los datos del navegador, quien ya los ha convertido en información legible para nuestra lectura.

No estoy tratando de asustarles, el que está asustado soy yo cuando pienso en la cantidad de personas vulnerables a este tipo de ataque.

El problema se agrava radicalmente cuando pienso en que las defensas existentes ante este tipo de ataque aún no son muy eficientes, ya que como este tipo de objetos se acopla al Internet Explorer, quizás no sean tán fáciles de detectar como lo pudieran ser un programa malware o un virus reconocido. Sin embargo, los programas antivirus son nuestra primera línea de defensa ya que contiene la firma digital de algunos BHO reconocidos, pero igual que con los virus, pueden aparecer nuevas variantes y en el caso de los BHO son más difíciles de detectar.

Una razón más por la que preocuparnos a la hora de navegar en línea!
Hasta la próxima...

7 de octubre de 2008

Cross Site Scripting - XSS ¡Otro enemigo peligroso!

XSS o Cross Site Scripting que aunque las siglas no concuerden se coloca la X para evitar confusión con CSS (Cascading Style Sheets), es básicamente una técnica de inyección de código en un sitio mediante el uso de técnicas que permiten insertar específicamente Javascript o VBscript en los URLs o en los campos de un formulario que no ha sido validado para tal efecto para que ejecute en el contexto de otro sitio.

Así por ejemplo si insertamos XSS en un campo de un formulario cuyo contenido posteriormente será mostrado, podemos insertar código javascript para que se cree un pop-up, o se abra un iframe que contenga información de otro sitio.

Esta técnica puede permitir que un URL que normalmente lleve información por método GET se convierta en una vulnerabilidad de nuestro sistema, ya que enviando a dicho URL una inyección XSS, podemos hacer que el sitio receptor nos muestre contenido "tóxico" como por ejemplo una página de malware u otros.

También podemos hacer que dicho código insertado reemplace las "cookies" creadas para validación e ingreso en un área no permitida por ejemplo.

En fin las técnicas XSS son muchas y no podemos mencionarlas todas aquí, sin embargo si podemos explicarle al programador como prevenirlas (en parte por lo menos)

Es necesario primeramente evitar la inclusión de las cadenas "javascript:", "vbscript" y "<script" debido a que un código javascript sin ellas no se puede reconocer como tal, pero cuidado los hackers saben algo de esto y colocan las cadenas de formas diferentes, como ejemplo: "JaVaScRIpT" o las esconden con los códigos hexadecimales correspondientes ejemplo: %22%3e%3c%73%63%72%69%70% enviado por el URL significa "<script>"

En cuanto a los campos de los formularios es importante prevenir el uso de TAGS de HTML y preferiblemente evitar que el usuario pueda usar estilos directamente ya que en el URL de una imagen de fondo se puede colocar perfectamente código XSS también por ejemplo:

<DIV fu="alert('Hola mundo');" STYLE="background-image: url(javascript:eval(this.fu))">

Este código inserta una función "fu" y la llama desde una URL asignada a una imagen para el fondo del elemento DIV. Interesante ¿no?

Ahora imaginen que dicho código no es tan sencillo como para mostrar simplemente una ventanita con el texto "Hola mundo" y que en dicho URL llamamos una rutina javascript con capacidad de cargar un AJAX que envíe lo que vamos escribiendo en un formulario a otro lugar.
Escalofriante ¿no?




4 de septiembre de 2008

Cuidado con los Keyloggers!

Un "Keylogger" es una herramienta de seguridad que se utiliza para controlar las pulsaciones de teclado en un equipo determinado. Si instalamos uno en un computador, podremos después de un determinado tiempo tener un registro de todas las teclas que se pulsaron mientras éste estuvo activo.

Los hay de dos tipos, los de hardware y los de software. Los primeros que interceptan a nivel físico la comunicación entre el teclado y el ordenador, sin embargo son visibles en la mayoría de los casos (los hay que se pueden colocar dentro del teclado) y en realidad no son los que nos preocupan en este caso.

Los Keyloggers de software, son programas que acceden al sistema operativo e incluso a los interruptores de hardware y obtienen copia de todas las pulsaciones registradas sin que sepamos que se está grabando un achivo en nuestro equipo que contiene dicha información. Inclusive algunos pueden comunicarse por Internet y enviar lo que van capturando.

Cómo se puede apreciar son extremadamente peligrosos, ya que pueden capturar datos importantes como números de tarjetas, passwords e información confidencial sensible.

¿Cómo combatirlos? La solución más sencilla es la de siempre, un buen antivirus tiene en sus listas de firmas digitales atrapados a un buen número de estos programas. Sin embargo, siempre aparecen nuevos, por lo cual es muy importante tener los antivirus actualizados diariamente.

También es muy importante tener cuidado con los programas de mensajería (Windows messenger, ICQ, Yahoo messenger) ya que los últimos utilizan "plugins" (adaptaciones o mejoras a gusto del usuario) que pudieran contener un keylogger. no los descargue si no provienen del sitio original que desarrola su programa de mensajería.

En último lugar, tampoco descargue "plug-ins" o "addons" para su navegador sin que sean reconocidos por los fabricantes de los navegadores, es decir no descargue "programitas" adicionales para Firefox, IE u otro navegador si no lo hace en las páginas especializadas para este tipo de aplicaciones reconocidas por Firefox, Microsoft o cualquier otra organización seria, ya que es muy fácil desarrollar un keylogger que intercepte solo lo que usted introduce en los formularios que viajan en la web, inclusive no necesariamente debe ser un keylogger. Este tipo de mini-aplicaciones está convirtiendo a los navegadores en el nuevo campo de batalla de la seguridad personal.

Hasta la próxima...

25 de agosto de 2008

Ruby ¿El Santo Grial de lo lenguajes de programación?

Como programador siempre estoy tratando de alcanzar como en las fábulas el "Santo Grial" de los lenguajes de programación. No es un asunto fácil, la verdad es muy complicado.

En las características más importantes que buzco hay muchas, pero las más importantes suelen ser las que tienen mucho que ver con la eficiencia y rapidez a la hora de desarrollar, así como el precio, el soporte existente, las interfaces de desarrollo que lo apoyan y por supuesto las librerías de codigo que debieran ayudarnos a producir más y mejores aplicaciones.


No es muy reciente la aparición en el ambiente de la programación de Ruby, un lenguaje de programación presentado al público por Yukihiro "Matz" Matsumoto en 1995, quien le colocó el nombre como en broma aludiendo al lenguaje de programción Perl. Puedes descargarlo en http://www.ruby-lang.org/es/.


Sin embargo es en los últimos tres años que Ruby ha entrado a formar parte de las grandes ligas del desarrollo, debido principalmente a su elegancia, eficiencia y a las utilidades o librerías que lo respaldan.

La primera cosa que me gustó de Ruby fué el hecho de que es un lenguaje de Código Abierto, lo que significa que no tiene costo, y a pesar de esto es soportado por una comunidad de desarrolladores que lo actualizan y mejoran constantemente apoyados en el tipo de licencia GPL.


También me fascinó el hecho de que el lenguaje es multiplataforma, es decir que lo que desarrollo para Linux, con pocos cambios puede servir para Windows o Mac. Bueno hay que aclarar con algo de ironía incluida ya que sabemos que una aplicación "a todo dar" siempre necesita alguno que otro ajuste al cambiar de sistema así esté hecha en Java.


También me gustó que es un lenguaje interpretado, por lo que cualquier máquina que tenga Ruby instalado puede ejecutar el código. No me preocupo en lo referente a la velocidad de procesamiento cuando veo las velocidades de los CPUs de hoy en día y las comparo con mi antigua 486Dx2 de 60 MegaHertz. (por si no lo han notado ya vamos por 3 ó 4 GigaHertz, y yo ya perdí la cuenta).


Luego, al profundizar un poco, me asombré con al gran cantidad de librerías disponibles. Todos los programadores sabemos que las librerías son ante todo una gran fuente de ayuda para no tener que reinventar la rueda. Pueden vistar http://rubyforge.org/ y percatarse de la gran cantidad de paquetes y librerías existentes para el lenguage. Tiene más de 6500 proyectos registrados al momento de redactar este artículo.


También me gustó mucho el hecho de que existe mucha bibliografía en Internet y se han publicado bastantes libros, incluso algunos de ellos completamente gratis, por lo que dejé de preocuparme por el soporte y la curva de aprendizaje. Un interesante y vasto tutorial se encuentra en http://www.rubyist.net/~slagell/ruby/index.html


Otro detalle que me pareció fascinante fué su sistema de actualización y descarga de componentes llamado GEMS. Es una utilidad (gestor de paquetes tipo linux) que una vez instalada controla los archivos y te permite descargar los paquetes y actualizaciones necesarias con una sola línea desde la interfaz de comandos. Ejemplo: Gem install rails, te descarga e instala en menos de 5 minutos toda la interfaz de desarrollo web llamada RAILS, sobre la que ya vamos a hablar.


Pero lo que realmente me terminó de impresionar fué una de las aplicaciones o componentes que están haciendo de Ruby un lenguaje de los grandes, es decir su interfaz de desarrollo web llamada Ruby on Rails (RoR o Rails para los amigos) que solo significa "Ruby sobre Rieles".


Esta interfaz se instala en menos de 5 minutos como mencionamos antes e integra toda una serie de librerías para desarrollo web y hasta su propio servidor web (Mongrel o Webrik) el cual puede manejar nuestras aplicaciones inclusive como servicios bajo Windows o usando a Apache como proxy. Si quieres saber más de RoR puedes ir a http://www.rubyonrails.org/.

5 de agosto de 2008

¿Porqué Flash sigue siendo un problema para las maquinarias de búsqueda?

El contenido en Flash y las páginas en HTML son fundamentalmente diferentes. Solo porque ahora Google puede extraer palablas e indexar algunos archivos en Flash, no significa que Flash sea amigable a los buscadores. A continuación algunas razones de lo anterior:


  1. En Flash es difícil dividir el texto en secciones representativas debido a que no utiliza tags como <h1> o <p> para separar diferentes secciones del texto. Por lo tanto se hace difícil entender que es importante y que no lo es. Para empeorar el asunto los diseñadores en Flash separan las letras de las palabras para lograr interesantes efectos lo que impide que dichas palabras puedan ser indexadas por los buscadores.

  2. Usualmente todo el contenido completo de un sitio es presentado en un solo URL. Usted no puede hacer un enlace a una parte específica de un sitio desarrollado enteramente en Flash, lo que significa que para las maquinarias de búsqueda también es difícil encontrar las zonas relevantes de un sitio desarrollado en esta tecnología. Adicionalmente los sitios en flash no enlazan entre sus secciones con enlaces comunes, lo hacen con comandos del lenguaje Activescript, por lo que no existen enlaces como los solemos conocer en la web entre sus propias páginas.


  3. La estructura de un sitio en Flash hace muy difícil poder obtener altos rankings en los buscadores. Muchos archivos en Flash enlazan desde otros archivos en Flash y no hay otros sitios que puedan enlazar a estos elementos internos. La ausencia de links externos provenientes de otros sitios hace muy difícil el posicionamiento.


  4. Flash no utiliza los métodos básicos de posicionamiento SEO (Search Engine Optimization). Normalmente usted no conseguirá enlaces con atributo "text" o imágenes con atributos "alt" en los que colocar las palabras importantes.


  5. Mucho contenido desarrollado en Flash todavía no es indexable. Y si bien Google y Yahoo lo empieza a hacer, los demás buscadores importantes aún no lo hacen.

No quiero decir con esto que la tecnología es mala o deficiente, todo lo contrario es muy buena, pero trate de evitar la creación de sitios completamente desarrollados en Flash y úselo donde realmente sea necesario, recordando las advertencias anteriores.


28 de julio de 2008

Si los programas de lectura de e-mail enredan sus boletines y su código HTML ¡Resuélvalo!

¿Contienen los boletines o "mailings" que envía a sus listas de usuarios enlaces de texto que redirigen a sus lectores a una versión Web en caso de que no pudieran leer el contenido en sus aplicaciones de correo tradicionales? Si no es así, deberían. Pero este simple detalle no lo absolverá del pecado de un diseño en HTML no bien pensado para enviar por e-mail.

En los días en que las primitivas aplicaciones de lectura de e-mail (como por ejemplo las versiones tempranas de AOL) rutinariamente “masticaban y rasgaban” HTML, enlazar a una versión Web era su única defensa. Hoy en día casi cualquier aplicación de E-mail puede mostrar HTML apropiadamente. Pero todavía usted debe darle formato correctamente. Enlazar a una versión Web de su mailing sin corregir el HTML malformado o no estándar, es una forma descuidada y floja de manejar el código HTML que no se muestra correctamente.

Además, el HTML malformado es solamente parte del problema. Ahora que la mayoría de las aplicaciones de e-mail basadas en Web y escritorio, utilizan el bloqueo de imágenes y los paneles de visualización previa por defecto, ese enlace de rescate podría inclusive no aparecer si lo agregó a una simple y larga imagen HTML.

Tal como acabamos de hacer notar, usted debería diseñar los primeros 8 a 10 centímetros de su mensaje con texto y HTML que explique a los lectores que contenido u oferta van a encontrar más abajo. Eso los incentivará a activar las imágenes, y tomar la acción deseada. De otra forma, podrían borrar el mensaje sin siquiera llegar a leerlo, particularmente si todo lo que logran ver es un gran espacio en blanco.

La siguiente lista identifica 12 consejos comunes de HTML para e-mail. Compárelos con su propio HTML antes de enviar su siguiente mailing o campaña de e-mail. ¡Ignórelos bajo su propio riesgo!

  1. Codifique su HTML a mano. El diseño HTML para E-mail es más simple que para Web. Los programas de diseño de HTML como FrontPage no son ideales para crear diseños de e-mail en HTML. Estos típicamente agregan código extra y causan estragos en algunas aplicaciones de lectura de e-mail. Tampoco use la función de Word “Guardar como HTML”, pudiera parecer sencillo, pero créanos – usted estaría cometiendo una aberración en HTML. Utilice los servicios de un programador de HTML experto para crear una plantilla limpia que podrá utilizar varias veces. Alternativamente si utiliza programas como Dreamweaver, MEW utilice un editor de texto plano, y remueva todo el código innecesario a mano.
  2. Sea cuidadoso con las tablas. Evite usar tablas anidadas, algunas aplicaciones como Lotus Notes y Netscape Messenger en particular, pueden no mostrarlas correctamente. También evite utilizar Gif’s espaciadores transparentes de 1x1 pixel (para forzar los anchos en las celdas de sus tablas). Estos se encuentran normalmente en el spam y podrían hacer que su dirección de e-mail fuera bloqueada, así como su mensaje.
  3. Tenga cuidado con las imágenes de fondo. Las imágenes de fondo para celdas individuales y/o tablas son generalmente aceptadas, pero no son mostradas en aplicaciones de lectura de e-mail como Lotus Notes.
  4. Coloque las imágenes en su servidor web en vez de incrustarlas en los mensajes. Algunos proveedores de acceso filtran los e-mails con imágenes incrustadas, ya que el tamaño del archivo aumenta considerablemente con estas. Lo anterior también puede acarrear un bloqueo de la cuenta de envío y por supuesto del mensaje. En cambio, coloque solamente en su mensaje imágenes referenciadas a su servidor, y asegúrese que tengan el URL de ubicación completo (ejem. http://www.miservidor.com/images/imagen.jpg). No utilice enlaces relativos, ya que es muy común ver mensajes con imágenes no cargadas que hacen referencia por ejemplo a “images/imagen.jpg“ en vez de hacerlo a la dirección URL de la imagen completa.
  5. Evite el CSS (Cascading Style Sheets). El CSS puede simplificar enormemente el proceso de desarrollo de un sitio Web y para algunos incluido yo es la mejor idea que ha existido, pero en los mensajes de e-mail en HTML puede causar una presentación incorrecta en algunas aplicaciones de e-mail. Si debe usar CSS, utilícelo en el estilo incrustado también conocido como “inline CSS”. Inserte los estilos creados con CSS entre los dos tags "BODY". No lo coloque entre los tags "HEAD" . Los estilos también pueden ser incrustados directamente en el código del mensaje.
  6. Mantenga el ancho de su mensaje entre 500 y 650 píxeles. Mensajes de HTML en e-mail de mayor ancho, obligan al usuario a usar la barra espaciadora horizontal, acción a la que no está regularmente acostumbrado al leer un documento de otro tipo. Los mensajes demasiado anchos son problemáticos especialmente en los paneles de visualización previa.
  7. Use el texto alternativo para las imágenes. El texto alternativo puede ser utilizado para describir una o dos acciones cuando la imagen es bloqueada o no se muestra por problemas de conexión. De todas formas tome en cuenta que el texto alternativo también se bloquea en algunos servicios web de e-mail.
  8. Agregue funcionalidades cuidadosamente. Muchas aplicaciones de e-mail no muestran correctamente o bloquean los formularios para que no pasen datos desde el mensaje de e-mail a su Web. Para las funcionalidades como “enviar a un amigo”, encuestas, consultas de búsqueda y otras, la forma más segura de colocarlas en un mensaje es mediante enlaces a páginas con dichas funcionalidades en su sitio Web.
  9. Simplemente dígale no al Flash. Coloque los sistemas de sonido, video y audio, además de flash en su sitio Web en vez de incrustarlos en sus mensajes. Coloque enlaces también en estos casos, ya que muchos sistemas no tienen la capacidad, plataforma necesaria o la versión correcta para ejecutar o mostrar este tipo de contenido. Además los usuarios de Outlook y Outlook Express, serán consultados acerca de permitir dicho contenido en sus equipos, y por temor a algún tipo de virus probablemente no permitirán que el contenido se muestre.
  10. Evite los scripts (Javascript, Vbscript etc.) siempre que pueda. Normalmente los scripts son comentariados o anulados por las aplicaciones de e-mail, especialmente las de uso en el web, causando que su código simplemente no se ejecute. Muchas veces son reconocidos como código malicioso y provocan el rechazo del mensaje. Nuevamente lleve a sus lectores a su sitio web, en donde podrá utilizar los componentes dinámicos con mayor tranquilidad y seguridad.
  11. Realice pruebas, pruebas y más pruebas. Es la misma vieja canción de siempre: Pruebe sus mensajes múltiples veces antes de enviarlos. Recuerde que un solo error a una lista de mil usuarios se convierte en mil errores. Esta es una fase crítica, que puede evitar muchos inconvenientes y no requiere de alta tecnología. Pruebe sus e-mails en cuentas claves creadas para las diferentes aplicaciones de e-mail (desktop y Web). Pruebe también sus mensajes en diferentes plataformas – PC, Macintosh – y diferentes navegadores como Firefox, Internet Exlorer, Netscape y Opera.
  12. Valide su contenido HTML en el servicio de validación de HTML del “W3 Consortium”
    ¡Es Gratis! Esto garantizará el mayor nivel posibhle de compatibilidad.

Sin duda si sigue estos consejos se encontrará con que la respuesta a su campaña aumentará radicalmente, por lo que necesitará menos envíos para obtener un mejor resultado y desgastará menos su lista de envío.

14 de julio de 2008

¿Que hacer cuando el puerto TCP 25 (SMTP) es bloqueado por el ISP?

No es difícil ver casos de usuarios que no pueden usar el servicio de salida SMTP (25) directamente debido a que su proveedor de Internet lo mantiene bloqueado para evitar que se envíe SPAM directamente desde las direcciones otorgadas para ADSL o inclusive Dial-Up.

Normalmente estos proveedores obligan a sus usuarios a configurar sus cuentas de e-mail para hacer "relay" en el servidor SMTP de la empresa proveedora de servicios y no en el servicio que se tiene contratado (para nuetro website, por ejemplo) , lo cual es de alguna forma una manera poco razonable de acabar con un problema quitándo libertades a otros. Además los servidores de los ISP a veces tienen muchas solicitudes de servicio, poco ancho de banda para el volúmen de e-mail saliente y simplemente son atacados como todos por hackers, spammers y otros bichos enfermizos.

Para empezar hay que aclarar que el puerto 25 es un estándar en Internet y que los puertos TCP/UDP se parecen mucho a los canales de comunicación de los radioaficionados, lo que significa que para poder hablar con alguien necesitamos ponernos de acuerdo en el canal a utilizar. Como hay millones de servidores conectando por el puerto 25, no podemos simplemente cambiar de puerto, porque quedaríamos aislados.

Muchos servidores de e-mail en sus versiones recientes, tienen la posibilidad de escuchar conexiones entrantes simultáneamente en puertos alternativos, por lo que a veces todo el problema se resuelve con preguntar a nuestro proveedor del servicio de e-mail si sus servidor tiene dicha opción y en caso tal cual es el puerto alternativo. Con estos datos solo es necesario ir a la configuración avanzada de nuestro programa cliente de e-mail y colocar el puerto correcto.

Una solución interesante, es la que ofrecen algunos servicios de e-mail, y es la de activar el servicio http-mail, que no es más que una comunicación por el puerto 80 mediante el protocolo HTTP (el utilzado para ver transportar las páginas web). Usted puede configurar a Outlook, Thunderbird y otros para que utilicen dicho protocolo en vez de SMTP. Cuando usted utiliza Hotmail/MSN por Outlook, posiblemente sin saberlo está utilizando esta opción.

Otra solución un poco menos práctica pero funcional, es tratar con su servicio de e-mail a través de web-mail, es decir una aplicación en Internet que le permite ver su e-mail desde cualquier parte con su navegador. Casi todos los servicios de e-mail de los proveedores de alojamiento soportan esta opción. Usted accederá a su servicio a través de su navegador y solo utilizará el puerto 80 (HTTP). No confunda esta opción con la anterior, ya que en esta usted no podrá descargar el e-mail en su computador, a menos que la aplicación le permira hacerlo como si bajara un archivo.

Otra solución mucho más compleja tiene que ver con enrutamiento TCP/IP, bastante más complicada y es básicamente para quienes tienen un servidor dedicado: se configura un router local para mandar las conexiones salientes a otro puerto, y en nuestro equipo servidor de e-mail se configura una aplicación de firewall o routing para que todas las solicitudes a dicho puerto se reenvíen al puerto 25. Esta solución es principalmente para empresas que tienen su propio servidor de e-mail y posiblemente un router o firewall aunque estos no necesariamente tienen que ser en hardware y pueden ejecutarse como aplicaciones en el servidor. Consiste básicamente en saltar el puerto bloqueado usando otro puerto a nivel de routers, y se puede configurar de varias formas. Aquí lo único que pueden hacer los usuarios convencionales es llevarle una copia de esta solución al administrador de redes de su empresa para que analice la factibilidad de la misma.

También hay soluciones como Google Apps, que nos permiten redirigir nuestro dominio a los servidores de Gmail. La versión gratis es muy buena, y si decide pagar obtendrá una herramienta insuperable. Solo es necesario hacer unos pequeños cambios en el puntero MX el servidor DNS de nuestro dominio. Además incluye servicios de colaboración en línea como Google Docs, Google Calendar y más... La dirección es: http://www.google.com/a/help/intl/es/admins/editions.html

Por último la más sencilla de todas es la que se basa en usar una cuenta de Gmail (MSN o Yahoo también sirven). Consiste en configurar nuestro programa cliente de correo para que utilice dicha cuenta directamente, y en agregar al campo "reply to" de la configuración de esta cuenta la dirección en la que queremos recibir los mensajes. Además en la configuración de la cuenta de Gmail (en línea), la configuraremos para que actue como "forward" y envíe todo lo que reciba a la cuenta en la que queremos recibir los mensajes, esto es por si algún destinatario en vez de hacer reply directamente decide escribirnos a la cuenta de Gmail. No es la más eficientes ya que algunos destinatarios verán la dirección de e-mail de Google, pero centraliza todo lo que se recibe en la cuenta deseada.

De seguro que alguna de las anteriores soluciones se ajustará a su caso, así que manos a la obra...

13 de julio de 2008

¿Qué es el "spoofing"?

Se conoce como "spoofing" como el conjunto de técnicas de suplantación de identidad en la red, generalmente con intenciones fraudulentas o de investigación.

Existen diferentes técnicas o tipos de spoofing, y todos ellos se basan en la suplantación de direcciones de red en diferentes protocolos, de lo que sugen una serie de tipos de spoofing diferentes.

Quizás el más conocido es el "IP spoofing", que se refiere precisamente a la suplantación del número IP a nivel de protocolo IP, por lo cual es quizás el más difícil de generar y actualmente los routers y firewall son muy capaces de detectar este tipo de técnica.

Otro muy conocido es el "ARP spoofing". El protocolo ARP es el que se encarga de traducir los números IP a numeros de identificación de red MAC que toda interfaz de red debe poseer (no confundir con Macintosh). En palabras cristianas ARP (Address Resolution Protocol) es el protocolo encargado de traducir una dirección IP al número MAC de su tarjeta de red ethernet, o de su dispositivo wireless (ejemplo 192.168.0.1 a 00-aa-00-62-c6-ff ). Tanto el IP spoofing como el ARP spoofing son técnicas muy poco utilizadas actualmente, ya que además de ser algo complejas, solo sirven en una dirección, es decir desde el host infectado hacia la dirección destino, y que para que funcionaran en dos sentidos (ejemplo: WEB) ambos lados de la comunicación deberían ser "infectados" por programas (casi siempre troyanos) que manipulen los paquetes de comunicación.

Empezando con algunos algo tipos de spoofing más peligrosos, está el "DNS spoofing" en donde a quien se ataca es al servidor DNS específico del dominio a victimar, y se configura para que indique a las solicitudes entrantes un número IP diferente al que no pertenece realmente al dominio, normalmente otro equipo en donde se encuentran los procedimientos engañosos y/o fraudulentos. Esta técnica se elimina fácilmente por parte de los propietarios de dominios, con la actualización de su software DNS y el uso de certificados digitales, ya que estos últimos están sembrados en el servidor correcto y no pueden ser emulados o copiados en la máquina suplantadora. Este es un caso de ataque en el que el usuario común no interviene para nada, y no necesita estar infectado para ser victima ya que el infectado es el servidor de dominio. Sin embargo puede evitar ser engañado simplemente verificando el certificado de seguridad del sitio. Lo peor de esta técnica es la propagación en otros servidores DNS de la información adulterada, llamada generalmente Envenenamiento DNS (DNS poisoning).

Otro tipo de técnica de este tipo es el "WEB spoofing", que enruta las solicitudes de un usuario a un servidor que actua de intermediario entre el usuario y el servidor destino, recibiendo la información y reenviándola, de modo que el usuario no pueda percatarse de nada (actuando como un proxy). No hay que confundir este tipo de ataque con el "phishing", ya que en este caso no se emula la página destino, solamente se filtra la información entre esta y el usuario. Normalmente este tipo de casos ocurren cuando un troyano modifica un archivo en su equipo llamado "hosts" (sin extensión). Este tipo de archivo es una extensión al servicio de búsqueda de nombres y normalmente se usa para configurar redes locales, sin embargo allí basta con escribir el nombre del host y su dirección IP (lógicamente la falsa) y el sistema asumirá dicha dirección IP sin verificar en el DNS correspondiente. Por lo tanto cada vez que usted pulse por ejemplo "www.mibanco.com" irá a una dirección falsa de donde será redirigido a la dirección definitiva.

Por último tenemos el "e-mail spoofing" que no es más que una suplantación de la dirección de e-mail. Esta técnica fué y es muy usada por los SPAMMERS, para enviar e-mail con direcciones no detectables en las listas anti-spam, o para hacer pasar una comunicación como proveniente de un usuario de cierta confianza. Actualmente se ha reducido considerablemente esta técnica (no así el SPAM) ya que los servidores de correo electrónico verifican que los usuarios y dominios que envían sean correspondientes al número IP del servidor que hace dicho envío.

En fin, como podrá apreciarse, existen una serie de técnicas, algunas muy avanzadas y complejas para las cuales el usuario común solo tiene una salida lógica: Tener un buen antivirus actualizado en el sistema, y usar el sentido común a la hora de ingresar datos confidenciales en la web. Recuerde: Ante cualquier sospecha deténgase y busque una buena asesoría, es preferible pasar por ignorante que ser víctima por incauto.

12 de julio de 2008

Adsense para Móviles

Publicidad en móvilesSi aunque no lo creas ya el gigante de la publicidad web ya tiene publicidad para dispositivos móviles.
Si eres usuario de Adsense y no has visto la oferta de dicho servicio aún en tu interfaz, es muy probable que sea porque las empresas de telefonía en tu zona no cumplen con los pasos de parámetros desde su WAP Gateway necesarios para que Adsense pueda evitar el "Click Fraud" (Fraude de clics)
¿Interesante cierto? Pues bien, algunas empresas de telefonía aún no han activado el paso de siertos parámetros en la cabecera de las solicitudes WAP, que permiten conocer por ejemplo el tamaño de la pantalla del dispositivo, así como el número ID de la tarjeta GSM y otros. Sin embargo no tardarán en adaptarse al modelo internacional, ya que es simplemente cuestión de actualización.

Así que ya sabes, si ves el servicio en tu interfaz de Adsense, es hora de crear tu sitio wap a la velocidad del rayo. Sobretodo si piensas en que una gran parte de la demanda de publicidad en ese medio ¡va a ser absorbida por muy pocos sitio! $$$$

Hasta la próxima!

11 de julio de 2008

¿Qué es el phishing o usurpación de identidad en la web?

El vocablo 'Phishing' que se pronuncia en inglés 'fishing' con un poco más de énfasis en la letra f, es un nuevo término acuñado por los especialista de seguridad en la red, que engloba a todas aquellas técnicas utilizadas por los 'phishers' para tratar precisamente de 'pescar' usuarios incautos en la red y usurpar su identidad electrónica con el fin de hacerse de su dinero o utilizar sus bienes electrónicos para efectuar compras en su nombre. En realidad este tipo de estafa electrónica es lo que se conoce como 'suplantación de identidad electrónica en la web'

¿Cómo actúa el phishing?
En el 75% de los casos el 'phishing' se basa en el envío de e-mails en los que supuestamente una entidad bancaria seria a la que confiamos nuestros ahorros, solicita por alguna razón que volvamos a ingresar nuestros datos personales de control (contraseña, nombre de usuario y otros importantes) mediante la pulsación de un enlace que nos llevará a una copia muy bien elaborada de la verdadera página de la entidad, en la que se solicitarán nuestros datos, para luego proceder a cometer el delito disponiendo de los mismos para ganar acceso al sistema y 'usurpar nuestra identidad'.

También en versiones más elaboradas de 'phishing' que pueden llevarnos a la página real de la entidad pero abriendo una ventana flotante (pop-up) que no es de dicha entidad, en la que también se soliciten nuestros datos. Otra versión y la más peligrosa es aquella que coloca en nuestro sistema un 'Keylogger' (rastreador de teclas pulsadas) que envía al phisher la información de los datos que hemos pulsado en la sesión de banca electrónica. Otra técnica muy temida es la de insertar una dirección falsa en el archivo "hosts" de su equipo cuyo fin es hacerle ir a una página falsa de la entidad bancaria aunque haya usted colocado la dirección correctamente en el navegador, indicándole a su equipo que tal dirección corresponde a un número IP en el que se encuentra la página del "Phisher".

¿Cómo prevenir el 'Phishing'?
Si bien existen varios sistemas que pueden ayudarle a controlar los intentos de phishing, estos en su mayoría se apoyan primordialmente en USTED, por lo que resultan inútiles si no se les presta la atención necesaria. Internet Explorer 7 y Firefox 2.0 tienen los denominados filtros anti-phishing, que le indicarán cuando una página ha sido reportada como 'falsa' por otro usuario. Sin embargo en países como el nuestro estas ayudas llegan a veces tarde por lo que el hecho de que estos filtros no indiquen a una página como falsa no necesariamente significa que no lo sea.

A continuación explicaré las normas esenciales que debe seguir antes de caer en una 'trampa de phishing'.
  1. NO ENTRE EN PÁNICO
    Normalmente los e-mail enviados por los practicantes de este tipo de estafa electrónica, tratan de urgirle a proceder de inmediato en la supuesta acción que le llevará a ser estafado. Para empezar, por norma general no hay forma de que una entidad bancaria le solicite a usted datos que ya tiene, y menos por e-mail. No se angustie, recuerde que aunque el comunicado le indique que si no procede a ingresar sus datos en las próximas 24 horas perderá su dinero, una llamada a la entidad será mucho más eficiente a la hora de resolver un problema supuestamente tan grave. Recuerde que lo que quiere el atacante es precisamente que usted no piense.
  2. NO CREA EN LOS ENLACES EN EL E-MAIL
    Un banco jamás le enviará un enlace sin antes usted haberlo solicitado, y aunque lo haya solicitado por algún procedimiento (recuperación de password por ejemplo), siempre procederá a llamarle primero o a esperar su llamada. Por otra parte, los enlaces en el e-mail pudieran simplemente engañarle. Cuidado: ¡No se crea demasiado inteligente! Usted podría inclusive pasar por encima del enlace con el ratón y ver el mismo enlace en el texto de apoyo que aparece en una ventanita.
  3. VERIFIQUE LA IDENTIDAD DEL SITIO
    Todas las entidades bancarias están en la obligación de proveer una 'conexión segura' lo que significa que toda dirección de banca electrónica de un banco debe empezar por las letras 'https' a diferencia de los sitios web tradicionales que empiezan con 'http' (sin la s). No confunda las páginas informativas del banco con las páginas de banca electrónica, las primeras no necesitan conexión segura, pero en cambio cualquier página en la que usted deba introducir datos importantes debería tener este tipo de conexión. A modo de dato adicional, todos los navegadores web (Firefox, Internet Explorer, Opera etc.) le mostrarán la imagen de un candado en alguna parte de su interfaz aclarándole que la conexión es segura (https), sin embargo si usted hace doble clic en dicho candado, podrá ver quién es el propietario del certificado de seguridad del sitio en el que usted está navegando.
  4. INSTALE Y ACTUALICE REGULARMENTE UN BUEN SISTEMA ANTIVIRUS
    Para el caso específico de los conocidos como 'Keyloggers' o capturadores de pulsaciones de teclado, es necesario mantener su antivirus actualizado. También existen los troyanos que modifican los DNS a los que su máquina solicita información por defecto, y aquellos que directamente modifican el archivo "hosts". Inclusive los hay que hacen todo esto y más en uno solo.

    Estos programas malignos pueden llegar a nuestro sistema en forma de 'troyanos' que se instalan al ejecutar una aplicación, descargar un componente "Activex" en una página web y otras acciones no muy fáciles de prevenir.

    Actualmente los sistemas de banca electrónica avanzados utilizan los denominados 'teclados virtuales', o teclados de pantalla en los que es obligatorio usar el ratón y que modifican la posición de los números cada vez que usted los utiliza. También los hay que esconden a la vista los números y otras teclas cuando se pasa por encima de ellos con el ratón, esto es para evitar que se tomen las coordenadas de la pulsación. En muchas diferentes versiones estos teclados eliminan de alguna u otra forma la posibilidad de que su clave sea interceptada. Los hay más o menos sofisticados pero cada uno a su manera son de gran ayuda. Claro no todos son perfectos y a medida que pasa el tiempo los hackers consiguen formas de imitarlos y violarlos, por lo que es mejor confiar en un buen antivirus. No use una aplicación de banca electrónica que no disponga de algún tipo de sistema de seguridad como los mencionados.
  5. ANTE CUALQUIER DUDA LLAME AL BANCO
    Todos los bancos que en la actualidad ofrecen servicios de banca electrónica (por lo menos así debería ser) tienen personal dispuesto a ayudarle, y en la mayoría de los casos disponen de una unidad específica preparada para atender estos casos.
  6. EVITE COLOCAR INFORMACIÓN PERSONAL EN LA WEB
    Los hackers conocen y estudian a sus víctimas, para descifrar sus claves y otros detalles de seguridad muchas veces basta con conocer sus gustos y aficiones. Trate de no publicar información que pudiera comprometer sus accesos en portales como FaceBook o MySpace ya que si usted coloca que por ejemplo le gusta la musica de Evanescence, no sería muy extraño que su clave fuera el título de alguno de los éxitos de dicho grupo. Lo mismo sucede con su fecha de naciemiento y otros detalles que se suelen agregar en los "perfiles" de las mencionadas comunidades virtuales.

Y para finalizar recuerde:
De nada sirven las ayudas y controles si Usted no toma las medidas necesarias en lo referente a seguridad electrónica para proteger su identidad.

9 de julio de 2008

Webmasters: ¡Cuidado con las ofertas Pay per Action!

Hacer publicidad en la web, o disponer de un sitio para ofrecer espacios publicitarios desde los primeros pasos de las antiguas punto.com siempre ha sido un proceso algo tortuoso a menos que utilicemos los servicios de empresas dedicadas al proceso de "Adserving" que son algo así como intermediarios entre el anunciante y el medio.

Sin embargo abrazadas por las grandes pérdidas del pinchazo de la burbuja de las punto.com estas empresas durante un tiempo empezaron a proponer cualquier tipo de trato a aquellos que aún persistían en tratar de rentabilizar sus sitios mediante la oferta de espacios publicitarios.

Personalmente me cansé en enviar visitas a páginas de diferentes tipos para que luego de alcanzar una cifra mediocre de ingresos, me cambiaran las reglas del juego apoyándose en contratos leoninos en los que no había forma de ganarles una. Una vez alcancé la enorme cifra para aquellos malos tiempos de 150 dólares en un mes y me restringieron a otro sistema de pago ya que a pesar de haber llevado una cantidad de clics importante a sus sitios, al parecer estos no habían generado las ventas esperadas.

Pasó el tiempo y desde la aparición de Google Adsense y Adwords las cosas cambiaron radicalmente. Si bien Google nunca nos dice cuanto nos va a pagar exactamente por clic, una vez ingresado a nuestro balance un monto determinado, jamás lo cambia. ¡Eso ya era una diferencia radical! Si bien creo que Google paga muy poco por lo que cobra, basado en que además de ofrecer mis espacios en Adsense también utilizo Adwords, hasta hace poco tiempo era el único intermediario de “adserving” responsable con el que se podía tratar.

Antes de Adsense, la empresa de adserving que no te daba un pago miserable por click, restringía los clics pagados (con la excusa de limitar el fraude de clics) a un click por usuario por día desde tu sitio, es decir si un usuario desde tu sitio hacía click sobre dos banners diferentes el mismo día, solo te pagaban uno. Ah! y el usuario no se calculaba por sesión sino por número IP fijo. Es decir, si varios usuarios hacían clic en tu sitio desde una misma computadora o a través de un proxy (un server que navega por varias máquinas) entonces te pagaban igualmente un solo clic. Y este era tan solo uno de los muchos trucos que usaban...

Estas "protecciones" y otros "pequeños errores", cambiaban la orientación del fraude, en pocas palabras, con la excusa de evitar un fraude éramos víctimas un fraude mayor.

La aparición de sistemas relativamente más transparentes y sencillos como los que ofrece Google Adsense, obligó un cambio de técnica de aquellas empresas de "adserving" que especulaban amparadas en la gran oferta de sitios y baja demanda de espacios. Un gran porcentaje de sitios empezó a pensar nuevamente en la opción de ajustar sus ingresos mediante la publicidad gracias a Google Adsense y la oferta de espacio para este tipo de empresas disminuyó radicalmente.

Gracias a Google Adwords y Adsense, además de otros que sería injusto no mencionar como Overture, la publicidad en la Web está viviendo una nueva etapa, más segura y eficiente y mucho más controlada. Pero sin embargo algo oscuro aparece en el horizonte de la publicidad online: ¡El fantasma del "Pay per Action" vuelve a aparecer!

Esta creciente oferta de pago de publicidad mediante el sistema denominado "Pay per Action" empieza a hacerse presente y cambiar las políticas del juego inclusive en el mismo Google Adsense.

Para aclarar el término, "Pay per Action" (PPA) o pago por acción, es aquel que sistema que te permite cobrar solamente si el usuario que llevas mediante publicidad a otro sitio completa o lleva a buen término una acción determinada, como por ejemplo llenar un formulario de registro, comprar un artículo y otras tantas acciones que se pueden realizar en un web, y que en su mayoría están todas relacionadas con obtener beneficios directos.

No parece ser nada preocupante ¿Cierto? Inclusive se pueden ganar altas cifras si se lleva a un usuario a comprar un vuelo a Madrid o utilizar servicios de Telefonía VoIP. Entonces: ¿Donde está la trampa?

En realidad no hay trampa como tal, sin embargo se trata de dejar de vender publicidad para vender productos y servicios específicos. Si existe algo que haya mantenido en la carrera por los grandes montos de publicidad que anualmente se reparten en el mercado publicitarios, este "algo" ha sido la capacidad de entender las limitaciones de las respectivas tecnologías y alcances de dichos medios (radio, tv, prensa) y no involucrar al medio en si mismo para nada en la acción de vender el producto o servicio. Estos llevan al cliente "a la puerta" del establecimiento o empresa ofertante, pero son estos últimos los encargado de cerrar la venta.

En Internet pareciera que el medio nos permite llegar más allá, e interactuar en la venta del producto mismo. Eso indudablemente es cierto, sin embargo pero antes de colocar publicidad con esa modalidad de pago en su sitio, piense en los siguientes puntos:

  1. ¿Tiene el sitio de llegada (landing site) en el que se debe realizar la acción una plataforma eficiente para permitir el que dicha acción se lleven a cabo?
  2. ¿Que tan "usable" es dicho sitio?¿Que tan legible, fácil de navegar, intuitivo es dicho sitio?
  3. ¿Existe la suficiente "motivación" en el sitio para que un usuario decida llevar a cabo la acción requerida?
  4. ¿Es el producto o servicio ofrecido lo suficientemente atractivo? ¿Ha pensado en la competencia que hay para dicho producto o servicio?
  5. Sinceramente: ¿Llevaría a cabo usted mismo la acción requerida?
  6. ¿Cree usted que el producto está acorde con los gustos de sus usuarios?
  7. ¿Existe alguna otra acción que produzca beneficios a los dueños del sitio, por la que no estipulan pagarle nada y a la que probablemente se desvien los usuarios que usted envíe?
  8. ¿Tiene el sitio los controles necesarios como para asegurar que una acción realizada será pagada? ¿Son estos controles lo suficientemente transparentes como para asegurarle que sus ganancias no se vean reducidas o "reajustadas" por alguna cláusula?

En fin, como usted podrá apreciar al hacerse todas estas preguntas, muchas de ellas no podrán ser respondidas sin caer en suposiciones, por lo cual usted ya estaría jugando con desventaja.

Sin embargo las respuestas a las anteriores preguntas podrían ser suficientemente satisfactorias para usted, y en ese caso de seguro el pago ofrecido no será gran cosa. Mi experiencia me sugiere que si el pago es atractivo la mayoría de las respuestas no serán satisfactorias o simplemente dichas respuestas se basarán en supuestos no comprobados.

Recuerde antes de creer en milagros de la web que los dueños del sitio ofertante saben perfectamente y mucho mejor que usted cuantas visitas hacen faltas para llevar a cabo la acción solicitada. Recuerde también que si no se realiza ninguna acción ellos también ganan: Todos los usuarios que no compraron pudieran hacerlo en otra ocasión, y por eso usted no recibirá remuneración ninguna, y por último el sitio se da a conocer a un potencial de usuarios y de por si solo esto tiene un precio.

Siga un consejo de alguien que ya se ha llevado muchos golpes en este asunto:

Lleve todos los usuarios que quiera a un determinado sitio, pero no se involucre en lo que estos hagan una vez que dejen el suyo. Usted no puede estar en todas partes.

30 de junio de 2008

¿Que son los UGLY URLs?

Tal como su traducción simple al castellano indica los UGLY URLs son Enlaces (URLs) feos.
Indudablemente esto no ayuda mucho pero nos da una pequeña idea del tema que está sin duda radicalmente asociado con las maquinarias de búsqueda y la publicación de sitios en las mismas.

Todos conocemos de alguna manera u otra lo que significa una página web dinámica, desarrollada en cualquiera de los lenguajes o plataformas de programación para Web actuales. Sin embargo una característica importante de las páginas web dinámicas es su URL o dirección.

En la gran mayoría de los casos estas páginas poseen un URL que contiene el signo "?" a partir del cual se muestran una serie de pares de "variable=contenido" separados por un símbolo "&" (ampersand).

Pues bien el hecho es que a las maquinarias de búsqueda nunca le han gustado este tipo de enlaces, pero se han debido adaptar a los mismos debido a la creciente existencia de dicho tipos de página.

Ah pero eso si, han puesto sus condiciones (por demás razonables) para incluir este tipo de páginas en sus bases de datos. Estas condiciones se basan en la lógica simple. Pongamos un ejemplo:

Pongamos dos direcciones web ficticias (para no ofender a nadie) en la balanza:

URL 1:
http://sitio1/Data.jsp?Ciudad_ID=Nueva%20Esparta&Zona=Oriente&Estado_ID=BAR&TipoCliID=00000067

URL 2:
http://sitio2/respuesta.asp?art=1&cat=AB

A simple vista sin mucha explicación podemos ver varias diferencias.

  1. El primer URL tiene 4 parámetros (Ciudad_ID, Estado_ID, Zona, TipoCliID) mientras el segundo solo tiene 2 (art, cat).
  2. El nombre de los parámetros utilizados son más largos en el primero que en el segundo.
  3. Los contenidos asociados a cada parámetro también son más largos en el primer caso.

Para empezar las maquinarias de búsqueda solo indexan URLs con un máximo de 2 parámetros, por lo cual el primer ejemplo podría quedar fuera.

Luego si nos referimos a un largo máximo la primera opción queda descartada nuevamente en algunas maquinarias debido a que es algo larga.

Pero hay un tercer problema, quizás el más importante y tiene que ver con la utilización de las letras "ID" en los nombres de los parámetros. Las maquinarias de búsqueda odian esa pequeña combinación ya que se asocia a sistemas de "forbidden bulk summision", es decir técnicas utilizadas por viejos webmasters para colocar la mísma página un sin fin de veces en una maquinaria de búsqueda y que están actualmente prohibidas o son causa de exclusión automática de un portal determinado de los índices más importantes de la actual web.

Pues bien, podemos deducir que el primer enlace es lo que se denomina un "UGLY URL" y sus posibilidades de indexación son mínimas. El segundo al contrario es un enlace sencillo con muchas más posibilidades de aparecer en os listados.

Claro esta es solo una de las tantas características a tomar en cuenta por una maquinaria de búsqueda a la hora de indexar su sitio. Pero conocerla puede aumentar las probabilidades de acierto.

Espero les sirva de algo, y por si tiene alguna duda al respecto ya que yo no soy Dios y tienen razón en dudar, pueden visitar:

http://www.google.com/support/webmasters/bin/answer.py?answer=35769#design

Aquí podrán encontar una buena lista de razones por las cuales sus sitios pudieran no estar indexados correctamente en Google.

Hasta la próxima!

26 de junio de 2008

¿Que son los sitios MobileOK?

Los sitios MobileOk son aquellos sitios WAP creados para móviles, que cumplen con una serie de estándares básicos dictados por el W3 consortium llamados "Buenas Prácticas" mediante las cuales se asegura que un sitio creado para Web Móvil sea portable en todos aquellos dispositivos que cumplen con las normas básicas del Default Device Context (DDC) o Contexto de Dispositivo por Defecto.

Crear un sitio WAP que se atenga a estos estándares si bien es algo complejo, asegura la legibilidad y visualizacvión de nuestro sitio en prácticamente toda la gama de dispositivos móviles actuales.

Las "Mobile Best Practices" (Buenas Prácticas Móviles), pueden resumirse en cinco grupos de reglas de:
  1. Comportamiento General
  2. Navegación y enlaces
  3. Diagramación y Contenido
  4. Definición de Página
  5. Input de usuarios

Podrás encontrarlas en: http://www.w3.org/TR/2006/PR-mobile-bp-20061102/

Si te parecen muy complejas no te preocupes, simplemente usa el validador (luego de haber validado el código XHTML-MP o XHTML BASIC de tu página) ubicado en:

http://validator.w3.org/mobile/

Es muy importante a la hora de desarrollar tu sitio WAP estar seguro de que será visto sin problemas por una vasta mayoría de dispositivo, sobre todo si tomas en cuenta la gran cantidad de estos que hay y lo diferenciadas que son sus características.

Hasta la próxima.

Entradas populares