{"id":84184,"date":"2020-06-05T19:42:31","date_gmt":"2020-06-05T17:42:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god"},"modified":"2020-06-05T19:42:31","modified_gmt":"2020-06-05T17:42:31","slug":"smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","title":{"rendered":"Pecados mortales de la seguridad del sitio: lo que aprendimos de la estad\u00edstica del esc\u00e1ner de vulnerabilidades durante un a\u00f1o","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hace aproximadamente un a\u00f1o, en DataLine lanzamos servicio<\/a><\/noindex> un servicio para buscar y analizar vulnerabilidades en aplicaciones de TI. La base del servicio es la soluci\u00f3n en la nube Qualys, sobre la que ya hemos hablado<\/a><\/noindex>. En un a\u00f1o de trabajo con esta soluci\u00f3n, realizamos 291 escaneos para diferentes sitios y acumulamos estad\u00edsticas sobre las vulnerabilidades comunes en aplicaciones web.\u00a0<\/p>\n

En el art\u00edculo a continuaci\u00f3n, mostrar\u00e9 qu\u00e9 agujeros de seguridad en los sitios se ocultan detr\u00e1s de diferentes niveles de criticidad. Veremos qu\u00e9 vulnerabilidades encontr\u00f3 el esc\u00e1ner con mayor frecuencia, por qu\u00e9 pueden surgir y c\u00f3mo protegerse.\u00a0<\/p>\n

\"Pecados
\n<\/a><\/noindex>
\nQualys clasifica todas las vulnerabilidades de las aplicaciones web en tres niveles de criticidad: bajo, medio y alto. Si miramos la distribuci\u00f3n por \u2018gravedad\u2019, parece que no est\u00e1 tan mal. Hay pocas vulnerabilidades de alta criticidad, la mayor\u00eda son no cr\u00edticas:\u00a0<\/p>\n

\"Pecados
\n
\nPero no cr\u00edticas no significa inofensivas. Tambi\u00e9n pueden causar da\u00f1os graves.\u00a0<\/p>\n

Las principales vulnerabilidades 'no cr\u00edticas'<\/h2>\n

<\/p>\n

    \n
  1. Vulnerabilidades relacionadas con contenido mixto.<\/b>\n

    El est\u00e1ndar de seguridad de los sitios es la transmisi\u00f3n de datos entre el cliente y el servidor a trav\u00e9s del protocolo HTTPS, que admite cifrado y protege la informaci\u00f3n contra interceptaci\u00f3n.\u00a0<\/p>\n

    Algunos sitios utilizan contenido mixto<\/i>: env\u00edan parte de los datos a trav\u00e9s del protocolo HTTP no seguro. Con mayor frecuencia se transmite contenido pasivo<\/i> \u2013 informaci\u00f3n que solo afecta la visualizaci\u00f3n del sitio: im\u00e1genes, estilos css. Pero a veces tambi\u00e9n se transmite contenido activo<\/i>: scripts que controlan el comportamiento del sitio. En este caso, utilizando software especializado, es posible analizar la informaci\u00f3n enviada desde el servidor con contenido activo, modificar las respuestas sobre la marcha y hacer que la m\u00e1quina funcione de una manera diferente a la prevista por sus creadores.\u00a0<\/p>\n

    Los navegadores de las nuevas versiones advierten a los usuarios que los sitios con contenido mixto no son seguros y bloquean el contenido. Los desarrolladores de sitios tambi\u00e9n reciben advertencias del navegador en la consola. Por ejemplo, as\u00ed es como se ve en Firefox<\/a><\/noindex>:\u00a0<\/p>\n

    \"Pecados
    \n
    \nLo peligroso es<\/b>: los atacantes utilizan el protocolo no seguro para interceptar la informaci\u00f3n del usuario, reemplazar scripts y enviar solicitudes al sitio en su nombre. Incluso si el visitante del sitio no ingres\u00f3 datos, esto no lo protege de phishing <\/i>\u2013 extracci\u00f3n de informaci\u00f3n confidencial mediante m\u00e9todos fraudulentos. Por ejemplo, mediante un script se puede redirigir al usuario a un sitio inseguro que se hace pasar por uno conocido. En algunos casos, el sitio malicioso puede parecer incluso mejor que el original, y el usuario puede completar el formulario y enviar informaci\u00f3n confidencial por su propia cuenta.\u00a0<\/p>\n

    Lo que un desarrollador web debe recordar<\/b>: Incluso si el administrador del sitio ha instalado y configurado un certificado SSL\/TLS, puede surgir una vulnerabilidad debido al factor humano. Por ejemplo, si en alguna de las p\u00e1ginas se estableci\u00f3 un enlace absoluto con http en lugar de uno relativo, y adem\u00e1s no se configuraron redirecciones de http a https.\u00a0<\/p>\n

    Se puede detectar contenido mixto en el sitio utilizando el navegador: buscando en el c\u00f3digo fuente de la p\u00e1gina, revisando las notificaciones en la consola del desarrollador. Sin embargo, el desarrollador tendr\u00e1 que hurgar en el c\u00f3digo durante mucho tiempo y con esfuerzo. Este proceso se puede acelerar con herramientas de an\u00e1lisis automatizadas, como: SSL Check<\/a><\/noindex>, el software gratuito Lighthouse o el software de pago Screaming Frog SEO Spider.<\/p>\n

    Tambi\u00e9n puede surgir una vulnerabilidad debido a problemas con el c\u00f3digo heredado, es decir, el c\u00f3digo que ha sido heredado. Por ejemplo, si algunas p\u00e1ginas se generan a partir de una plantilla antigua que no tiene en cuenta la transici\u00f3n de los sitios a https.\u00a0\u00a0\u00a0\u00a0\n<\/li>\n

  2. Cookies sin las banderas 'HTTPOnly' y 'secure'.<\/b>\n

    El atributo 'HTTPOnly' protege los archivos de cookies contra el procesamiento por scripts que los atacantes utilizan para robar datos de usuarios. La bandera 'secure' no permite la transmisi\u00f3n de cookies en texto plano. El intercambio de datos estar\u00e1 permitido \u00fanicamente si se utiliza el protocolo seguro HTTPS para enviar las cookies.\u00a0<\/p>\n

    Ambos atributos se configuran en las propiedades de las cookies:<\/p>\n

    Set-Cookie: Secure; HttpOnly<\/code><\/pre>\n
    \nLo peligroso es<\/b>: Si el desarrollador del sitio no especifica estos atributos, un atacante puede interceptar la informaci\u00f3n del usuario de las cookies y aprovecharse de ella. Si las cookies se utilizan para autenticaci\u00f3n y autorizaci\u00f3n, podr\u00e1 secuestrar la sesi\u00f3n del usuario y realizar acciones en el sitio en su nombre.\u00a0<\/p>\n
    Lo que un desarrollador web debe recordar<\/b>: Como regla general, en los frameworks populares, estos atributos se configuran autom\u00e1ticamente. Pero a\u00fan as\u00ed, verifica la configuraci\u00f3n del servidor web y establece la bandera: Set-Cookie HttpOnly; Secure. <\/p>\n
    Ten en cuenta que el atributo 'HTTPOnly' har\u00e1 que las cookies sean invisibles incluso para tu propio JavaScript.\u00a0\u00a0\n<\/li>\n
  3. Vulnerabilidades basadas en rutas.<\/b>\n
    El esc\u00e1ner informa sobre esta vulnerabilidad si detecta archivos o directorios del sitio accesibles p\u00fablicamente que contienen informaci\u00f3n potencialmente confidencial. Por ejemplo, puede encontrar archivos individuales con la configuraci\u00f3n del sistema o el acceso completo a la estructura de archivos. Esta situaci\u00f3n puede ocurrir si los permisos de acceso en el sitio est\u00e1n configurados incorrectamente.<\/p>\n
    Lo peligroso es<\/b>: Si el sistema de archivos \"est\u00e1 expuesto\", un atacante puede ingresar a la interfaz del sistema operativo e intentar encontrar carpetas con contrase\u00f1as, si se almacenan en texto claro (\u00a1no debe hacerse!). Tambi\u00e9n puede robar los hashes de las contrase\u00f1as y probar combinaciones para adivinar la contrase\u00f1a, as\u00ed como intentar elevar privilegios en el sistema y avanzar profundamente en la infraestructura.\u00a0\u00a0<\/p>\n
    Lo que un desarrollador web debe recordar<\/b>: No olvide sobre los permisos de acceso y configure la plataforma, el servidor web y la aplicaci\u00f3n web para que no se pueda \"escapar\" del directorio web.\n<\/li>\n
  4. Formularios para ingresar datos confidenciales con la funci\u00f3n de autocompletar activada.<\/b>\n
    Si un usuario a menudo llena formularios en sitios, su navegador guarda esta informaci\u00f3n mediante la funci\u00f3n de autocompletar.\u00a0<\/p>\n
    Los formularios en los sitios pueden incluir campos con informaci\u00f3n confidencial, como contrase\u00f1as o n\u00fameros de tarjetas de cr\u00e9dito. Para tales campos, es recomendable desactivar la funci\u00f3n de autocompletar en el sitio mismo.\u00a0<\/p>\n
    Lo peligroso es<\/b>: Si el navegador del usuario guarda informaci\u00f3n confidencial, un atacante puede interceptarla m\u00e1s tarde, por ejemplo, mediante phishing. En esencia, el desarrollador web que olvida este matiz est\u00e1 poniendo en riesgo a sus usuarios.\u00a0<\/p>\n
    Lo que un desarrollador web debe recordar<\/b>: En este caso, tenemos un cl\u00e1sico conflicto: comodidad vs seguridad. Si el desarrollador web piensa en la comodidad del usuario, puede optar conscientemente por la autocompletar. Por ejemplo, si es importante seguir Las Directrices de Accesibilidad para el Contenido Web<\/a><\/noindex> \u2013 recomendaciones para la accesibilidad del contenido a usuarios con discapacidades.\u00a0<\/p>\n
    Para la mayor\u00eda de los navegadores, se puede desactivar la autocompletar utilizando el atributo autocompete=\"off\", por ejemplo:<\/p>\n
    \u00a0<body>\n    <form action="\/es\/form\/submit\/" method="get" autocomplete="off" data-trp-original-action="\/form\/submit">\n      <div>\n        <input type="text" placeholder="Nombre">\n      <\/div>\n      <div>\n        <input type="text" id="lname" placeholder="Apellido" autocomplete="on">\n      <\/div>\n      <div>\n        <input type="number" placeholder="Número de tarjeta de crédito">\n      <\/div>\n      <input type="submit">\n    <input type="hidden" name="trp-form-language" value="es"\/><\/form>\n  <\/body><\/code><\/pre>\n
    \nPero no funcionar\u00e1 para Chrome. Esto se evita usando JavaScript, se puede encontrar una variante de la receta aqu\u00ed<\/a><\/noindex>.\u00a0\n<\/li>\n
  5. En el c\u00f3digo del sitio no se ha especificado la cabecera X-Frame-Options.\u00a0<\/b>\n
    Este encabezado afecta a las etiquetas frame, iframe, embed u object. Con \u00e9l se puede prohibir completamente incrustar su sitio dentro de un marco. Para ello, debe especificar el valor X-Frame-Options: deny. O puede especificar X-Frame-Options: sameorigin, lo que permite la incrustaci\u00f3n en iframe solo en su dominio.<\/p>\n
    Lo peligroso es<\/b>: La ausencia de dicho encabezado puede ser utilizada en sitios maliciosos para clickjacking<\/i>. Para tal ataque, el atacante crea un marco transparente sobre los botones y enga\u00f1a al usuario. Por ejemplo: los estafadores colocan el marco en el sitio de p\u00e1ginas de redes sociales. El usuario piensa que est\u00e1 haciendo clic en un bot\u00f3n en ese sitio. En lugar de eso, el clic es interceptado y env\u00eda la solicitud del usuario a la red social donde hay una sesi\u00f3n activa. De esta forma, los atacantes env\u00edan spam en nombre del usuario o aumentan seguidores y me gusta.\u00a0<\/p>\n
    Si no se proh\u00edbe tal posibilidad, un atacante puede colocar el bot\u00f3n de su aplicaci\u00f3n en un sitio malicioso. Puede estar interesado en su programa de referidos o en sus usuarios.\u00a0\u00a0<\/p>\n
    Lo que un desarrollador web debe recordar<\/b>: La vulnerabilidad puede aparecer si X-Frame-Options con un valor conflictivo est\u00e1 establecido en el servidor web o en el balanceador de carga. En este caso, el servidor y el balanceador sobreescribir\u00e1n el encabezado, ya que tienen una prioridad m\u00e1s alta en comparaci\u00f3n con el c\u00f3digo del backend.\u00a0\u00a0<\/p>\n
    Los valores deny y sameorigin del encabezado X-Frame-Options interferir\u00e1n con el funcionamiento del webvisor de Yandex. Para permitir el uso de iframe para el webvisor, es necesario escribir una regla separada en la configuraci\u00f3n. Por ejemplo, para nginx se puede configurar as\u00ed:<\/p>\n
    http{\n...\n map $http_referer $frame_options {\n \"~webvisor.com\" \"ALLOW-FROM http:\/\/webvisor.com\";\n default \"SAMEORIGIN\";\n }\n add_header X-Frame-Options $frame_options;\n...\n}\n\n<\/code><\/pre>\n
    \n<\/li>\n
  6. Vulnerabilidades PRSSI (Importaci\u00f3n de estilos relativos a la ruta).\u00a0\u00a0<\/b>\n
    Esta es una vulnerabilidad en los estilos del sitio web. Ocurre si se utilizan enlaces relativos como href=\"\/somefolder\/styles.css\/\" para acceder a los archivos de estilo. Un atacante aprovechar\u00e1 esto si encuentra una manera de redirigir al usuario a una p\u00e1gina maliciosa. La p\u00e1gina insertar\u00e1 el enlace relativo en su URL e imitar\u00e1 la solicitud a los estilos. Esto generar\u00e1 una solicitud similar a badsite.ru\/...\/somefolder\/styles.css\/, que bajo la apariencia de un estilo podr\u00eda realizar acciones maliciosas.\u00a0<\/p>\n
    Lo peligroso es<\/b>: Un estafador puede aprovechar esta vulnerabilidad si encuentra otro fallo de seguridad. Como resultado, podr\u00eda robar datos de usuario de las cookies o tokens.<\/p>\n
    Lo que un desarrollador web debe recordar<\/b>: Establezca el encabezado X-Content-Type-Options: nosniff. En este caso, el navegador verificar\u00e1 el tipo de contenido para los estilos. Si el tipo es diferente de text\/css, el navegador bloquear\u00e1 la solicitud.\n<\/li>\n<\/ol>\n
    <\/p>\n
    Vulnerabilidades cr\u00edticas<\/h2>\n
    <\/p>\n
      \n
    1. La p\u00e1gina con el campo de contrase\u00f1a se sirve desde el servidor a trav\u00e9s de un canal no seguro (HTML form containing password field(s) is served over HTTP).<\/b>\n
      La respuesta del servidor a trav\u00e9s de un canal no cifrado es vulnerable a ataques de tipo 'Man in the middle'. Un delincuente puede interceptar el tr\u00e1fico e infiltrarse entre el cliente y el servidor cuando la p\u00e1gina va del servidor al cliente.\u00a0<\/p>\n
      Lo peligroso es<\/b>: Un estafador podr\u00eda reemplazar la p\u00e1gina y enviar al usuario un formulario para datos confidenciales, que se enviar\u00edan al servidor del delincuente.\u00a0<\/p>\n
      Lo que un desarrollador web debe recordar<\/b>: Algunos sitios env\u00edan a los usuarios un c\u00f3digo \u00fanico por correo electr\u00f3nico\/tel\u00e9fono en lugar de una contrase\u00f1a. En este caso, la vulnerabilidad no es tan cr\u00edtica, pero el mecanismo complicar\u00e1 la vida de los usuarios.\n<\/li>\n
    2. El env\u00edo del formulario con el nombre de usuario y contrase\u00f1a a trav\u00e9s de un canal no seguro (Login Form Is Not Submitted Via HTTPS).<\/b>\n
      En este caso, el formulario con el nombre de usuario y la contrase\u00f1a se env\u00eda desde el usuario al servidor a trav\u00e9s de un canal no cifrado.<\/p>\n
      Lo peligroso es<\/b>: A diferencia del caso anterior, esta es una vulnerabilidad cr\u00edtica. Es m\u00e1s f\u00e1cil interceptar datos confidenciales, ya que ni siquiera es necesario escribir c\u00f3digo para ello.\u00a0\n<\/li>\n
    3. Uso de bibliotecas de JavaScript con vulnerabilidades conocidas.<\/b>\n
      Durante el escaneo, la biblioteca m\u00e1s utilizada fue jQuery, con un amplio rango de versiones. En cada una de las versiones hay al menos una, y a veces m\u00e1s, vulnerabilidades conocidas. El impacto puede ser muy diverso, dependiendo de la naturaleza de la vulnerabilidad.<\/p>\n
      Lo peligroso es<\/b>: Para vulnerabilidades conocidas, hay exploits, por ejemplo:<\/p>\n
      \"Pecados
      \n
      \nLo que un desarrollador web debe recordar<\/b>: Regrese regularmente al ciclo: b\u00fasqueda de vulnerabilidades conocidas - eliminaci\u00f3n - verificaci\u00f3n. Si est\u00e1 utilizando bibliotecas obsoletas de manera consciente, por ejemplo, para soportar navegadores antiguos o para ahorrar presupuesto, busque la forma de eliminar la vulnerabilidad conocida.\u00a0\n<\/li>\n
    4. Scripts entre sitios (XSS).\u00a0<\/b>
      \nEl Cross-Site Scripting (XSS), o scripts entre sitios, son ataques a aplicaciones web que resultan en la aparici\u00f3n de c\u00f3digo malicioso en la base de datos. Si Qualys encuentra tal vulnerabilidad, significa que un posible atacante puede haber inyectado o ya inyect\u00f3 su script js en el c\u00f3digo del sitio para realizar acciones maliciosas.<\/p>\n
      XSS almacenado<\/b> son m\u00e1s peligrosos, ya que el script se inyecta en el servidor y se ejecuta cada vez que se abre en el navegador la p\u00e1gina atacada.<\/p>\n
      XSS reflejado<\/b> es m\u00e1s f\u00e1cil de llevar a cabo, ya que el script malicioso se puede inyectar en la solicitud HTTP. La aplicaci\u00f3n recibir\u00e1 la solicitud HTTP, no validar\u00e1 los datos, los empaquetar\u00e1 y los enviar\u00e1 inmediatamente. Si el atacante intercepta el tr\u00e1fico e inserta un script como el siguiente <\/p>\n
      <script>\/*+\u0447\u0442\u043e+\u0442\u043e+\u043f\u043b\u043e\u0445\u043e\u0435+*\/<\/script> <\/code><\/pre>\n
      \nentonces se enviar\u00e1 una solicitud maliciosa en nombre del cliente.<\/p>\n
      Un ejemplo claro de XSS: js-sniffers que imitan p\u00e1ginas para introducir el CVC, la fecha de vencimiento de la tarjeta, etc.\u00a0<\/p>\n
      Lo que un desarrollador web debe recordar<\/b>: En el encabezado Content-Security-Policy utiliza el atributo script-src para que el navegador del cliente cargue y ejecute solo c\u00f3digo de fuentes confiables. Por ejemplo, script-src 'self' permite solo scripts de nuestro propio sitio.\u00a0
      \nLa mejor pr\u00e1ctica consiste en permitir solo c\u00f3digo en l\u00ednea: habilita solo javascript en l\u00ednea con el valor unsafe-inline. Este valor permite el uso de js\/css en l\u00ednea, pero no proh\u00edbe incluir archivos js. En combinaci\u00f3n con script-src 'self', bloqueamos la ejecuci\u00f3n de scripts externos.<\/p>\n
      Aseg\u00farese de registrar todo mediante report-uri y observe los intentos de inyecci\u00f3n en el sitio.\n<\/li>\n
    5. Inyecciones SQL.<\/b>
      \nLa vulnerabilidad indica la posibilidad de inyectar c\u00f3digo SQL en el sitio, que accede directamente a la base de datos del sitio. La inyecci\u00f3n SQL es posible si los datos del usuario no se escapan: no se verifican por su validez y se utilizan directamente en la consulta. Por ejemplo, esto ocurre si un formulario en el sitio no valida la coherencia de la entrada con el tipo de datos.\u00a0<\/p>\n
      Lo peligroso es<\/b>: Si un atacante introduce una consulta SQL en tal formulario, puede provocar que la base de datos se caiga o revelar informaci\u00f3n confidencial.\u00a0<\/p>\n
      Lo que un desarrollador web debe recordar<\/b>: No conf\u00ede en lo que proviene del navegador. Es necesario protegerse tanto en el lado del cliente como en el del servidor.\u00a0<\/p>\n
      En el lado del cliente, implemente la verificaci\u00f3n de campos utilizando JavaScript.\u00a0<\/p>\n
      Las funciones integradas en los frameworks populares tambi\u00e9n ayudan a escapar de caracteres sospechosos en el servidor. Tambi\u00e9n se recomienda utilizar consultas parametrizadas a las bases de datos en el servidor.<\/p>\n
      Identifique d\u00f3nde exactamente se est\u00e1 interactuando con la base de datos en la aplicaci\u00f3n web.\u00a0<\/p>\n
      La interacci\u00f3n ocurre cuando obtenemos alguna informaci\u00f3n: una solicitud con id (cambio de id), creaci\u00f3n de un nuevo usuario, nuevo comentario, - nuevas entradas en la base. Aqu\u00ed pueden ocurrir inyecciones SQL. Incluso si se elimina una entrada de la base, puede haber una inyecci\u00f3n SQL.\n<\/li>\n<\/ol>\n
      <\/p>\n
      Recomendaciones generales<\/h2>\n
      \nNo inventes la rueda: utiliza frameworks probados.<\/b>. En general, los frameworks populares son m\u00e1s seguros. Para .NET, son ASP.NET MVC y ASP.NET Core; para Python, Django o Flask; para Ruby, Ruby on Rails; para PHP, Symfony, Laravel, Yii; para JavaScript, Node.JS - Express.js; para Java, Spring MVC.<\/p>\n
      Est\u00e9 atento a las actualizaciones del proveedor y actualice regularmente.<\/b>. Las vulnerabilidades ser\u00e1n encontradas, luego se escribir\u00e1 un exploit, se pondr\u00e1 en acceso p\u00fablico, y todo volver\u00e1 a repetirse. Suscr\u00edbase a las actualizaciones de versiones estables del proveedor de software.<\/p>\n
      Verifique los permisos de acceso.<\/b>. Desde el lado del servidor, siempre trate su c\u00f3digo como si todo, desde la primera hasta la \u00faltima letra, estuviera escrito por su enemigo m\u00e1s odiado, que desea romper su sitio, romper la integridad de sus datos. Especialmente porque a veces es realmente as\u00ed.<\/p>\n
      Utilice clones, entornos de prueba, y luego despliegue en producci\u00f3n.<\/b>. Esto ayudar\u00e1, en primer lugar, a evitar errores en el entorno productivo: el entorno productivo genera dinero, el tiempo de inactividad en producci\u00f3n es cr\u00edtico. Al agregar, corregir o cerrar cualquier problema, se deben realizar trabajos en el entorno de prueba, luego verificar la funcionalidad y las vulnerabilidades encontradas, y solo despu\u00e9s planear el trabajo con el entorno productivo.\u00a0<\/p>\n
      Proteja la aplicaci\u00f3n web mediante Web Application Firewall<\/a><\/noindex> e integre con los informes del esc\u00e1ner de vulnerabilidades.<\/b>. Por ejemplo, en DataLine se utilizan Qualys y FortiWeb como combinaci\u00f3n de servicios.
      \n
      Fuente:       habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
      \u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434 \u043c\u044b \u0432 DataLine \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u043f\u043e\u0438\u0441\u043a\u0430 \u0438 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 \u0418\u0422-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445. \u0412 \u043e\u0441\u043d\u043e\u0432\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u2013 \u043e\u0431\u043b\u0430\u0447\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 Qualys, \u043f\u0440\u043e \u0440\u0430\u0431\u043e\u0442\u0443 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0443\u0436\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u043b\u0438. \u0417\u0430 \u0433\u043e\u0434 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u0440\u0435\u0448\u0435\u043d\u0438\u0435\u043c \u043c\u044b \u043f\u0440\u043e\u0432\u0435\u043b\u0438 291 \u0441\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0430\u0439\u0442\u043e\u0432 \u0438 \u043d\u0430\u043a\u043e\u043f\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0443 \u043f\u043e \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u043d\u044b\u043c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044f\u043c \u0432 \u0432\u0435\u0431-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.\u00a0 \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u043d\u0438\u0436\u0435 \u044f \u043f\u043e\u043a\u0430\u0436\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043c\u0435\u043d\u043d\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84185,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84184","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Pecados mortales de seguridad del sitio: lo que aprendimos de las estad\u00edsticas del esc\u00e1ner de vulnerabilidades durante un a\u00f1o | ProHoster","description":"Hace aproximadamente un a\u00f1o lanzamos en DataLine un servicio para buscar y analizar vulnerabilidades en aplicaciones de TI.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043c\u0435\u0440\u0442\u043d\u044b\u0435 \u0433\u0440\u0435\u0445\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0441\u0430\u0439\u0442\u0430: \u0447\u0442\u043e \u043c\u044b \u0443\u0437\u043d\u0430\u043b\u0438 \u0438\u0437 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0438 \u0441\u043a\u0430\u043d\u0435\u0440\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0437\u0430 \u0433\u043e\u0434 | ProHoster","og:description":"\u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434 \u043c\u044b \u0432 DataLine \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u043f\u043e\u0438\u0441\u043a\u0430 \u0438 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 \u0418\u0422-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-05T17:42:31+00:00","article:modified_time":"2020-06-05T17:42:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84184","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:03:50","updated":"2022-09-30 12:56:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=84184"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84184\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/84185"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=84184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=84184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=84184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}