Es posible que no piense que su sitio tiene algo por lo que vale la pena hackearlo, pero los sitios web están en peligro todo el tiempo. La mayoría de las infracciones de seguridad del sitio web no son para robar sus datos o desfigurar su sitio web, sino que intenta utilizar su servidor como retransmisor de correo electrónico para correo no deseado, o configurar un servidor web temporal, normalmente para servir archivos de naturaleza ilegal.
El pirateo se realiza regularmente mediante scripts automáticos escritos para explorar Internet en un intento de explotar los problemas de seguridad conocidos del sitio web en el software. Estos son nuestros 10 consejos principales para ayudarlo a usted y a su sitio a mantenerse seguros en línea.
01. Mantenga el software actualizado
- ¿El hecho de que Microsoft distribuya un antivirus incorporado gratuito con sus sistemas operativos representa una amenaza para las compañías de software antivirus?
- ¿Cuáles son los mejores sitios web para noticias e información de seguridad cibernética?
- ¿Cuáles son las diferencias y similitudes entre la aplicación web y la ingeniería inversa binaria?
- ¿Alguna vez has pirateado la computadora de otro hacker?
- ¿Cómo se nombra una vulnerabilidad de seguridad después de ser descubierta?
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.
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.
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á.
03. XSS
Las secuencias de comandos de sitios cruzados se producen cuando un atacante intenta pasar JavaScript u otro código de secuencias de comandos a un formulario web para intentar ejecutar código malicioso para los visitantes de su sitio. Al crear un formulario, asegúrese siempre de verificar los datos que se envían y codificar o eliminar cualquier HTML.
04. Mensajes de error
Tenga cuidado con la cantidad de información que proporciona en sus mensajes de error. Por ejemplo, si tiene un formulario de inicio de sesión en su sitio web, debe pensar en el idioma que utiliza para comunicar un error al intentar iniciar sesión. Debe usar mensajes genéricos como “Nombre de usuario o contraseña incorrectos” para no especificar cuándo un usuario obtuvo la mitad de la consulta correctamente. Si un atacante intenta un ataque de fuerza bruta para obtener un nombre de usuario y contraseña y el mensaje de error se muestra cuando uno de los campos es correcto, entonces el atacante sabe que tiene uno de los campos y puede concentrarse en el otro campo.
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 de todos orden de 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:
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.
09.SSL
SSL es un protocolo utilizado para proporcionar seguridad a través de Internet. Es una buena idea usar un certificado de seguridad siempre que pase información personal entre el sitio web y el servidor web o la base de datos. Los atacantes podrían rastrear esta información y, si el medio de comunicación no es seguro, podría capturarla y usar esta información para obtener acceso a las cuentas de usuario y datos personales.
10. 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.
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.
Espero que ayude…