Use of TCP/binary communications in JNBridgePro potentially exposes certain security vulnerabilities. In .NET-to-Java projects, for example, the Java side awaits requests from clients to execute Java APIs and return results. Ideally, these clients are .NET applications under your control, accessing the .NET side through proxies that you have created. However, it is possible for a malicious application to act as a client, accessing the Java side through JNBridgePro’s TCP/binary protocol. Proxies are not required (nor is .NET), and even APIs that have not been proxied can be accessed; in particular, the Runtime.exec() API can be called, leading to the ability to execute arbitrary code on the Java-side machine. A similar vulnerability exists when using TCP/binary communications in Java-to-.NET projects to access the .NET-side machine.

In order to avoid these vulnerabilities, JNBridgePro offers a number of security features, some of which were introduced starting with JNBridgePro version 10.1. With the exception of shared memory, these features are turned on by default. While you may turn them off, you should be aware of the risks involved, and should be confident that you are otherwise mitigating these vulnerabilities.

The following is a summary of JNBridgePro’s security features:

• Shared memory: The most secure way to use JNBridgePro is through shared memory, in which the .NET and Java sides run in the same process, and in which communications between the two sides is through shared data structures rather than through sockets. Because the remote Java or .NET side is not exposed to the network through sockets, the TCP/binary vulnerability does not exist. If use of shared memory is feasible for your scenario (i.e., you have exactly one .NET side and one Java side in your application, and they reside on the same machine), you should always use it. In addition to better security, shared memory is also much faster than TCP/binary communications, and (unlike with TCP/binary) shared memory automatically starts the remote Java or .NET side when the application starts, and shuts it down when the application ends.
• SSL communications: If TCP/binary communications must be used, consider using SSL (Secure Sockets Layer) for the connection between the Java and .NET sides. JNBridgePro’s implementation of SSL in TCP/binary requires both client and server authentication. This guarantees that a JNBridgePro client (the Java or .NET side making the cross-platform calls) is communicating with the intended server (the .NET or Java side responding to the cross-platform calls) rather than some malicious server acting in its place, and it also guarantees that only authorized JNBridgePro clients that possess the appropriate credentials can access the server. It also guarantees an encrypted connection between the .NET and Java sides. SSL is not turned on by default when TCP/binary communications is used, and once it is turned on, it must be configured before it will work. For instructions on configuring SSL, see the sections “Secure communications using SSL” in the .NET-to-Java and Java-to-.NET chapters in the Users’ Guide.
• Class whitelisting: An effective way to mitigate the TCP/binary vulnerability is to limit the APIs that can be accessed from a remote client. JNBridgePro allows you to specify a whitelist of classes whose APIs can be accessed remotely. Accesses to any classes not in the whitelist will be rejected and an exception will be thrown. A judiciously chosen whitelist containing only those classes that your clients will be accessing will substantially mitigate the risks of the TCP/binary vulnerability, but it is still possible for a malicious client to access whitelisted classes. If that poses a risk because those classes implement sensitive APIs, then you should use class whitelisting together with SSL. Class whitelisting is turned on by default, and a class whitelist file should be supplied if you want to whitelist more than the small list of classes that are always whitelisted. Class whitelisting can be turned off, but this must be done explicitly. For instructions on class whitelisting and how to configure it, see the sections “Class whitelisting” in the .NET-to-Java and Java-to-.NET chapters in the Users’ Guide.
• IP whitelisting: One rudimentary way to mitigate the TCP/binary vulnerability is to limit the hosts from which a Java-side or .NET-side server will accept cross-platform requests. JNBridgePro allows you to specify a whitelist of those IP addresses from which requests will be accepted; requests from all other hosts will be rejected. The whitelist can include wildcards, so that subnets and other ranges can be whitelisted. IP whitelisting does not prevent access by malicious clients residing on the whitelisted hosts, so it should generally be used in conjunction with other security features like SSL and class whitelisting. IP whitelisting is turned on by default, with requests only accepted from clients on the same machine as the server. It can be explicitly turned off by supplying a complete wildcard whitelist, but you should only consider doing this if you are using SSL and/or class whitelisting, or have extreme confidence in your computing environment, including (but not restricted to) a properly configured network firewall. For instructions on IP whitelisting, see the sections “Whitelisting .NET clients” and “Whitelisting Java clients” in the Users’ Guide.

Note that the JNBridgePro proxy generation tools use TCP/binary communications along with same-host IP whitelisting and a highly-restricted class whitelist, so use of TCP/binary in this context should be considered safe.