Puede que no creas que tu sitio tiene nada por lo que valga la pena ser pirateado, pero los sitios web están comprometidos todo el tiempo. La mayoría de las violaciones de seguridad de sitios web no tienen como objetivo robar sus datos ni alterar el diseño de su sitio web, sino que intentan utilizar su servidor como retransmisor de correo electrónico para spam o configurar un servidor web temporal, normalmente para entregar archivos de naturaleza ilegal. . Otras formas muy comunes de abusar de las máquinas comprometidas incluyen el uso de sus servidores como parte de una botnet o para extraer Bitcoins. Incluso podría verse afectado por ransomware.
La piratería se realiza habitualmente mediante scripts automatizados escritos para rastrear Internet en un intento de explotar problemas conocidos de seguridad de sitios web en el software. Estos son nuestros nueve consejos principales para ayudarle a usted y a su sitio a estar seguros en línea.
01. Mantenga el software actualizado
Puede parecer obvio, pero asegurarse de mantener todo el software actualizado es vital para mantener su sitio seguro. Esto se aplica tanto al sistema operativo del servidor como a cualquier software que pueda estar ejecutando en su sitio web, como un CMS o un foro. Cuando se encuentran agujeros de seguridad en un sitio web en el software, los piratas informáticos se apresuran a intentar aprovecharlos.
Si está utilizando una solución de alojamiento administrado, no necesita preocuparse tanto por aplicar actualizaciones de seguridad para el sistema operativo, ya que la empresa de alojamiento debe encargarse de esto.
Si está utilizando software de terceros en su sitio web, como un CMS o un foro, debe asegurarse de aplicar rápidamente los parches de seguridad. La mayoría de los proveedores tienen una lista de correo o un canal RSS que detalla cualquier problema de seguridad del sitio web. WordPress, Umbraco y muchos otros CMS le notifican sobre las actualizaciones del sistema disponibles cuando inicia sesión.
Muchos desarrolladores usan herramientas como Composer, npm o RubyGems para administrar sus dependencias de software, y las vulnerabilidades de seguridad que aparecen en un paquete del que depende pero al que no le presta atención es una de las formas más fáciles de quedar atrapado. Asegúrese de mantener sus dependencias actualizadas y utilice herramientas como Gemnasium para recibir notificaciones automáticas cuando se anuncie una vulnerabilidad en uno de sus componentes.
02. Cuidado con la inyección SQL
Los ataques de inyección SQL se producen cuando un atacante utiliza un campo de formulario web o un parámetro de URL para obtener acceso a su base de datos o manipularla. Cuando utiliza Transact SQL estándar, es fácil insertar, sin saberlo, código malicioso en su consulta que podría usarse para cambiar tablas, obtener información y eliminar datos. Puede evitar esto fácilmente utilizando siempre consultas parametrizadas; la mayoría de los lenguajes web tienen esta función y es fácil de implementar.
Considere esta consulta:
“SELECCIONAR * DE la tabla DONDE columna = '” + parámetro + “';”
Si un atacante cambió el parámetro de URL para pasar ' o '1'='1, esto hará que la consulta se vea así:
“SELECCIONAR * DE la tabla DONDE columna = '' O '1'='1';”
Dado que '1' es igual a '1', esto permitirá al atacante agregar una consulta adicional al final de la declaración SQL que también se ejecutará.
Puede solucionar esta consulta parametrizándola explícitamente. Por ejemplo, si estás usando MySQLi en PHP, esto debería ser:
$stmt = $pdo->prepare('SELECCIONAR * DE la tabla DONDE columna = :valor'); $stmt->execute(array('valor' => $parámetro));
03. Protéjase contra ataques XSS
Los ataques de secuencias de comandos entre sitios (XSS) inyectan JavaScript malicioso en sus páginas, que luego se ejecuta en los navegadores de sus usuarios y puede cambiar el contenido de la página o robar información para enviársela al atacante. Por ejemplo, si muestra comentarios en una página sin validación, entonces un atacante podría enviar comentarios que contengan etiquetas de script y JavaScript, que podrían ejecutarse en el navegador de todos los demás usuarios y robar su cookie de inicio de sesión, permitiendo que el ataque tome el control de la cuenta de cada uno. Usuario que vio el comentario. Debe asegurarse de que los usuarios no puedan inyectar contenido JavaScript activo en sus páginas.
Esta es una preocupación particular en las aplicaciones web modernas, donde las páginas ahora se crean principalmente a partir del contenido del usuario y que en muchos casos generan HTML que luego también es interpretado por marcos de front-end como Angular y Ember. Estos marcos brindan muchas protecciones XSS, pero mezclar la representación del servidor y del cliente también crea vías de ataque nuevas y más complicadas: no solo es efectivo inyectar JavaScript en HTML, sino que también puede inyectar contenido que ejecutará código insertando directivas Angular o usando Ember. ayudantes.
La clave aquí es centrarse en cómo el contenido generado por el usuario podría escapar de los límites esperados y ser interpretado por el navegador como algo distinto a lo que pretendía. Esto es similar a defenderse contra la inyección SQL. Al generar HTML dinámicamente, use funciones que realicen explícitamente los cambios que está buscando (por ejemplo, use element.setAttribute y element.textContent, que el navegador escapará automáticamente, en lugar de configurar element.innerHTML manualmente), o use funciones en su herramienta de plantillas que automáticamente realiza el escape apropiado, en lugar de concatenar cadenas o configurar contenido HTML sin formato.
Otra herramienta poderosa en la caja de herramientas del defensor XSS es la Política de seguridad de contenido (CSP). CSP es un encabezado que su servidor puede devolver y que le indica al navegador que limite cómo y qué JavaScript se ejecuta en la página, por ejemplo, para no permitir la ejecución de scripts no alojados en su dominio, no permitir JavaScript en línea o deshabilitar eval(). Mozilla tiene una guía excelente con algunos ejemplos de configuraciones. Esto dificulta el funcionamiento de los scripts de un atacante, incluso si pueden introducirlos en su página.
04. Cuidado con los mensajes de error
Tenga cuidado con la cantidad de información que proporciona en sus mensajes de error. Proporcione solo errores mínimos a sus usuarios, para asegurarse de que no filtren secretos presentes en su servidor (por ejemplo, claves API o contraseñas de bases de datos). Tampoco proporcione detalles completos de las excepciones, ya que pueden facilitar mucho los ataques complejos como la inyección SQL. Mantenga los errores detallados en los registros de su servidor y muestre a los usuarios solo la información que necesitan.
05. Validar por ambos lados
La validación siempre debe realizarse tanto en el lado del navegador como en el del servidor. El navegador puede detectar fallas simples, como campos obligatorios que están vacíos y cuando ingresa texto en un campo de solo números. Sin embargo, estos pueden omitirse, y debe asegurarse de verificar estas validaciones y una validación más profunda en el lado del servidor, ya que no hacerlo podría provocar que se inserte código malicioso o código de secuencias de comandos en la base de datos o podría causar resultados no deseados en su sitio web.
06. Revisa tus contraseñas
Todo el mundo sabe que deben utilizar contraseñas complejas, pero eso no significa que siempre lo hagan. Es fundamental utilizar contraseñas seguras para su servidor y el área de administración de su sitio web, pero también es igualmente importante insistir en buenas prácticas de contraseñas para que sus usuarios protejan la seguridad de sus cuentas.
Por mucho que a los usuarios no les guste, imponer requisitos de contraseña, como un mínimo de ocho caracteres, incluida una letra mayúscula y un número, ayudará a proteger su información a largo plazo.
Las contraseñas siempre deben almacenarse como valores cifrados, preferiblemente utilizando un algoritmo hash unidireccional como SHA. El uso de este método significa que cuando autentica usuarios, solo compara valores cifrados. Para mayor seguridad del sitio web, es una buena idea agregar sal a las contraseñas, utilizando un sal nuevo por contraseña.
En el caso de que alguien piratee y robe sus contraseñas, el uso de contraseñas cifradas podría ayudar a limitar los daños, ya que no es posible descifrarlas. Lo mejor que alguien puede hacer es un ataque de diccionario o un ataque de fuerza bruta, esencialmente adivinando cada combinación hasta que encuentre una coincidencia. Cuando se utilizan contraseñas saladas, el proceso de descifrar una gran cantidad de contraseñas es aún más lento, ya que cada suposición debe procesarse por separado para cada contraseña salt +, lo cual es computacionalmente muy costoso.
Afortunadamente, muchos CMS brindan administración de usuarios lista para usar con muchas de estas funciones de seguridad de sitios web integradas, aunque es posible que se requiera alguna configuración o módulos adicionales para usar contraseñas saladas (anteriores a Drupal 7) o para establecer la seguridad mínima de la contraseña. Si está utilizando .NET, entonces vale la pena utilizar proveedores de membresía, ya que son muy configurables, brindan seguridad incorporada al sitio web e incluyen controles listos para iniciar sesión y restablecer contraseña.
07. Evite la carga de archivos
Permitir que los usuarios carguen archivos en su sitio web puede representar un gran riesgo para la seguridad del sitio web, incluso si se trata simplemente de cambiar su avatar. El riesgo es que cualquier archivo cargado, por inocente que parezca, podría contener un script que, cuando se ejecuta en su servidor, abre completamente su sitio web.
Si tiene un formulario de carga de archivos, debe tratar todos los archivos con gran sospecha. Si permite que los usuarios carguen imágenes, no puede confiar en la extensión del archivo o el tipo MIME para verificar que el archivo es una imagen, ya que pueden falsificarse fácilmente. Incluso abrir el archivo y leer el encabezado, o usar funciones para verificar el tamaño de la imagen, no es infalible. La mayoría de los formatos de imágenes permiten almacenar una sección de comentarios que podría contener código PHP que podría ejecutar el servidor.
Entonces, ¿qué puedes hacer para prevenir esto? En última instancia, desea evitar que los usuarios puedan ejecutar cualquier archivo que carguen. De forma predeterminada, los servidores web no intentarán ejecutar archivos con extensiones de imagen, pero no confíe únicamente en verificar la extensión del archivo, ya que se sabe que un archivo con el nombre image.jpg.php puede pasar.
Algunas opciones son cambiar el nombre del archivo al cargarlo para garantizar la extensión correcta del archivo o cambiar los permisos del archivo, por ejemplo, chmod 0666 para que no se pueda ejecutar. Si usa *nix, puede crear un archivo .htaccess (ver más abajo) que solo permitirá el acceso a archivos configurados evitando el ataque de doble extensión mencionado anteriormente.
negar desde todos los ordenar denegar, permitir permitir desde todos los
En última instancia, la solución recomendada es impedir por completo el acceso directo a los archivos cargados. De esta manera, cualquier archivo cargado en su sitio web se almacena en una carpeta fuera de webroot o en la base de datos como un blob. Si no se puede acceder directamente a sus archivos, deberá crear una secuencia de comandos para recuperar los archivos de la carpeta privada (o un controlador HTTP en .NET) y enviarlos al navegador. Las etiquetas de imagen admiten un atributo src que no es una URL directa a una imagen, por lo que su atributo src puede apuntar a su secuencia de comandos de entrega de archivos siempre que establezca el tipo de contenido correcto en el encabezado HTTP. Por ejemplo:
La mayoría de los proveedores de alojamiento se encargan de la configuración del servidor por usted, pero si aloja su sitio web en su propio servidor, hay algunas cosas que deberá comprobar.
Asegúrese de tener un firewall configurado y de bloquear todos los puertos no esenciales. Si es posible, establecer una DMZ (Zona Desmilitarizada) que solo permita el acceso a los puertos 80 y 443 desde el mundo exterior. Aunque esto podría no ser posible si no tiene acceso a su servidor desde una red interna, ya que necesitaría abrir puertos para permitir la carga de archivos e iniciar sesión de forma remota en su servidor a través de SSH o RDP.
Si permite que se carguen archivos desde Internet, utilice únicamente métodos de transporte seguros a su servidor, como SFTP o SSH.
Si es posible, haga que su base de datos se ejecute en un servidor diferente al de su servidor web. Hacer esto significa que no se puede acceder al servidor de la base de datos directamente desde…
