Mi pregunta es, para un sitio "normal", ¿qué crees que es suficiente para protegerte contra los métodos utilizados por "script kiddies"? Por ejemplo, inyección SQL, XSS, y cosas por el estilo.
La misma pregunta para los hashes de contraseña. ¿Crees que es suficiente con hash con sal aleatoria MD5 + o con sal mínima aleatoria SHA1 +, o se debe usar algo aún más fuerte?
Sé que ninguna aplicación es completamente segura, pero quiero lograr una buena seguridad sin ser demasiado compleja.
Esto suena como una pregunta de "cuánto dura un trozo de cuerda". No hay una respuesta definitiva. Todo depende del valor de los datos o de este sitio web, la probabilidad de que sea atacado, la habilidad o las herramientas que tendría el atacante, las vulnerabilidades que el sitio ya podría tener, etc. También debería evaluar la complejidad o costo de implementar sus controles de seguridad en comparación con cuánto gana o pierde. p.ej. qué fácil o difícil es cambiar el hash de MD5 a SHA1 en comparación con lo que podría perder si alguien recibe esos hashes.
Yo diría que la probabilidad de que un sitio web en Internet sea atacado por guiones infantiles es razonablemente alta. Hay muchas herramientas y muchas personas aburridas que quieren divertirse o aprender a ser hackers. Por lo tanto, como mínimo, querrá asegurarse de estar cubierto contra las vulnerabilidades conocidas. Si desea ir un paso más allá, intente escanearlo con algunas herramientas que los niños de script pueden usar usted mismo para averiguarlo. También hay un número creciente de proveedores de SaaS que ofrecen este tipo de servicio, algunos de ellos incluso pueden tener una opción básica gratuita. Puede comenzar fácilmente con eso y continuar creciendo / mejorando dependiendo de su perfil de riesgo. Cuando consideres esto, no solo pienses en guiones infantiles y hackers. ¿Qué hay de tu propio personal? ¿Desarrolladores, administradores de sistemas, tu proveedor de hosting? Personas con acceso legítimo, que podrían cometer un error o deliberadamente hacer algo malo. Esos son también un riesgo potencial. Además, no son solo problemas técnicos. Piense en ingeniería social, ataques de phishing, etc.
Aparte de eso, si es para su propio aprendizaje y desarrollo. Intente enumerar todas esas mejoras / problemas de seguridad y califíquelos de alguna manera. Incluso si no está seguro, es mejor tener algunas prioridades en mente. Comience con los elementos que representan el mayor riesgo de inversión. Luego baja a la lista y gradualmente mejora tu seguridad.
Intenta entenderlo desde un punto de vista ligeramente más cercano a la realidad.
Hay personas con diferentes niveles de habilidad que atacarán su sistema web por muchas razones que abarcan desde razones políticas, comerciales, personales o simplemente por razones de entretenimiento.
Las razones no tienen consecuencias al final del día. El hecho primordial es el hecho de que un sistema web es vulnerable y ha sido explotado.
Es responsabilidad del desarrollador asegurarse de que todas las entradas sean de tipo establecido y que las llamadas a la base de datos estén preparadas correctamente.
La responsabilidad del usuario de la aplicación web es asegurarse de que esté actualizada con la última versión del software de la aplicación y las últimas versiones de los complementos y complementos que también puedan usar.
Si los usuarios de la aplicación se adhirieron a esta regla, la explotación de la aplicación se reduciría a la sombra de su versión actual.
Si está utilizando una aplicación que tiene vulnerabilidades de entrada que no han sido parcheadas por los desarrolladores, puede aplicar un parche o cambiar a una aplicación que no sea vulnerable de esa manera.
Si cualquier usuario, sin embargo, se niega a mantener sus aplicaciones actualizadas cuando hay soluciones disponibles, para ser franco, son ellos quienes son el script kiddie no el atacante.
Lea otras preguntas en las etiquetas hash sql-injection xss