Re: simple (?) question about having ";" in the password
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 7 Sep 2005 11:25:03 +0100
Jimi Hullegård wrote:
> > [me:]
> > 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.
Yes. The problem is that for security, the user should be allowed to use
whatever characters they damn well please. If you start putting restrictions
on what characters can be used, how are you going to explain to them, in
/their/ terms, what cannot but seem an arbitrary restriction ?
It is, I would say, simply unprofessional to do anything less. And --
remember -- the only reason for the restriction is that the programmer wants to
use an inherently less safe (and only marginally more convenient) programming
technique. Pure laziness.
Oh, before I go on, I should explain that when I used (and use) the term
"validation", I'm /only/ referring to checking the input for values that would
compromise security (or otherwise break the DB access). There will, of course,
be a need for business-logic-style validation, but I'm not interested in that
for these purposes. I should have made that clear in my earlier post, sorry.
> > 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.
This is what I don't like. You are (or rather, you /seem/ to be, judging by
the above comment) taking the view that assembling SQL from code is the normal
practise, and that using prepared statements is the fall-back technique that
should be used only when necessary. That's /exactly/ the attitude I would like
to see stamped out. The security lists are alive with reports of SQL injection
attacks; it seems that DB programmers are no more able to eliminate that
vulnerability from their coding habits that C programmers are able to avoid
buffer overflows. This issue is not theoretical, it is not even rare, it is a
serious problem. Yet avoiding SQL-injection is /easy/, if you do it right by
habit, and never, never, never, even /think/ about assembling SQL from code.
Put simply, what I'm trying to say is that programmers should never ask
themselves "do I need to use a prepared statement here ?".
Incidentally, I'm not so sure that it /is/ OK just to forbid certain characters
in user names. I've already mentioned the example of O'Connor. Do /you/ know
enough about the world's writing systems that you can specify a reasonable
range of characters that are acceptable from a Chinese customer, say ? And do
you know enough about your DB's parser (including bugs, and not only now, but
in future revisions) that you can be sure that none of them will be
interpreted as syntax ? More to the point, do you think that the average
working DB programmer knows enough about such issues to be entrusted with a
serious security decision based on that knowledge ?
> > 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?
I don't even want to think about it. That's what I'm trying to say.
(
Actually, and to be honest, I can't see too many problems with accepting an
untrusted integer, and I might well "allow" myself to take a short cut in such
a case. It's not too likely, though, since it's not too common to have a SQL
statement that doesn't also include a string -- so a prepared statement would
be mandatory anyway.
Oh, and consider this scenario. We start off with getting an untrusted integer
from some source -- say a web form input that has been parsed to turn the
strung '45' into 45.
Now someone decides that parsing the string is a waste of time (a mistake, IMO,
but it could happen) since its going to be added to the SQL string. So they
make a trivial change to the code that simply appends the string to the SQL,
but don't use a prepared statement...
)
-- chris
.
- References:
- Re: simple (?) question about having ";" in the password
- From: Jimi Hullegård
- Re: simple (?) question about having ";" in the password
- From: Chris Uppal
- Re: simple (?) question about having ";" in the password
- From: Jimi Hullegård
- Re: simple (?) question about having ";" in the password
- Prev by Date: Re: JNI's throw new does not throw an exception
- Next by Date: Re: Is it possiable? Create object via parameter?
- Previous by thread: Re: simple (?) question about having ";" in the password
- Next by thread: Filesystem type checking
- Index(es):
Relevant Pages
|
