1

I am working on Java application which generate SQL prepared statements and stored procedure query strings using user inputs and executes with PreparedStatement.execute() or CallableStatement.execute() Example:

String query = "{? = call UserSuppliedStoredProcName(?,?)}"
conn.prepareCall(query)

assuming a user can insert SQL clause in the variable query , can it be exploited via prepare call ?

String query = "{? = call UserSuppliedStoredProcName(?,?)} or select * from login_table"
String query = "{? = call UserSuppliedStoredProcName(?,?)} AND select * from login_table"
String query = "{select * from login_table UNION ? = call UserSuppliedStoredProcName(?,?)}"
String query = "{sleep(1) or ? = call UserSuppliedStoredProcName(?,?)}"
manish sardiwal
  • 11
  • 2
  • There's some info here: https://security.stackexchange.com/questions/230211/why-are-stored-procedures-and-prepared-statements-the-preferred-modern-methods-f/230248#230248 – paj28 May 10 '20 at 21:03
  • I take it that `UserSuppliedStoredProcName` comes from an untrusted source. If so, this does look injectable. I'm not familiar with curly braces in SQL, but injecting something like `foo(1,2)}; update users set password='bar' where username='admin';` could be very damaging. – paj28 May 10 '20 at 21:07
  • @mentallurg The curly braces are a JDBC thing. – Tom Hawtin - tackline May 11 '20 at 12:45
  • Thank you all. Procedure name and input parameters controlled by user. I tried some cases like "{select * from login_table UNION ? = call UserSuppliedStoredProcName(?,?)}", such cases were failed to parse in SQL syntax. @paj28 foo(1,2)}; update users set password='bar' where username='admin'; is throwing syntax error, I am assuming there might be some case where attacker can pass a valid SQL syntax along with procedure call. – manish sardiwal May 11 '20 at 14:03
  • You might be able use a subquery like `UserSuppliedStoredProcName((select user from user)` It may be that it's only possible to read not update through this injection. If that doesn't work, do not conclude that this is non-exploitable. You can probably keep tweaking the exploit until it works although I'm not prepared to help you further with that. To fix this, I think you can't use a question mark parameter for the stored procedure name. Probably best to whitelist validate that so only a-zA-Z is allowed. – paj28 May 11 '20 at 16:58

0 Answers0