Re: simple (?) question about having ";" in the password

"Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:431ad0be$3$38044$bed64819@xxxxxxxxxxxxxxxxxxxx
> Jimi Hullegård wrote:
>
>> [...] 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.

Now I don't follow. What is a "minimum standard of security"? Are you
talking about the fact my regex only approves regular letters? That was only
an example. If the regex also would approve numbers, all basic punctuation
marks (besides any that might be missinterpreted by the DB) and other basic
typographical symbols like & * @ # $ % / ( ) - _ < > ^ ~, whould you still
consider this a Very Bad Thing To Do? If so, I don't agree with you. I would
think that if the user can create passwords like:
pL9SD(ndk(!nfn??m3n#
then I wouldn't say that I have made it impossible for the user to choose
"even a minimum standard of security". Now ofcourse it's prefered to do some
check to see if the password is too weak, but that is a different story.

> 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.

Now, that I agree with. IF there is any reason to suspect that the user
might want to use any "special" character, then ofcourse I would use a
prepared statement. But was I meant was in many cases it I think its logical
to simply "forbid" any characters besides some safe ones. In the case of a
username, for example.

> 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.

Now I'm curious. If you get an simple int as an input from an untrusted
source, would you still use a parameterised statement instead of simple
doing something like the code below?

.....
if (imageId < 1 || imageId > SOME_HIGH_NUMBER)
{
throw new InvalidInputException();
}
rs = stmt.executeQuery("SELECT * FROM images WHERE imageId=" + imageId);

If so, would that be because you have a principle to always use a
parameterised statement, or do you still see a security issue here?

> (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).

Are you saying that using parameterised statement can prevent that? Because
there might be several reasons to validate the input. Lets say that we have
a social security number (SSN) field in the database. I assume that the SSN
where you live (I live in Sweden) looks in a certain way, and that it can be
tested for validity* using some algorithm. Now it makes sense that the
application checks the SSN for validity before it inserts it into the DB.
But parameterised statement or not, there is still no guarantee that someone
has not entered an invalid SSN using some other method (maybe using direct
access to the DB, and writing the insert statement by hand).

By the way, I never talked about sanitising input. Instead I talked about a
simple check to see if the input is OK or not.

* A "valid SSN" would be a SSN that follows a certain pattern, it doesn't
necessarily mean that it is an "active" SSN.

Regards
/Jimi


.