% hack in password field

[D E]

I created a user-name password html form to connect to Access 2000
(JDBC-ODBC) database.

queryString = "SELECT Name FROM tblUser WHERE UserID LIKE '" + getLoginId +
"' AND Password LIKE '" + getPassword+ "'";

How do I overcome the hack where users simply add "%" in the password field
and get admin privileges?

 

[Christophe Vanfleteren]

I created a user-name password html form to connect to Access 2000
(JDBC-ODBC) database.

queryString = "SELECT Name FROM tblUser WHERE UserID LIKE '" + getLoginId
+ "' AND Password LIKE '" + getPassword+ "'";

How do I overcome the hack where users simply add "%" in the password
field and get admin privileges?

Use PreparedStatements:

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html

 

[Roedy Green]

queryString = "SELECT Name FROM tblUser WHERE UserID LIKE '" + getLoginId +
"' AND Password LIKE '" + getPassword+ "'";

How do I overcome the hack where users simply add "%" in the password field
and get admin privileges?

why are you using the keyword LIKE at all?

 

[Chris Uppal]

queryString = "SELECT Name FROM tblUser WHERE UserID LIKE '" + getLoginId
+ "' AND Password LIKE '" + getPassword+ "'";

Never, ever, *ever*, create SQL statements by concatenating user-supplied
strings!

Even with the best will in the world (i.e. not *intending* to hack into, or
break, your application) users will type in stuff that breaks.

Using prepared statements (as already mentioned) is the correct way to do it.

-- chris

 

[D E]

thanks all... i DO appreciate your warnings and stuff and will gratefully
heed your advice..

 

[Chris Smith]

Use PreparedStatements:

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html

Actually, no. Or rather, yes do use PreparedStatement, but don't expect
it to solve this problem. A '%' in a LIKE pattern for a
PreparedStatement works just as well as a '%' in a LIKE pattern for any
other SQL statement.

So use PreparedStatement, and also verify (using String.indexOf) that
the username and password doesn't contain a '%' -- or don't use LIKE at
all. Why would you want to compare passwords with LIKE anyway?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Mladen Adamovic]

I suggest using
String new_mem_id=mem_id.replaceAll("[^A-Za-z0-9_]","");

 

[FD]

I suggest using
String new_mem_id=mem_id.replaceAll("[^A-Za-z0-9_]","");

Never, ever, *ever*, create SQL statements by concatenating user-supplied
strings!

And more, never ever use "LIKE" operator for such critical datas like userid
and password, only strict '='.

all. Why would you want to compare passwords with LIKE anyway?

Yes, why ?

 

[Tony Morris]

Read up on "SQL Injection".
Your solution looks like it is prone to this trivial, and common attack.
java.sql.PreparedStatement solves a lot of this problem.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Chris Smith]

Read up on "SQL Injection".
Your solution looks like it is prone to this trivial, and common attack.
java.sql.PreparedStatement solves a lot of this problem.

And I'll again repeat that PreparedStatement still doesn't prevent the
inclusion of the '%' character in a string that's compared with the LIKE
operator. To use LIKE, you'd still need to do some kind of analysis to
be sure the input string is an acceptable pattern.

And I'm still wondering why someone would want to do pattern matching on
a password field.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

And I'll again repeat that PreparedStatement still doesn't prevent the

inclusion of the '%' character in a string that's compared with the LIKE
operator.

Agreed

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

Agreed

yes, but if you are using LIKE, isn't % one of the things you would
expect?

Why are you using LIKE?

I suppose you could do an indexOf('%') to filter naughty requests. Is
this a real problem or a theoretical one?

 

[Chris Smith]

yes, but if you are using LIKE, isn't % one of the things you would
expect?

Why are you using LIKE?

In this case, I don't know; but the OP was using LIKE and worried about
interjected '%' characters. Needed to be pointed out that the common
response (use PreparedStatement) wouldn't solve the problem that the OP
was asking about. I would guess that the OP was using LIKE because of
some other belief about its functionality, such as that is might perform
a case-insensitive comparison (which may even be true with some DBMSs
that do stuff like that; it sounds like the kind of irregular "helpful"
feature you'd find in Access).

In general, though, it's sometimes necessary to find when a given (user
input) string is a substring of a field. In that case, I'd be tempted
to search for wildcard characters ('%' or '_') in the input string
before writing the query. Frankly, I wouldn't know how to deal with it
anyway; is it possible to escape a wildcard character in a LIKE
operator? Every time I've needed to do this, the presence of those
characters represented a validation error, hence I haven't needed to
solve the problem.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[D E]

theoretical problem... school project... professor said in real life, LDAP
is used... The real meat of the project didn't really involve methodolgies
of logging in... But i am curious actually... your answers are very
informing.. thanks...

 

[Lee Fesperman]

In this case, I don't know; but the OP was using LIKE and worried about
interjected '%' characters. Needed to be pointed out that the common
response (use PreparedStatement) wouldn't solve the problem that the OP
was asking about. I would guess that the OP was using LIKE because of
some other belief about its functionality, such as that is might perform
a case-insensitive comparison (which may even be true with some DBMSs
that do stuff like that; it sounds like the kind of irregular "helpful"
feature you'd find in Access).

Yes, case-insensitive comparison with LIKE is non-standard.

In general, though, it's sometimes necessary to find when a given (user
input) string is a substring of a field. In that case, I'd be tempted
to search for wildcard characters ('%' or '_') in the input string
before writing the query. Frankly, I wouldn't know how to deal with it
anyway; is it possible to escape a wildcard character in a LIKE
operator? Every time I've needed to do this, the presence of those
characters represented a validation error, hence I haven't needed to
solve the problem.

In SQL92, you can use the optional ESCAPE clause to specify the escape character. For
example,

password LIKE '/%' ESCAPE '/'

There is also a form of the JDBC (ODBC) extension syntax using "{" for specifying the
escape character for LIKE.