9 consejos de seguridad para proteger su sitio web de los piratas informáticos

Puede que crea que su sitio no 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 brechas de seguridad del sitio web no tienen como objetivo robar sus datos o interferir con su diseño del sitio web , pero en su lugar intenta utilizar su servidor como un retransmisor de correo electrónico para correo no deseado, o para configurar un servidor web temporal, normalmente para entregar archivos de naturaleza ilegal. Otras formas muy comunes de abusar de las máquinas comprometidas incluyen usar sus servidores como parte de una botnet o extraer Bitcoins. Incluso podría ser atacado por ransomware.

La piratería se realiza regularmente 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 ayudarlo a que usted y su sitio estén seguros en línea.

01. Mantenga el software actualizado

Puede parecer obvio, pero asegurarse de mantener todo el software actualizado es vital para mantener la seguridad de su sitio. 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 intentan abusar de ellos rápidamente.

Si está utilizando una solución de alojamiento administrado, no necesita preocuparse tanto por la aplicación de 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 una fuente RSS que detalla cualquier problema de seguridad del sitio web. WordPress , Umbraco y muchos otros CMS le notifican 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 prestan 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 anuncia una vulnerabilidad en uno de sus componentes.

02. Cuidado con la inyección SQL

Los ataques de inyección de SQL ocurren cuando un atacante utiliza un campo de formulario web o un parámetro de URL para obtener acceso o manipular su base de datos. Cuando usa Transact SQL estándar, es fácil insertar, sin saberlo, código falso en su consulta que podría usarse para cambiar tablas, obtener información y eliminar datos. Puede evitarlo 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:

|_+_|

Si un atacante cambió el parámetro de URL para pasar 'o' 1 '=' 1, esto hará que la consulta se vea así:

|_+_|

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 corregir esta consulta parametrizándola explícitamente. Por ejemplo, si está utilizando MySQLi en PHP, esto debería convertirse en:

|_+_|

03. Protéjase contra ataques XSS

