He estado obteniendo algunos 404 con fragmentos de código (CSS, HTML y JavaScript) en la URL.HTML y CSS en URL que causan errores 404 (agente de usuario = Trident/4.0)
Como mejor que puedo decir que el usuario está progresando a través del sitio bien durante su sesión - Es un sitio de comercio electrónico y los usuarios afectados están poniendo las cosas en su cesta y la salida a OK etc.
En ciertas páginas Veo errores 404 adyacentes a una pantalla de página aparentemente exitosa. Obtengo el mismo error 404 cada vez que se muestra esa página (dentro de esa sesión).
Ejemplo de un error registrado 404:
404;http://www.example.com/rrepeat: repeat-y;
Hay una sola instancia correspondiente en la página en cuestión (aparte de la primera "r"):
<td style="background-image: url(/i/lb_ccccccbrd.gif); background-repeat: repeat-y;">
He comprobado los archivos CSS incluidos y ninguno tiene coincidencias (y presumiblemente si lo hicieran obtendría un 404 en todas las páginas que incluyen el archivo CSS)
Mi idea era que quizás es un PlugIn para IE8 que es sp idering la página mientras el usuario la está viendo para almacenar algo en caché, o posiblemente para fines más malévolos. El agente de usuario para las páginas y el 404 (dentro de esa sesión) es el mismo [no sé si un plugin mostraría diferente al propio navegador?]
Otros ejemplos:
/r/table></form></td><td width=
/r width=
/r alt=
/rurn pair[1]; --></SPAN> --></SPAN>--></SPAN>function Set_Cookie(name, value, expires, path, domain, secure) <SPAN style="color:red;font-weight:bold;background-color:yellow;"><!--/ set time, it's in millisecondsvar today = new Date();today.setTime(today.getTime());/*if the expires variable is set, make the correct expires time, the current script below will set it for x number of days, to make it for hours, delete * 24, for minutes, delete * 60 * 24if (expires)<SPAN style="color:red;font-weight:bold;background-color:yellow;"><!--expires = expires * 1000 * 60 * 60 * 24;--></SPAN>*/expires = (3650) * 1000 * 60 * 60 * 24;var expires_date = new Date(today.getTime() + (expires));document.cookie = name +
Todos parecen para comenzar con una "r" que no es parte del código, luego un fragmento directo del código de la página.
La página pasa la validación w3c.org HTML (así que no creo que es, digamos, una cotización unlcosed, a menos que tenga algo de JavaScript torpe romper el código HTML !!)
agente de usuario es siempre MSIE 8.0 o MSIE 7.0 y Trident/4.0. (Supongo que el MSIE 7.0 con Trident es IE8 en modo compatible)
Solo veo unas instancias de esto al día (menos de 10 sesiones), mientras que recibo cientos de sesiones al día con User Agent, incluido IE8 y Tridente.
Gracias.
Lo sentimos, el ejemplo HTML que di consiguió tragado: "Hay una sola instancia correspondiente en la página en cuestión (aparte de la primera 'r'): estilo
Respuesta
Me parece que estás tratando con una araña mal formada o con un intento de ataque XSS.
Si está sucediendo a pequeña escala, lo mejor es asegurarse de que ha bloqueado su aplicación/sitio para que dichos ataques no tengan éxito.
Vigile sus registros. Si cosas como esta recogen en frecuencia y/o cambian sus vectores de ataque, será mejor que sepas hacia dónde se dirigen esos esfuerzos y respondan en consecuencia.
Por último, el identificador de cliente "IE8/Trident" no es nada especial. Simplemente indica que el cliente dice que están ejecutando Internet Explorer 8 usando el motor de diseño Trident (similar a Safari/WebKit o Mozilla/Gecko).
Fuente
2009-10-04 16:41:41
Gracias por su respuesta No creo que sea un ataque de araña/XSS, a menos que sea algo que haya infectado el navegador del usuario. Recibo 10 usuarios por día comprando cosas con tarjetas de crédito, y en su sesión (es decir, los errores 404 tienen la misma cookie de sesión, etc.) también estoy viendo estos errores tontos 404. Así que definitivamente son usuarios reales. Mencioné IE8/Trident como todos los 404 de este tipo tiene ese User Agent, por lo que parece ser algo relacionado específicamente con ese explorador – Kristen
¿Está utilizando algún tipo de interacción compleja de JavaScript (AJAX, formularios Flash, etc.)? Podría ser que los scripts que ejecuta en el lado del cliente se descompongan en IE8 y contaminar las variables post/get con HTML desde cualquier lugar de su aplicación. –
Tenemos Javascript, pero es bastante liviano Sin AJAX, sin formularios Flash. Echaré un vistazo a las páginas en la misma sesión que no informan ningún error para ver si puedo detectar una diferencia. La página en sí se está cargando, así que no creo que haya un problema POST/GET (el solo hecho de ver la página de inicio crea el 404, antes de que el usuario POSTRE cualquier cosa), lo que veo es un archivo adicional solicitud. Así que creo que cualquier corrupción tendría que estar en una etiqueta IMG o algo así. También veré los registros de todos los archivos HTML/CSS/IMG y veré en qué parte de la secuencia se encuentra el 404 – Kristen
Tuve el mismo problema. En los navegadores Trident 4.0, la aplicación comenzaría repentinamente a referirse a scripts js extraños, es decir
Esto no afectaría la experiencia del usuario, ya que el sitio web aún se mostraría bien. Pude rastrear el problema y volver a ejecutarlo en mi servidor local con el mismo error, lo que me hizo pensar que no es un ataque XSS.
Realicé algunas pruebas y resultó que el problema era que la aplicación intentaba incluir demasiados archivos js - cuando reduje ese número, el problema se detenía.
No pude encontrar ninguna información, si es un límite introducido por el motor de diseño Trident, pero recuerdo que IE solía tener límites en la cantidad de clases de CSS que puede usar en cada página, así que eso es algo para hacer con Microsoft tratando de burlar a todos.
Fuente
2010-03-16 15:16:50
(Trident/4.0 es lo que identifica IE 8, incluso si el User-Agent dice IE 7, que es IE 8 ejecutándose en modo compatibilidad.) IE 8's Lookahead Downloader tiene una peculiaridad que afecta las URL que abarcan cualquier 4096th byte. La url resultante generada es una concatenación de la cadena inmediatamente anterior al corte y la cadena inmediatamente posterior. Parece tratar cualquier comilla simple o doble como delimitadores. si usas XHTML, no hay una forma práctica de evitar obtener estos errores 404 de los usuarios de IE 8.
Fuente
2011-03-17 16:24:24 Slinky
Cuestiones relacionadas