Re: simple (?) question about having ";" in the password
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 4 Sep 2005 11:34:20 +0100
Jimi Hullegård wrote:
> > [me:]
> > BTW, if the reason you are having difficulty is that you are attempting
> > to create SQL insert/update queries on-the-fly by concatenating strings
> > with the
> > user-supplied password (or any other user-supplied input) then you
> > shouldn't
> > be. **NEVER** do that. (it should -- IMO -- be a firing offence, at
> > least for
> > senior staff, and a one-last-warning for junior).
> I would agree that this is really stupid. But what if the input is
> validated first, say using a regular expression like:
>
> if (!username.matches("^[a-zA-Z]+$") || !password.matches("^[a-zA-Z]+$") )
> {
> throw new BadUsernameOrPasswordException();
> }
>
> Whould that still be error prone?
I would say that it is still a Very Bad Thing To Do.
Consider the case in question. By "validating" you have just made it
impossible for the user to choose even a minimum standard of security.
Sensible systems might well use a regexp like yours, but the check
would be there in order to /refuse/ to allow the user to set such a weak
password.
The same problem also occurs with names (ask anyone called O'Connor), and all
sort of other fields. The typical programmer's next instinct is to try to
sanitise input by allowing special characters, but escaping them before adding
them to the SQL string. This, above all, is where I would be handing out exit
cards. Attempting to escape SQL strings is a non-starter. Few people know
/exactly/ what the syntax of their particular SQL engine is (including how it
responds to Unicode characters, and characters outside the printable ASCII
range). Fewer still know how many of those details are due to bugs that might
be fixed without warning in a later release (of the DB engine, or of the JDBC
connection). Not that many programmers are capable of turning that knowledge
into a 100% accurate algorithm, even if they had it. As an approach it is
unsafe (which is unforgivable), slow (which is stupid), and very, very
complicated (which is even stupider).
The rule is, don't ever construct SQL from untrusted sources. There is an easy
and efficient way of handling this kind of thing (parameterised statements).
Use them.
Always.
(BTW, remember that if you are attempting to sanitise input "by hand", then
"untrusted sources" includes /all/ other components of the system -- including
data that is already in the DB -- since although that source may be a trusted
part of the enterprise, there is no guarantee that it used the /same/
hand-written validation as you are relying on).
> I guess the prefered way is that first validate the input, and then (to be
> on the safe side), using prepared statements, like this:
>
> PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM users WHERE
> username LIKE '?' AND password LIKE BINARY '?'"
> pstmt.setString(1, username);
> pstmt.setString(2, password);
> pstmt.execute();
>
> Is there something in this method that is unsecure?
That's the correct way to do it.
If you are really paranoid (which may well be a completely appropriate state of
mind for anyone writing web-facing code), then it /might/ be worth adding a bit
of validation to the logic before using the prepared statement. The point of
that would not be that it makes the SQL itself safer (it does not, and there is
no need for it to do so), but in order to ensure that strangely-crafted strings
do not appear in the system's log files (and similar). There have been
documented attacks (sorry, I can't remember the detail, nor whether they were
real attacks, or proof-of-concept discussions) where some log file viewer might
have a bug (such as the inevitable buffer overflows) that made /viewing/ the
log unsafe, even though the system was otherwise working perfectly....
That's pretty extreme, though, and I certainly wouldn't criticise even a very
senior programmer who didn't consider that kind of paranoic over-compensation.
(Although security-minded thinking, /in general/, should be part of every
programmer's mind-set.)
-- chris
.
- Follow-Ups:
- Re: simple (?) question about having ";" in the password
- From: Jimi Hullegård
- Re: simple (?) question about having ";" in the password
- References:
- Re: simple (?) question about having ";" in the password
- From: Jimi Hullegård
- Re: simple (?) question about having ";" in the password
- Prev by Date: Re: Method chaining with generics
- Next by Date: Re: Efficient hashmap serialization?
- Previous by thread: Re: simple (?) question about having ";" in the password
- Next by thread: Re: simple (?) question about having ";" in the password
- Index(es):
Relevant Pages
|
