Jump to: navigation, search

Difference between revisions of "EclipseLink/FAQ/Security"

(New page: == Is SQL generated by EclipseLink vulnerable to SQL injection attacks? == No, EclipseLink generated SQL is not vulnerable to SQL injection attacks. SQL injection attacks occur when param...)
 
 
Line 17: Line 17:
  
 
It should go without saying that it is never recommended to expose the native SQL to an application user, doing so would be similar to exposing JDBC API to an application user.  At this point it is no longer an injection attack issue, and more about allowing end users the capability to run any SQL on your Database.   
 
It should go without saying that it is never recommended to expose the native SQL to an application user, doing so would be similar to exposing JDBC API to an application user.  At this point it is no longer an injection attack issue, and more about allowing end users the capability to run any SQL on your Database.   
 +
 +
== Does EclipseLink store my clear text passwords anywhere? ==
 +
 +
EclipseLink does not store passwords any persistent store, including files or database.  When EclipseLink is handed a clear text password, it is first encrypted before being stored in memory.  Before it is passed to the DB, it is decrypted. 
 +
 +
Application developers also have the option to encrypt the password before giving it to EclipseLink, in which case EclipseLink will decrypt it before setting it in JDBC.
 +
  
 
[[Category:EclipseLink FAQ|Security]]
 
[[Category:EclipseLink FAQ|Security]]

Latest revision as of 15:36, 15 January 2013

Is SQL generated by EclipseLink vulnerable to SQL injection attacks?

No, EclipseLink generated SQL is not vulnerable to SQL injection attacks. SQL injection attacks occur when parameters exposed to an end user are designed in such a way to execute potentially harmful SQL.

e.g.

"SELECT * FROM users WHERE name = '" + userName + "';" 

is vulnerable to an injection attack because passing in a user name of "a';DROP TABLE users;SELECT * from users where name = 'a"

Produces SQL like this:

SELECT * FROM users WHERE name = 'a';DROP TABLE users;SELECT * from users where name = 'a';

The SQL that is generated by EclipseLink prevents these types of attacks in two main ways.

  • prepared statements. EclipseLink supports (and defaults to) binding all SQL parameters. As the SQL is computed before the parameter is passed in, parameterized statements are an effective mechanism for preventing SQL injection (in most resources on preventing injection attacks, prepared statements is the number one recommended solution).
  • escaping single quotes. If the application chooses to have prepared statements turned off, EclipseLink parses parameters for ' and escapes them. The escaping of the ' means that the resulting SQL will no longer pose a threat to the database (using the above example, the SQL would look something like this:
SELECT * FROM users WHERE name = `a``;DROP TABLE users;SELECT * from users where name = ``a`;

There does exist within EclipseLink a mechanism to allow application developers to query directly using native SQL instead of having EclipseLink generate SQL. Applications executing raw SQL through EclipseLink must guard against SQL injection as they are bypassing the SQL injection defenses employed by EclipseLink .

It should go without saying that it is never recommended to expose the native SQL to an application user, doing so would be similar to exposing JDBC API to an application user. At this point it is no longer an injection attack issue, and more about allowing end users the capability to run any SQL on your Database.

Does EclipseLink store my clear text passwords anywhere?

EclipseLink does not store passwords any persistent store, including files or database. When EclipseLink is handed a clear text password, it is first encrypted before being stored in memory. Before it is passed to the DB, it is decrypted.

Application developers also have the option to encrypt the password before giving it to EclipseLink, in which case EclipseLink will decrypt it before setting it in JDBC.