Reino: API Abuse

Un API es un contrato entre un autor de llamada y un receptor de llamada. Las formas de abuso de API más comunes los produce el autor de llamada cuando no consigue atender su fin de este contrato. Por ejemplo, si un programa no consigue llamar chdir() después de llamar chroot(), se viola el contrato que especifica cómo cambiar el directorio de origen activo de una forma segura. Otro buen ejemplo de un abuso de manual es esperar que el receptor devuelva una información de DNS de confianza al autor de llamada. En este caso, el autor de llamada abusa el API del receptor haciendo determinadas suposiciones sobre su comportamiento (que el valor de retorno se puede usar con fines de autenticación). También se puede violar el contrato entre el autor de llamada y el receptor desde el otro lado. Por ejemplo, si un codificador envía SecureRandom y devuelve un valor no aleatorio, se viola el contrato.

Code Correctness: Incorrect Serializable Method Signature

Abstract
Si se utiliza la firma de método incorrecto en un método de serialización, puede que nunca se llame a dicho método.
Explanation
Corrección del código: se producen problemas de firma incorrecta del método serializable cuando una clase serializable crea una función de serialización o deserialización pero no sigue las firmas correctas:


private void writeObject(java.io.ObjectOutputStream out) throws IOException;
private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
private void readObjectNoData() throws ObjectStreamException;


Una desviación de las firmas del método que requiere la serialización puede provocar que nunca se llame al método durante la serialización o deserialización. Esto supondría una serialización o deserialización incompleta o podría permitir que un código que no es de confianza obtenga acceso a los objetos.
En el caso de que se produzcan excepciones no arrojadas, puede significar que la serialización o deserialización está fallando y bloqueando la aplicación o que podría incluso fallar discretamente. En tal caso, los objetos se crearían correctamente solo en parte y se producirían errores muy difíciles de depurar. El autor de la llamada deberá filtrar estas excepciones de manera que la serialización o deserialización incorrectas puedan tratarse correctamente sin la presencia de bloqueos o de objetos creados parcialmente.
References
[1] SER01-J. Do not deviate from the proper signatures of serialization methods CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
desc.structural.java.code_correctness_incorrect_serializable_method_signature