rspec/rules/S2655/java/rule.adoc

== Why is this an issue?

The JEE standard forbids the direct management of connections in JEE applications.
The application code should not directly create, manage, or close database connections.
Instead, the application code should use the connection pool managed by the container via `DataSource` objects.

The container is responsible for creating and managing the connection pool,
as well as monitoring the usage of connections and releasing them when they are no longer needed.
By delegating connection management to the container, JEE applications can avoid connection leaks and resource exhaustion and ensure that database connections are used efficiently and securely.

When an application manages connections directly, connection leaks may arise.
These leaks occur when an application fails to release a database connection after it has finished using it.
Another risk is vulnerability to SQL injection attacks, which occur when an attacker is able to inject malicious SQL code
into an application's database queries, allowing them to access or modify sensitive data.
Finally, these applications have difficulty managing and monitoring database connections.
Without a centralized connection pool, tracking the usage of database connections and ensuring they are used efficiently and securely can be challenging.

This rule raises an issue for using a `DriverManager` in a servlet class.

== How to fix it

Replace usage of `DriverManager` with a `DataSource` obtained via JNDI lookup.

=== Code examples

==== Noncompliant code example

[source,java,diff-id=1,diff-type=noncompliant]
----
private static final String CONNECT_STRING = "jdbc:mysql://localhost:3306/mysqldb";

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException  {

  Connection conn = null;
  try {
    conn = DriverManager.getConnection(CONNECT_STRING);  // Noncompliant
    // ...
  } catch (SQLException ex) {...}
    //...
  }
}
----

==== Compliant solution

[source,java,diff-id=1,diff-type=compliant]
----
private static final String DB_LOOKUP = "jdbc/mainDb";

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException  {

  Connection conn = null;
  try {
    InitialContext ctx = new InitialContext();
    DataSource datasource = (DataSource) ctx.lookup(DB_LOOKUP);
    conn = datasource.getConnection();
    // ...
  } catch (SQLException ex) {...}
    //...
  }
}
----


== Resources

=== Documentation
* https://cwe.mitre.org/data/definitions/245[MITRE, CWE-245] - J2EE Bad Practices: Direct Management of Connections

* https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/javax/sql/DataSource.html[Oracle SDK 20 - javax.sql.DataSource]

=== Articles & blog posts

* https://owasp.org/www-community/attacks/SQL_Injection[OWASP - SQL Injection]

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Use a JNDI-supplied DataSource instead.


'''
== Comments And Links
(visible only on this page)

=== on 27 Feb 2015, 20:14:42 Ann Campbell wrote:
\[~nicolas.peru] I've written this rule more narrowly than the CWE example shows: i.e. I've written that we'll raise an issue when a servlet class uses ``++DriverManager++``, but the CWE example shows a delegate class being used to interact with ``++DriverManager++``. 


I'm guessing that detecting this case as well will take CFG?

=== on 13 Apr 2015, 14:48:39 Nicolas Peru wrote:
\[~ann.campbell.2]just to be sure of my understanding : you are talking about a servlet using a class of the project using ``++DriverManager++`` ? 


This is not related to CFG, but more to an analysis of what is in the project or not. We can find way to do it but it is not easy given the current implementation of things right now to know if a class is defined in the project or not. 


I would probably stick to this simpler implementation as a first step.

=== on 20 Jul 2015, 07:37:26 Ann Campbell wrote:
Tagged java-top by Ann

endif::env-github,rspecator-view[]