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 del sitio web en el software, los hackers intentan abusar de ellos rápidamente.
Si está utilizando una solución de alojamiento administrado, entonces no necesita preocuparse tanto por aplicar actualizaciones de seguridad para el sistema operativo, ya que la empresa de alojamiento debería encargarse de esto.
- ¿Quién es el mejor entrenador de negocios o negocios famosos en India? ¿Por qué?
- Al hacer SEO, ¿podemos obtener una ventaja para los negocios?
- ¿Qué papel juegan los abogados en las fusiones y adquisiciones?
- ¿Cuál fue el desafío más difícil que tuvo que enfrentar para iniciar su propio negocio y cómo lo superó?
- ¿Cuáles son las cualidades de un gran socio comercial?
Si está utilizando software de terceros en su sitio web, como un CMS o un foro, debe asegurarse de aplicar rápidamente cualquier parche 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 disponibles del sistema 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 que no le prestan atención es una de las formas más fáciles de quedar atrapado. Asegúrese de mantener sus dependencias actualizadas y use herramientas como Gemnasium para recibir notificaciones automáticas cuando se anuncie una vulnerabilidad en uno de sus componentes.
02. inyección SQL
Los ataques de inyección SQL son cuando un atacante usa un campo de formulario web o parámetro de URL para obtener acceso o manipular su base de datos. Cuando usa Transact SQL estándar, es fácil, sin saberlo, insertar código falso 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 idiomas web tienen esta característica 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í:
“SELECT * FROM table WHERE column = ” OR ‘1’ = ‘1’;”
Como ‘1’ es igual a ‘1’, esto permitirá al atacante agregar una consulta adicional al final de la instrucción SQL que también se ejecutará.
Puede solucionar esta consulta parametrizándola explícitamente. Por ejemplo, si está utilizando MySQLi en PHP, esto debería convertirse en:
$ stmt = $ pdo-> prepare (‘SELECT * FROM table WHERE column =: value’);
$ stmt-> execute (array (‘valor’ => $ parámetro));
03. XSS
Los ataques de scripting 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 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 cualquier otro usuario y robar su cookie de inicio de sesión, permitiendo que el ataque tome 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 marcos front-end como Angular y Ember. Estos marcos proporcionan muchas protecciones XSS, pero la combinación de la representación del servidor y el cliente también crea nuevas y más complicadas vías de ataque: no solo inyecta JavaScript en el HTML, sino que también puede inyectar contenido que ejecutará código insertando directivas Angulares o usando Ember ayudantes
La clave aquí es centrarse 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 SQL. Al generar HTML de forma dinámica, 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 a mano), o use funciones en su herramienta de plantillas que realiza automáticamente el escape apropiado, en lugar de concatenar cadenas o establecer 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 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 permita JavaScript en línea o deshabilite eval (). Mozilla tiene una excelente guía con algunas configuraciones de ejemplo. Esto dificulta el trabajo de los scripts de un atacante, incluso si pueden ingresarlos a su página.
04. 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 excepciones, ya que estos pueden hacer que los ataques complejos como la inyección SQL sean mucho más fáciles. Mantenga errores detallados en los registros de su servidor y muestre a los usuarios solo la información que necesitan.
05. Validación del lado del servidor / validación de formulario
La validación siempre debe hacerse tanto en el navegador como en el 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, se pueden omitir, y debe asegurarse de verificar estas validaciones y un servidor de validación más profundo, ya que de lo contrario podría provocar que se inserte código malicioso o código de script en la base de datos o podría causar resultados no deseados en su sitio web.
06. Contraseñas
Todos saben que deberían usar contraseñas complejas, pero eso no significa que siempre lo hagan. Es crucial usar contraseñas seguras para el servidor y el área de administración del sitio web, pero igualmente importante es insistir en buenas prácticas de contraseña 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 autentica a los usuarios, solo compara los valores cifrados. Para mayor seguridad del sitio web, es una buena idea usar las nuevas contraseñas.
En caso de que alguien piratee y robe sus contraseñas, el uso de contraseñas hash podría ayudar a limitar los daños, ya que no es posible descifrarlos. 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 usan contraseñas con sal, el proceso de descifrar una gran cantidad de contraseñas es aún más lento, ya que cada conjetura se debe descifrar por separado para cada contraseña de sal + que es computacionalmente muy costosa.
Afortunadamente, muchos CMS proporcionan administración de usuarios lista para usar con muchas de estas características de seguridad del sitio web integradas, aunque es posible que se requieran algunas configuraciones o módulos adicionales para usar contraseñas con sal (anteriores a Drupal 7) o para establecer la contraseña mínima. Si está usando .NET, entonces vale la pena usar proveedores de membresía, ya que son muy configurables, brindan seguridad incorporada en el sitio web e incluyen controles listos para iniciar sesión y restablecer la contraseña.
07. Subidas de archivos
Permitir que los usuarios carguen archivos en su sitio web puede ser un gran riesgo para la seguridad del sitio web, incluso si es simplemente 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, entonces 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 mime para verificar que el archivo sea 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 son prueba completa. 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 ser ejecutado por el servidor.
Entonces, ¿qué puedes hacer para evitar 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 se recomienda confiar únicamente en verificar la extensión de archivo como se sabe que un archivo con el nombre image.jpg.php ha llegado.
Algunas opciones son cambiar el nombre del archivo en la carga 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, podría crear un archivo .htaccess (ver más abajo) que solo permitirá el acceso a los archivos de configuración evitando el ataque de doble extensión mencionado anteriormente.
Negar todo
orden negar, permitir
permitir de todos
Finalmente, la solución recomendada es evitar el acceso directo a los archivos cargados todos juntos. 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 puede acceder directamente a sus archivos, deberá crear un script para recuperar los archivos de la carpeta privada (o un controlador HTTP en .NET) y entregarlos 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:
<? php
// imageDelivery.php
// Obtener el nombre de archivo de la imagen de la base de datos basado en $ _GET [“id”]
…
// Entregar imagen al navegador
Encabezado (‘Tipo de contenido: imagen / gif’);
readfile (‘images /’.$ fileName);
?>
La mayoría de los proveedores de alojamiento manejan la configuración del servidor por usted, pero si aloja su sitio web en su propio servidor, entonces hay algunas cosas que querrá verificar.
Asegúrese de tener una configuración de firewall y de que esté bloqueando todos los puertos no esenciales. Si es posible, configure 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 los archivos se carguen de 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 el mundo exterior, solo su servidor web puede acceder a él, minimizando el riesgo de que sus datos estén expuestos.
Finalmente, no se olvide de restringir el acceso físico a su servidor.
08. HTTPS
HTTPS es un protocolo utilizado para proporcionar seguridad a través de Internet. HTTPS garantiza a los usuarios que están hablando con el servidor que esperan y que nadie más puede interceptar o cambiar el contenido que están viendo en tránsito.
Si tiene algo que sus usuarios puedan desear en 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 se 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 cualquier otra solicitud a su sitio que realice un usuario conectado, y se utiliza para autenticar esas solicitudes. Un atacante que robe esto podría imitar perfectamente a un usuario y asumir su sesión de inicio de sesión. Para vencer este tipo de ataques, casi siempre desea usar HTTPS para todo su sitio.
Sin embargo, eso ya no es tan complicado o costoso como solía ser. Let’s Encrypt proporciona certificados totalmente gratuitos y automatizados, que necesitará para habilitar HTTPS, y existen herramientas comunitarias disponibles para una amplia gama de plataformas y marcos comunes para configurarlo automáticamente.
En particular, Google ha anunciado que lo impulsarán en las clasificaciones de búsqueda si usa HTTPS, lo que también le brinda un beneficio de SEO. Sin embargo, hay un palo para ir con esa zanahoria: Chrome y otros navegadores planean poner advertencias cada vez más grandes en cada sitio que no haga esto, a partir de enero de 2017. HTTP inseguro está saliendo, y ahora es el momento de mejorar.
¿Ya estás usando HTTPS en todas partes? Vaya más allá y busque configurar HTTP Strict Transport Security (HSTS), un encabezado fácil que puede agregar a las respuestas de su servidor para no permitir HTTP inseguro para todo su dominio.
09. Herramientas de seguridad del sitio web
Una vez que piense que ha hecho todo lo que puede, es hora de probar la seguridad de su sitio web. La forma más efectiva de hacerlo es mediante el uso de algunas herramientas de seguridad del sitio web, a menudo denominadas pruebas de penetración o pruebas de lápiz para abreviar.
Hay muchos productos comerciales y gratuitos para ayudarlo con esto. Funcionan de manera similar a los scripts que los hackers usarán, 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 mirar:
- Netsparker (edición comunitaria gratuita y versión de prueba disponible). Bueno para probar 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 la bifurcación de un Nessus antes de convertirse en un producto comercial de código cerrado.
- SecurityHeaders.io (verificación en línea gratuita). Una herramienta para informar rápidamente qué encabezados de seguridad mencionados anteriormente (como CSP y HSTS) ha habilitado y configurado correctamente un dominio.
- Xenotix XSS Exploit Framework 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 desalentadores, ya que presentan una gran cantidad de problemas potenciales. Lo importante es centrarse primero en los problemas críticos. Cada problema reportado 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.
Si desea llevar las cosas un paso más allá, hay algunos pasos adicionales que puede seguir para intentar comprometer manualmente su sitio alterando 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 buena aplicación gratuita llamada Fiddler es un buen punto de partida.
Entonces, ¿qué debería estar tratando de alterar en la solicitud? Si tiene páginas que solo deberían ser visibles para un usuario que haya iniciado sesión, entonces intentaría cambiar los parámetros de URL, como la identificación del usuario o los valores de 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.
Esperemos que estos consejos lo ayuden a mantener su sitio e información seguros. Afortunadamente, la mayoría de los CMS tienen muchas características de seguridad integradas en el sitio web, pero sigue siendo una buena idea tener conocimiento de las vulnerabilidades de seguridad más comunes para que pueda asegurarse de estar cubierto.
También hay algunos módulos útiles disponibles para que los CMS verifiquen su instalación en busca de fallas de seguridad comunes como Security Review para Drupal y WP Security Scan para WordPress.