¿Cómo se piratean los sitios web para modificar su contenido? ¿Cómo puedo evitar tales ataques en mi sitio web?

Básicamente hay tres tipos de ataques en internet.

• Cross Site Scripting (ataca su navegador, vea Cross-site scripting).
• Falsificación de solicitudes entre sitios (ataca su conexión a un servidor, consulte Falsificación de solicitudes entre sitios)
• Inyección SQL (ataca el servidor, ver inyección SQL).

No conozco lo suficiente sobre este tema para explicar las diferentes formas de implementar estos ataques, pero quiero señalar algo.

Para cambiar el contenido del sitio web, la única forma es poder iniciar sesión en el servidor de la base de datos, y también poder pasar el bloqueo de contraseña en la base de datos y modificar el contenido.

Esto no es verdad. De alguna manera, podría hacer que el servidor entregue JavaScript malicioso, que se ejecuta en su navegador. El código malicioso intercambia todos los titulares con “U MAD?”. Este es un ataque de Cross Site Scripting. Tampoco he iniciado sesión en la base de datos ni he descifrado una contraseña.

Hay muchas formas en que se pueden hackear sitios web que incluyen seguridad de inicio de sesión deficiente y permisos de usuario, vulnerabilidades de software, vulnerabilidades de código / malware, etc.

No siempre es posible estar al tanto de los últimos informes de vulnerabilidad a menos que el suyo sea un pequeño sitio web estático en su propio servidor web dedicado.

La mejor manera en estos días es ejecutar escaneos automáticos en su sitio web donde haya un tercero, como SiteLock, evaluando la seguridad de su sitio web. Esto es bueno de DOS maneras:

1. Le permite conocer los problemas y, en ocasiones, los soluciona por usted.
2. Proporcionan un sello de confianza que le dice a sus visitantes que su sitio web puede ser confiable con su información.

Depende del exploit utilizado. No es necesario conectarse directamente a la base de datos en la mayoría de los casos.

El hacker primero buscará su servidor para encontrar cuál es la pila de su aplicación (Lenguajes de programación, Base de datos, CMS, OS).

Mirar HTML, código Javascript, patrón de URL, obtener URL estándar de páginas de administración y escaneo de puertos ayuda mucho.

Una vez hecho esto, él o ella sabe qué hazañas probar.

Con los CMS, los exploits se hacen públicos muy rápido. Los parches de seguridad están disponibles con la misma rapidez. Si aplica regularmente parches de seguridad, estará bien. Aparte de eso, los CMS son vulnerables principalmente debido a una mala configuración o una mala elección de contraseña.

Las aplicaciones personalizadas son más vulnerables a los agujeros de bucle en el código. Hay muchas vulnerabilidades que pueden explotarse y puede encontrar las más comunes enumeradas aquí: Categoría: Proyecto Top Ten de OWASP

En mi experiencia, la mayoría de los problemas relacionados con el código surgen porque muchos desarrolladores hacen estas suposiciones erróneas:

1. El usuario puede ver pero no cambiar HTML o JavaScript para que la lógica del lado del cliente no pueda ser manipulada.
2. Las solicitudes POST son seguras porque el usuario no puede ver lo que se pasa al servidor. A diferencia de GET, el usuario no puede modificar los parámetros.
3. Está bien devolver la contraseña guardada a una página porque aparece como *****

Otros errores comunes:

1. Los campos de la base de datos quedan expuestos a modificaciones porque el programador elige simplemente persistir todo el objeto recibido del usuario en lugar de elegir solo aquellos campos que el usuario pudo modificar desde esa página.

2. Tener métodos ajax como getObject (int objectid) en Javascript sin la validación correspondiente en el lado del servidor para determinar si el objeto solicitado debe ser accesible para el usuario actual.

Estos errores de codificación aparentemente poco convincentes son sorprendentemente muy comunes en aplicaciones personalizadas.