Kingdom: API Abuse

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

5 items found
Weaknesses
Abstract
The program violates the Enterprise JavaBeans specification by using AWT/Swing.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard."

A requirement that the specification justifies in the following way:

"Servers do not allow direct interaction between an application program and a keyboard/display attached to the server system."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 575
desc.structural.java.ejb_bad_practices_use_of_awt_swing
Abstract
The program violates the Enterprise JavaBeans specification by using the class loader.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"The enterprise bean must not attempt to create a class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams."

A requirement that the specification justifies in the following way:

"These functions are reserved for the Enterprise Beans container. Allowing the enterprise bean to use these functions could compromise security and decrease the container’s ability to properly manage the runtime environment."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 578
desc.structural.java.ejb_bad_practices_use_of_classloader
Abstract
The program violates the Enterprise JavaBeans specification by using the java.io package.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean should exercise caution when using the Java I/O package to attempt to access files and directories in the file system."

A requirement that the specification justifies in the following way:

"The file system APIs are not well-suited for business components to access data. Files might not be accessible from all instances, or their content might be different on different instances, and coordinating updates to the file can be difficult. Business components should use a resource manager API, such as JDBC, to store data."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 576
desc.structural.java.ejb_bad_practices_use_of_java_io
Abstract
The program violates the Enterprise JavaBeans specification by using sockets.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast."

A requirement that the specification justifies in the following way:

"The Enterprise Beans architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean— to serve the Enterprise Beans clients."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 577
desc.structural.java.ejb_bad_practices_use_of_sockets
Abstract
The program violates the Enterprise JavaBeans specification by using thread synchronization primitives.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances, unless it is a singleton session bean with bean-managed concurrency."

A requirement that the specification justifies in the following way:

"This rule is required to ensure consistent runtime semantics because while some Enterprise Beans containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] THI01-J. Do not invoke ThreadGroup methods CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 574
desc.structural.java.ejb_bad_practices_use_of_synchronization_primitives