Los ataques de cross-site scripting (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 enviarla al atacante. Por ejemplo, si muestra comentarios en una página sin validación, 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, lo que permitiría que el ataque tomara el control de la cuenta de cada 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 construyen principalmente a partir del contenido del usuario, y que en muchos casos generan HTML que luego también es interpretado por frameworks front-end como Angular y Ember. Estos marcos proporcionan muchas protecciones XSS, pero la combinación de la representación del servidor y del cliente también crea nuevas y más complicadas vías de ataque: no solo inyectar JavaScript en el HTML es efectivo, sino que también puede inyectar contenido que ejecutará código insertando directivas angulares o usando Ember. ayudantes.

La clave aquí es enfocarse en cómo su contenido generado por el usuario podría escapar de los límites que espera y ser interpretado por el navegador como algo diferente de lo que pretendía. Esto es similar a defenderse contra la inyección de SQL. Al generar HTML dinámicamente, use funciones que hagan 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 creación de plantillas que automáticamente realizan el escape apropiado, en lugar de concatenar cadenas o configurar contenido HTML sin procesar.

Otra poderosa herramienta 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 que le dice al navegador que limite cómo y qué JavaScript se ejecuta en la página, por ejemplo, para no permitir la ejecución de cualquier script que no esté alojado en su dominio, no permitir JavaScript en línea o deshabilitar eval (). Mozilla tiene una excelente guía con algunas configuraciones de ejemplo. 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 la excepción, ya que estos 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 en ambos lados

La validación siempre debe realizarse tanto en el navegador como en el servidor. El navegador puede detectar fallas simples como los campos obligatorios que están vacíos y cuando ingresa texto en un campo de solo números. Sin embargo, estos se pueden omitir, y debe asegurarse de verificar esta validación y el lado del servidor de validación más profunda, ya que no hacerlo podría llevar a que se inserte código malicioso o código de secuencia de comandos en la base de datos o podría causar resultados no deseados en su sitio web.

06. Comprueba tus contraseñas

Todos saben que deben usar contraseñas complejas, pero eso no significa que siempre lo hagan. Es fundamental utilizar contraseñas seguras para el área de administración de su servidor y sitio web, pero también es importante insistir en las 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, hacer cumplir los requisitos de contraseña, como un mínimo de alrededor 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 de hash unidireccional como SHA. El uso de este método significa que cuando está autenticando usuarios, solo está comparando valores cifrados. Para mayor seguridad del sitio web, es una buena idea agregar sal a las contraseñas, usando una nueva sal por contraseña.

En el caso de que alguien piratee y robe sus contraseñas, el uso de contraseñas hash podría ayudar a limitar el daño, ya que no es posible descifrarlas. Lo mejor que puede hacer alguien es un ataque de diccionario o un ataque de fuerza bruta, esencialmente adivinando cada combinación hasta encontrar 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 conjetura debe ser codificada 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 características 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 usar para el inicio de sesión y el restablecimiento de 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 en el tipo de mime para verificar que el archivo sea una imagen, ya que se pueden falsificar fácilmente. Incluso abrir el archivo y leer el encabezado, o usar funciones para verificar el tamaño de la imagen, no son infalibles. 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 de archivo correcta 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 de configuración que eviten el ataque de doble extensión mencionado anteriormente.

|_+_|

En última instancia, la solución recomendada es evitar por completo el acceso directo a los archivos cargados. De esta manera, los archivos cargados en su sitio web se almacenan en una carpeta fuera de la raíz web 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 está alojando su sitio web en su propio servidor, hay algunas cosas que querrá comprobar.

Asegúrese de tener una configuración de firewall y de bloquear todos los puertos no esenciales. Si es posible, establezca una DMZ (zona desmilitarizada) que solo permita el acceso al puerto 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, ejecute su base de datos 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 el mundo exterior, solo su servidor web puede acceder a él, minimizando el riesgo de que sus datos estén expuestos.

Por último, no olvide restringir el acceso físico a su servidor.

08. Utilice HTTPS

HTTPS es un protocolo que se utiliza para proporcionar seguridad en Internet. HTTPS garantiza que los usuarios están hablando con el servidor que esperan y que nadie más puede interceptar o cambiar el contenido que ven en tránsito.

Si tiene algo que sus usuarios deseen que sea privado, es muy recomendable usar solo HTTPS para entregarlo. Eso, por supuesto, significa tarjetas de crédito y páginas de inicio de sesión (y las URL a las que envían), pero generalmente también mucho más de su sitio. Un formulario de inicio de sesión a menudo establecerá una cookie, por ejemplo, que se envía con cada otra solicitud a su sitio que realiza un usuario que ha iniciado sesión, y se utiliza para autenticar esas solicitudes. Un atacante que robe esto podría imitar perfectamente a un usuario y hacerse cargo de su sesión de inicio de sesión. Para vencer este tipo de ataques, casi siempre querrás usar HTTPS para todo tu sitio.

Eso ya no es tan complicado o caro como lo era antes. Vamos a cifrar proporciona certificados totalmente gratuitos y automatizados, que necesitará para habilitar HTTPS, y existen herramientas comunitarias existentes disponibles para una amplia gama de plataformas y marcos comunes que lo configuran automáticamente.

En particular, Google ha anunciado que lo impulsarán en los rankings de búsqueda si usa HTTPS, lo que también le brinda un beneficio de SEO. HTTP inseguro está desapareciendo, y ahora es el momento de actualizar.

¿Ya usas HTTPS en todas partes? Vaya más allá y observe cómo configurar HTTP Strict Transport Security (HSTS), un encabezado sencillo que puede agregar a las respuestas de su servidor para no permitir HTTP inseguro para todo su dominio.

09. Obtenga herramientas de seguridad del sitio web

Una vez que crea que ha hecho todo lo posible, es hora de probar la seguridad de su sitio web. La forma más eficaz de hacerlo es mediante el uso de algunas herramientas de seguridad del sitio web, a menudo denominadas pruebas de penetración o pruebas de penetración para abreviar.

Hay muchos productos comerciales y gratuitos para ayudarlo con esto. Funcionan de manera similar a los hackers de scripts, ya que prueban todos los exploits conocidos e intentan comprometer su sitio utilizando algunos de los métodos mencionados anteriormente, como la inyección SQL.

Algunas herramientas gratuitas que vale la pena ver:

  • Netsparker (Edición comunitaria gratuita y versión de prueba disponibles). Bueno para probar la inyección SQL y XSS
  • OpenVAS Afirma ser el escáner de seguridad de código abierto más avanzado. Bueno para probar vulnerabilidades conocidas, actualmente escanea más de 25,000. Pero puede ser difícil de configurar y requiere la instalación de un servidor OpenVAS que solo se ejecuta en * nix. OpenVAS es una bifurcación de Nessus antes de convertirse en un producto comercial de código cerrado.
  • SecurityHeaders.io (cheque en línea gratis). Una herramienta para informar rápidamente qué encabezados de seguridad mencionados anteriormente (como CSP y HSTS) ha habilitado y configurado correctamente un dominio.
  • Marco de explotación Xenotix XSS Una herramienta de OWASP (Open Web Application Security Project) que incluye una gran selección de ejemplos de ataques XSS, que puede ejecutar para confirmar rápidamente si las entradas de su sitio son vulnerables en Chrome, Firefox e IE.

Los resultados de las pruebas automatizadas pueden ser abrumadores, ya que presentan una gran cantidad de problemas potenciales. Lo importante es centrarse primero en las cuestiones críticas. Cada problema informado normalmente viene con una buena explicación de la vulnerabilidad potencial. Probablemente encontrará que algunos de los problemas medios / bajos no son una preocupación para su sitio.

Hay algunos pasos adicionales que puede seguir para intentar comprometer manualmente su sitio modificando los valores POST / GET. Un proxy de depuración puede ayudarlo aquí, ya que le permite interceptar los valores de una solicitud HTTP entre su navegador y el servidor. Una popular aplicación gratuita llamada Violinista es un buen punto de partida.

Entonces, ¿qué debería intentar modificar en la solicitud? Si tiene páginas que solo deberían ser visibles para un usuario que inició sesión, intente cambiar los parámetros de URL, como la identificación del usuario o los valores de las cookies, en un intento de ver los detalles de otro usuario. Otra área que vale la pena probar son los formularios, que cambian los valores POST para intentar enviar código para realizar XSS o cargar un script del lado del servidor.

Artículos relacionados: