Me sorprendió cuando, en mi clase de gestión avanzada de datos, el profesor tenía un gráfico que mostraba una amenaza relativamente pequeña (pero significativa) de los ataques de inyección SQL. Esto me pareció sorprendente porque son relativamente fáciles de evitar, dado que el programador usa los métodos incorporados en el lenguaje para ejecutar una consulta.
Entonces, ese sería uno de los más grandes. Es obvio, bien conocido y fácil de proteger (Brian Swan de Microsoft hace un mejor trabajo al hablar de esto que yo: ¿los procedimientos almacenados protegen contra la inyección de SQL?). También es fácil de explotar y extremadamente peligroso cuando se explota.
Básicamente, tenga en cuenta que si está escribiendo algo abriendo un socket, está expandiendo la superficie de ataque de la plataforma en la que se encuentra. En otras palabras, use servicios web que se encuentren en un contenedor web en lugar de abrir puertos en una máquina A MENOS QUE ES ABSOLUTAMENTE NECESARIO.
- ¿Cómo es participar en un concurso de piratería informática?
- ¿Qué debe hacer si alguien le está chantajeando por dinero en Skype? ¿Pueden realmente hacer algo para dañar tu reputación?
- ¿Qué son los certificados de seguridad digital?
- ¿Cómo funcionan exactamente los malwares de enlaces de Facebook?
- Después de hacer un curso de seguridad de red, ¿qué ha hecho para proteger su propia red doméstica personal y cómo era antes?
Probablemente el más grande:
UTILICE LAS CARACTERÍSTICAS DEL SISTEMA EN EL QUE ESTÁ . Tenga en cuenta la seguridad, pero siempre trate de utilizar la tecnología estándar de la industria para crear su solución. En otras palabras, no reinvente la rueda, porque es poco probable que su invención de la rueda sea tan buena como la que ha existido y ha sido probada.
En otras palabras, no escriba su propio ORM si la plataforma web en la que se encuentra ya tiene uno, no cree sus propias rutinas de paso de mensajes en subprocesos si ya hay una manera de hacerlo, no cree un servicio solo para construir un servicio, reutilice la mayor cantidad de código de biblioteca posible.
NUNCA escriba su código de tal manera que tenga privilegios SA o SYSTEM (SQL Server y Oracle Respectivamente). A menos que sea absolutamente necesario, evite tener que usar privilegios elevados (encuentre alternativas de privilegios más bajos para lograrlo de la misma manera).
Tenga en cuenta los desbordamientos del búfer, especialmente si está en código no administrado. Siga los procedimientos de seguridad correctos (exija solo lo que necesita y nada más, y no haga nada más de lo que se le pidió). No agregue funciones por el simple hecho de agregar funciones. ENCRYPT contraseñas con sales: no almacene contraseñas sin cifrar o sin cifrar en una base de datos.
Hay otros, pero estos son los más obvios que vienen a la mente.
¡La mejor de las suertes!
Aleksei