Escáneres de seguridad gratuitos arrojaron tres resultados distintos: ¿de cuál fiarnos?

La advertencia de JavaScript que encontró la segunda herramienta es probablemente un mecanismo de redirección condicional. El código malicioso no se muestra a los administradores con sesión iniciada, solo se activa para visitantes cuyo encabezado Referer sea Google. Extraigan el código de la página desde la terminal usando curl con distintos valores de User-Agent y Referer. Busquen funciones sospechosas como eval, base64_decode o document.write dentro del archivo.

Antes de entrar en pánico revise dos cosas: Primero entre al panel de Google Search Console de su sitio y mire la pestaña Problemas de seguridad; si Google detectó un peligro, lo listará claramente ahí. Segundo, determine la fecha del último respaldo limpio de su sitio web. Si el problema empezó hace unos días comparar desde la copia de respaldo es la forma más rápida.

El año pasado ignoramos una advertencia similar porque dos escáneres decían que estaba limpio. 48 horas después, el buscador bloqueó nuestro sitio con una pantalla roja. Los anuncios se detuvieron y perdimos cerca de 4.200 dólares en facturación esa semana. El informe limpio de los escáneres externos da una falsa tranquilidad, denle siempre prioridad al reporte que dice que está infectado.

Que el tercer escáner diga que hay un riesgo alto por los encabezados HTTP es una táctica típica de marketing. Muchas herramientas gratuitas exageran los encabezados de seguridad faltantes como si el servidor tuviera un virus para intentar vender su propio plugin de pago. No confunda la falta de configuración con una infección activa de malware.

edit: he corregido unas erratas.

yo q tu no ignoraría para nada la alerta de script externo. x lo general son contadores viejos olvidados en la web o pixels de chat de terceros q hackean y meten redirecciones... miren en el código fuente entre las etiquetas head, si hay un dominio raro da el cantazo de una.

¿Su sitio está basado en WordPress o es un software a medida desarrollado desde cero? Además, ¿ese archivo JavaScript sospechoso está alojado en su propio servidor o se carga desde un servidor externo? Si comparte estos dos datos será más fácil orientarle.

Para aclarar los informes contradictorios siga este orden: 1) Guarde el enlace completo del archivo de script que el segundo escáner marca como sospechoso. 2) Abra el código fuente del archivo en el servidor y revise si hay códigos de redirección extraños. 3) Compruebe la fecha de última modificación a través del FTP o el panel del servidor. 4) Deje las advertencias de certificados y encabezados de la tercera herramienta para después.

No se desanime para nada, en sitios de comercio electrónico activos suelen ocurrir falsas alarmas o pequeñas filtraciones de scripts. Si le da reparo tocar la parte del código, abra un ticket con el equipo de soporte de su empresa de hosting y envíeles el registro que dio el segundo escáner; ellos le harán un escaneo antivirus a nivel de servidor de forma gratuita.

Hace dos años viví exactamente lo mismo. Empezad con una pequeña prueba, no lo integréis todo de golpe.

También me gustaría saber si alguien lo hace de otra manera.

creo que es difícil hablar con tanta claridad sobre escaneo seguridad web gratis pero la gente no defiende el proceso, defiende la costumbre. la resistencia viene de ahí.

¿Creen que esto funciona a cualquier escala? El tiempo que tardas en detectar un problema determina directamente su coste.

Ánimo.

En su momento, nosotros también nos atascamos ahí. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Empezad con una pequeña prueba, no lo integréis todo de golpe. Esta es mi opinión, no lo escribo como una verdad absoluta.

han surgio tres opiniones distintas todas se complementan. si el permiso y el alcance no están por escrito que no empiece la prueba.

yo seguiría por ese camino.

Correcto. La respuesta varía mucho según el sector, no hay una regla general.

También me gustaría saber si alguien lo hace de otra manera.

Estoy totalmente de acuerdo. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

También me gustaría saber si alguien lo hace de otra manera.

De acuerdo, incluso me gustaría recalcarlo... La gente no defiende el proceso defiende la costumbre. en fin la resistencia viene de ahí.

Comprobado por experiencia.

Lo que voy a preguntar sonará un poco novato, perdonadme. El tiempo que tardas en detectar un problema determina directamente su coste.

Al tomar decisiones, escribe también el peor escenario, no solo el mejor. Lo dejo como nota, por si sirve.

Lo escribo para que no cometan el mismo error. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Eso es todo, disculpa si me he extendido demasiado.