Defensive Java Programming Notes (05 of 11) SQL Injection

  • strict warning: Non-static method view::load() should not be called statically in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_argument.inc on line 744.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
Leeland's picture

Problem: Embedding user input into SQL queries is BAD!

String SQL = "SELECT Username, Password " +
  "FROM users " +
  "WHERE Username='" + Username + "' " +
  "AND Password ='" + Password + "'";
s.execute(SQL)

So what if in the password field you put in: X' OR 1=1; --

That will turn the SQL statment into:

SELECT Username, Password FROM users WHERE Username='InputName'
 AND Password ='X' OR 1=1; --';

Which will actually select every Username and Password from the database, possibly displaying it out. Now you have completely bypassed the password check for any given account.

So you need to be real stingy on permissions. Also watch out for database provided stored procedures because if they are there they can be called.

The way around this is to properly use:

  • Stored Procedures
  • Prepared Statements
  • Parameterized Queries

Challenge is figuring out how to manipulate the SQL to get what is needed. But the key ingredients of real crackers are:

  • Knowledge
  • Patience
  • Persistence
  • Imagination

Problems with Stored Procedures
Any database system that provides stored procedure support generally comes with built in stored procedures. You really should review them and if you don't need them delete them. MS SQL comes with a LOT of integrated stored procedures to make running commands easy. Oracle doesn't provide stored procedures by default (you have to turn them on). If an attacker can get access to certain stored procedures compromising the system becomes a lot easier.

One of the most dangerous stored procedures is in MS SQL Server and is called xp_cmdshell. This little treasure allows you to run command line programs from with SQL scripts on the server WITH THE PERMISSIONS OF THE DATABASE USER. So all the attacker has to do is figure out how to use SQL injection to get the server to run "EXEC master..xp_cmdshell'dir/del/format C:'"

Thread Slivers eBook at Amazon