En Google estamos obsesionados por la velocidad. Hemos visto una y otra vez cómo el aumento de la velocidad aparente se plasma directamente en el aumento de la satisfacción y de la implicación del usuario [inglés]. Instant Pages ayuda a los visitantes a llegar a tu sitio más rápidamente. Al poner en marcha Instant Pages para tu sitio web, los usuarios pueden comenzar a interactuar con tu sitio casi de forma inmediata, sin tener que esperar a que se carguen el texto y las imágenes. Sólo ponemos en marcha Instant Pages cuando estamos muy seguros de que tu sitio es el resultado exacto que los usuarios están buscando. El tráfico de búsqueda se medirá en las Herramientas para webmasters de Google exactamente igual que antes de introducir esta característica, de modo que sólo contarán los resultados en que el usuario haya visitado realmente el sitio. Este verano dedicaremos un tiempo a recoger vuestras opiniones antes de introducir esta característica en las versiones estables de Chrome.
La inmensa mayoría de sitios funcionarán correctamente al ser previsualizadas en Chrome. Si quieres más información sobre cómo funciona la previsualización en Chrome o sobre cómo puedes detectar que tu sitio se previsualiza, consulta la entrada sobre previsualización en el blog Chromium [inglés].
Publicado por Ziga Mahkovec, Ingeniero de software
El informe de impacto sobre la búsqueda te da una idea de cómo afectan los +1 al tráfico procedente de las búsquedas orgánicas. Puedes averiguar si tu tasa de accesos cambia al usar recomendaciones personalizadas para ayudar a destacar tu contenido. Para ello, puedes comparar los clics y las impresiones en los resultados de las búsquedas con y sin anotaciones +1. Sólo mostraremos estadísticas sobre variaciones en la tasa de acceso cuando haya impresiones suficientes como para realizar una comparación significativa.
El informe de actividad muestra cuántas veces se ha hecho +1 en tus páginas, desde botones situados en tu sitio web y en otras páginas (como en la búsqueda de Google).
Finalmente, el informe de audiencia muestra datos agregados geográficos y demográficos sobre los usuarios de Google que han hecho +1 en tus páginas. Para proteger la privacidad, sólo damos información sobre audiencia cuando hay un número significativo de usuarios que han hecho +1 en páginas de tu sitio.
El menú Métricas +1 del lado izquierdo de la página te permite acceder a estos informes. Si todavía no has verificado tu sitio web en las Herramientas para webmasters de Google, puedes seguir estas instrucciones para acceder.
Finalmente, también puedes ver cómo comparten los usuarios tu contenido usando otros botones aparte del botón +1, usando el seguimiento del Social Plug-in en Google Analytics [inglés]. Una vez configurado JavaScript para Analytics, el informe de implicación social te ayudará a comparar los distintos tipos de acciones de compartición que se producen en tus páginas.
El informe de implicación social te permite saber cómo cambia el comportamiento de tu sitio debido a las visitas que incluyen clics en botones +1 u otras acciones de tipo social. Esto te permite, por ejemplo, determinar si la gente que hace +1 en tus páginas durante una visita pasa más tiempo en tu sitio que la gente que no lo hace.
El informe de acciones sociales te permite realizar un seguimiento del número de acciones sociales (clics en +1, tweets, etc.) realizadas en tu sitio, todo desde un mismo lugar.
El informe de páginas sociales te permite comparar las páginas de tu sitio para ver cuáles impulsan el mayor número de acciones de tipo social.
Si usas la versión predeterminada del código más reciente de seguimiento de Google Analytics, al añadir botones +1 a tu sitio [inglés] automáticamente activamos el seguimiento del Social Plug-in para botones +1 en tu cuenta. Puedes habilitar el seguimiento de otros plug-ins [inglés] de carácter social en tan sólo unos simples pasos.
Los informes de actividad social son sólo el principio. A medida que la gente encuentra nuevas formas de interacción en la web, buscamos nuevos tipos de informes que ayuden a los propietarios de los negocios a entender el valor que las acciones sociales tienen sobre su actividad de negocio. Así que, ya sabéis: ¡+1 de utilidad para vuestros datos!
Hoy os mostraremos algunos ejemplos de cómo se puede atacar una aplicación web, para que puedas aprender de ello. Con este fin, usaremos Gruyere, una aplicación intencionadamente vulnerable que también usamos internamente para formación sobre seguridad. No pruebes la vulnerabilidad de los sitios web de otras personas sin su permiso, puesto que podría considerarse un ataque (hacking), pero te damos la bienvenida (e incluso te animamos) a hacer pruebas en Gruyere.
Manipulación del estado del cliente (Client State): ¿qué sucede si altero la URL?
Imaginemos que tienes un sitio de alojamiento de imágenes y que usas una secuencia de comandos en PHP para mostrar las imágenes subidas por los usuarios.
Otro ejemplo de manipulación de estado del cliente se produce cuando no se validan los campos de los formularios. Por ejemplo, imaginemos que tienes este formulario:
Parece que el nombre de usuario del remitente se almacena en un campo oculto. Bueno, ¡esto es genial! ¿Significa que si cambio el valor de ese campo por el de otro nombre de usuario puedo enviar el formulario como si fuese ese otro usuario? Bien podría suceder. Aparentemente, los datos introducidos por el usuario no se autentican con, por ejemplo, ningún token que se pueda verificar en el servidor.
Imagina la situación si ese formulario formase parte de un carrito de la compra y modificásemos el precio de un artículo de 1000 USD por 1 USD para, después, enviar el pedido.
Proteger tu aplicación frente a este tipo de ataques no es fácil. Echa un vistazo a la tercera parte de Gruyere [inglés] para ver algunos consejos sobre cómo defender tu aplicación.
Cross-site scripting (XSS): los datos introducidos por el usuario no son de fiar
Una URL simple e inofensiva: http://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3E
¿Es realmente inofensiva? Si descodificamos los caracteres codificados con el signo de porcentaje, obtenemos:
<script>alert('0wn3d')</script>
Al igual que muchos sitios web con páginas de error personalizadas, Gruyere está diseñada para incluir el componente de la ruta dentro de la página HTML. Esto puede generar problemas de seguridad, como XSS, puesto que introduce el código introducido por el usuario tal como está en la página HTML de la aplicación web. Podríamos pensar, "bueno, es solo un cuadro de advertencia, ¿y qué?". El problema es que si puedes inyectar un cuadro de advertencia, puedes, con toda probabilidad, inyectar otra cosa, también, y tal vez aprovechar para robarte las cookies y usarlas para acceder a tu sitio como si fueses tú.
Otro ejemplo es cuando no se limpian las entradas del usuario. Imaginemos que escribo un comentario en tu blog. Se trata de un comentario muy simple:
<a href=”javascript:alert(‘0wn3d’)”>Click here tos see a kitten</a>
Si otros usuarios hacen clic en mi inocente enlace, tendré sus cookies:
Puedes ver cómo resolver las vulnerabilidades por XSS en tu propia aplicación web e intentar resolverlas en la segunda parte de Gruyere [inglés] o, si eres un desarrollador avanzado, mirar las características sobre escapado automático en sistemas con plantillas de la que hablamos en nuestro blog sobre seguridad online [inglés].
Falsificación de petición en sitios cruzados (XSRF): ¿debería aceptar las solicitudes procedentes de diablos.com?
Oh, vaya, una imagen rota. No puede ser peligrosa: está rota, al fin y al cabo, lo cual significa que la URL de la imagen devuelve un código 404 o tiene un formato incorrecto. ¿Pero es siempre así?
¡No! La fuente de una imagen se puede especificar con cualquier URL, sea cual sea su tipo de contenido. Puede ser una página HTML, un archivo JavaScript, u otro recurso potencialmente malicioso. En este caso, la fuente es la URL de una simple página:
Esta página sólo funcionará si tengo una sesión iniciada y algunas cookies asignadas. Puesto que realmente tenía una sesión iniciada en la aplicación, cuando el navegador ha intentado recuperar la imagen accediendo a la URL de fuente, también ha eliminado mi primer fragmento. Esto no suena particularmente peligroso, pero si conozco un poco la aplicación también podría invocar una URL que elimine el perfil de un usuario o permita a un administrador otorgar permisos a otros usuarios.
Para proteger tu aplicación de XSRF no deberías permitir nunca que las acciones de cambio se soliciten vía GET. El método POST se inventó para este tipo de peticiones de cambio de estado. Este cambio por si solo podría mitigar el ataque anterior, pero por lo general no basta y es necesario añadir algún valor impredecible a todas las solicitudes que supongan un cambio de estado para prevenir las acciones de XSRF. Si quieres más información sobre XSRF puedes ir directamente a Gruyere [inglés].
Inclusión de Cross-site script (XSSI): todas tus secuencias de comandos nos pertenecen
En muchos sitios es posible actualizar dinámicamente el contenido de una página mediante peticiones de JavaScript asincrónicas que devuelven datos JSON. A veces JSON puede contener datos sensibles que, si no se toman las precauciones debidas, un hacker podría robar.
Imaginemos la situación siguiente: hemos creado una páginas HTML estándar y te enviamos el enlace. Puesto que confías en nosotros, visitas el enlace que te hemos enviado. La página contiene tan solo unas cuantas líneas:
<script>function _feed(s) {alert("Your private snippet is: " + s['private_snippet']);}</script>
Puesto que has iniciado sesión en Gruyere y dispones de un fragmento privado, verás un cuadro de alerta en mi página que te informa sobre el contenido de tu fragmento. Como siempre, si nos las hemos arreglado para abrir un cuadro de alerta, podremos hacer lo que queramos. En este caso se trata de un simple fragmento, pero también podría haber sido tu mayor secreto.
Defender a una aplicación frente a XSSI no es demasiado difícil, pero exige pensar con cuidado. Puedes usar tokens, tal como se explica en la sección sobre XSRF, hacer que tu secuencia de comandos solo responda a peticiones POST o simplemente iniciar la respuesta JSON por "\n" para asegurarte de que la respuesta no es ejecutable.
Inyección de SQL: ¿todavía crees que lo que introducen los usuarios es seguro?
Qué sucedería si intento acceder a tu aplicación con un nombre de usuario como
MarioMartinez' ; DROP TABLE members;--
Aunque este ejemplo en particular no dejaría expuestos los datos de los usuarios, podría provocar grandes quebraderos de cabeza porque tiene la capacidad de eliminar por completo la tabla de SQL en la cual tu aplicación almacena los datos de los miembros registrados.
Por lo general, puedes proteger a tu sitio web de la inyección de código SQL pensando proactivamente sobre la introducción de datos de los usuarios En primer lugar: ¿estás seguro de que tu usuario de SQL necesita disponer de permiso para ejecutar "DROP TABLE members"? ¿No bastaría con concederle derechos de SELECT? Asignando los permisos de los usuarios cuidadosamente puedes evitar experiencias dolorosas y un montón de problemas. También puede ser útil configurar los informes de error de tal modo que no queden expuestos los nombres de las bases de datos ni de las tablas en caso de que una consulta falle.
En segundo lugar, tal como hemos aprendido en el caso XSS, los datos introducidos por el usuario no son nunca de fiar. Lo que para ti parece un formulario de inicio de sesión, es una posible puerta de acceso para un atacante. Limpia y verifica siempre la estructura de la información de entrada que se vaya a almacenar en una base de datos y, siempre que sea posible, usa instrucciones del tipo de consultas preparadas o parametrizadas, disponibles en la mayoría de las interfaces de programación de bases de datos.
Sabiendo cómo es posible atacar una aplicación web es el primer paso para entender cómo protegerla. Por este motivo, te animamos a que sigas el curso de Gruyere [inglés], aproveches otros cursos sobre seguridad web disponibles en la Google Code University [inglés]. También puedes probar Skipfish [inglés], una herramienta de prueba automática de la seguridad. Si tienes alguna pregunta más, no dudes en enviarla a nuestro Foro de ayuda para webmasters.
Publicado por Gary Illyes, Analista de tendencias para webmasters
Un ejemplo de fragmento enriquecido: un resultado de búsqueda mejorado con marcado estructurado. En este caso, el fragmento enriquecido contiene una imagen, opiniones y tiempo de cocción de una receta.
Estos elementos han sido adoptados rápidamente por la comunidad de webmasters y hoy día podemos mostrar fragmentos enriquecidos en las búsquedas más de diez veces más a menudo que cuando comenzamos hace dos años.
Queremos continuar haciendo que la Web abierta sea más rica y útil. Sabemos que añadir estas marcas a las páginas cuesta tiempo y esfuerzo y que añadir marcas es mucho más difícil cuando cada motor de búsqueda pide datos distintos y de formas distintas. Por este motivo nos hemos unido con otros motores de búsqueda, con el fin de poder utilizar un estándar común de Sitemaps [inglés] en 2006. Con schema.org, los propietarios de los sitios pueden mejorar la forma en que sus sitios aparecen en los resultados de las búsquedas, no solo en Google, sino también en Bing, Yahoo! y, potencialmente, otros motores de búsqueda en el futuro.
Ahora vamos a analizar algunos aspectos de Schema.org relevantes para ti como webmaster:
1) Schema.org contiene muchos nuevos tipos de marcas.
Hemos añadido más de 100 nuevos tipos y trasladado todos los tipos de fragmentos enriquecidos existentes. Si has pensado en añadir marcas para fragmentos enriquecidos con anterioridad pero ninguno de los tipos existentes parecía relevante para tu sitio, vale la pena volver a mirarlo. Aquí tienes algunos tipos populares:
También puedes ver la lista completa de todos los tipos de esquemas de schema.org [inglés]. Los nuevos tipos de marcas se podrán usar en el futuro para dar formato a los fragmentos enriquecidos así como para otros tipos de mejoras destinadas a ayudar a la gente a encontrar lo que buscan más fácilmente.
2) Schema.org usa microdatos.
Históricamente, hemos empleado tres estándares distintos para el etiquetado de datos estructurados: microdatos, microformatos y RDF. Hemos decidido centrarnos en un único formato para schema.org con el fin de facilitar la labor de los webmasters y mejorar la consistencia entre los motores de búsqueda que trabajan a partir de los datos. Existen argumentos para preferir cualquiera de los estándares existentes, pero creemos que los microdatos ofrecen el equilibrio entre la posibilidad de ampliación de RDF y la sencillez de los microformatos, así que éste es el formato por el que hemos optado.
Para obtener información sobre los microdatos y las convenciones que se siguen en schema.org, consulta la Guía de inicio de schema.org [inglés].
3) Continuaremos admitiendo nuestros formatos existentes de etiquetado de fragmentos enriquecidos.
Si ya has trabajado en el etiquetado de tus páginas usando microformatos o RDF, continuaremos empleándolo. No obstante, hay un inconveniente: aunque se pueda usar el nuevo esquema de etiquetado o continuar usando los microformatos o RDF existentes, se debe evitar mezclar distintos formatos en una misma página web, porque esto podría confundir a nuestros analizadores.
4) Prueba las marcas usando la herramienta de pruebas de fragmentos enriquecidos.
Resulta muy útil probar las páginas web etiquetadas para comprobar que el análisis de los datos correspondientes se haga correctamente. Al igual que con los formatos de etiquetado de fragmentos enriquecidos anteriores, para ello se debe usar la herramienta de pruebas de fragmentos enriquecidos. Ten en cuenta que la herramienta de pruebas mostrará la información etiquetada que se ha podido extraer del análisis de la página, pero la vista previa de fragmentos etiquetados con las etiquetas de schema.org todavía no está disponible. Esta funcionalidad se añadirá en breve.
El sitio web de schema.org y la herramienta de pruebas de los fragmentos enriquecidos están escritos en inglés. No obstante, Google muestra los fragmentos enriquecidos en los resultados de las búsquedas globalmente, así que no es necesario esperar a comenzar a etiquetar páginas.
