Los desbordamientos de búfer, como se mencionó, no son posibles en Java. Hay matrices de Java (bytes) que se asignan más o menos directamente a la memoria, pero todos los accesos a la matriz tienen límites comprobados (arroja un IndexOutOfBoundsException
si alguien está leyendo más allá de los límites. Esta es una verificación de tiempo de ejecución, por supuesto. Referencias en lugar de punteros ( NullPointerException
es un nombre poco apropiado). La aritmética de punteros no se admite. Por supuesto, por lo general no se captura IndexOutOfBoundsException
, por lo que aún se puede usar para realizar un ataque de denegación de servicio.
Eso no significa que Java no sea vulnerable a otros errores de programación. Puede terminar con un error relacionado con la memoria si pierde recursos, por ejemplo.
Para obtener buenas prácticas de codificación, eche un vistazo, por ejemplo, a las prácticas de codificación de Google . Estos especifican principalmente prácticas relacionadas con la sintaxis. Para obtener información general sobre la semántica de la programación Java, al menos debe leer Java efectivo .
Muy poca gente los usa, pero es una buena idea realizar un análisis de código estático en el código fuente generado y en el código de bytes. Dos herramientas bien conocidas son CheckStyle para el código fuente y FindBugs para el código de byte. Puede ser rentable y utilizar aplicaciones especiales que también pueden realizar pruebas automatizadas de código. Hay una gran cantidad de empresas que se especializan en, por ejemplo, pruebas estáticas. Muchas de estas compañías realizan análisis de este tipo de forma gratuita para aplicaciones de código abierto .
Debe tener pruebas de JUnit , al menos para cualquier clase de biblioteca que escriba. Se recomienda realizar cobertura de código para sus pruebas de unidad. Dejaré de lado otras prácticas, como las pruebas de nivel de aplicación y la revisión de código, aparte de mencionar que existen. Para poder hacer todo esto, debe usar un sistema de versiones bien definido y crear un entorno. Si tiene más de un desarrollador, integración continua generalmente da sus frutos.
Una de las prácticas de seguridad más conocidas es no confiar en la entrada de su aplicación. Es posible que desee crear un análisis de amenazas separado para su diseño de seguridad.