Let's say you have a Java app which has a query which can unlock/reset passwords for users like:

ALTER USER " + iD_Of_User.toUpperCase() + " IDENTIFIED BY " + password_Of_User + " ACCOUNT UNLOCK

Where iD_Of_User and password_Of_User definitely come in directly from an HTTP request.

This is a pretty textbook SQL injection risk-- we're passing incoming, untrusted data directly to a query. However, when I try to parameterize the query-- I get an error when I try to use a PreparedStatement object to parameterize the dynamic values... I guess PreparedStatement's parameters can only be used for data values? And the ALTER query here is not using the values that way.

I don't think input validation is even possible here-- maybe on the iD_Of_User value, but almost certainly not on the password_Of_User value (which is sometimes used as a password reset-- so it's only restrictions are the Oracle 12c password standards).

Any help were would be greatly appreciated. I reviewed this post, but it didn't give me a good solution. I'm hoping someone knows of a good way to do password resets/account unlocks in Oracle which doesn't open the app up to SQL injection.

  • 1
    I'm voting to close this question as off-topic because it is cross-posted – schroeder Nov 18 '19 at 22:05
  • 1
    Please do not cross-post. If required, the other stack might migrate it here. – schroeder Nov 18 '19 at 22:06
  • 1
    you can flag your posts for migration – schroeder Nov 19 '19 at 7:29
  • 1
    You cannot do this, for the reason that ALTER USER isn’t a query so it doesn’t go through the query planner so PreparedStatement is irrelevant. You can validate the username using a PreparedStatement however (SELECT FROM dba_users). And instead of accepting a new password you could generate a new one and tell the user what it is. If someone wants to unlock this question I’ll post this as the answer. – Gaius Nov 19 '19 at 9:43
  • 1
    This question could also be reopened if reworded like "How can an attacker use SQL injection in ALTER query?/What can an attacker do with an injectable ALTER statement?" or so, like security.stackexchange.com/questions/44151/… does If reworded this way, then it should be reopened IMO : migrating it seems a bad idea, as I (we?) wouldn't answer the "right way to code this", but we would answer the "how can this be exploited" (thos there is a fun way to exploit this query :) ) – Xenos Nov 19 '19 at 10:27