Stupid Audit Tricks

[Lee]

Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.


--

 

[Ivan Marsh]

Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.

Actually that's a bad cut and paste operation on your part... things that
are different aren't the same.

 

[Steve Swift]

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.

I totally agree. Humans (in my comprehensive survey of one, i.e. me) are
always adding leading and trailing whitespace. And you're right that
white*space* has to be stripped; about 10% of the time the trailing
character is a tab.

 

[Lee]

Ivan Marsh said:

Actually that's a bad cut and paste operation on your part... things that
are different aren't the same.

Of course it was, but bad cut and paste operations that
include extra spaces are invisible to the user. The web
page can easily detect them, and should. Instead, it
leaves the user trying to add the 8th character, and having
the field block it, for no obvious reason.

That's bad user interface design.


--

 

[Ivan Marsh]

Ivan Marsh said:

Of course it was, but bad cut and paste operations that include extra
spaces are invisible to the user. The web page can easily detect them,
and should.

That is a matter of opinion.

Instead, it leaves the user trying to add the 8th character, and having
the field block it, for no obvious reason.

No... the user in question is trying to add a ninth character as he's
already pasted eight characters into the field.

There absolutely IS a reason. An eight character field is an eight
character field. Not to mention this isn't a javascript gripe it's pure
browser interpretation of HTML where the max field length of the input
field is set to eight. Setting it to eight prevents the user from flooding
the field and protects against possible code injection.

That's bad user interface design.

That, again, is a matter of opinion. I'd say it's a user issue and has
nothing to do with design. What if the field is supposed allow whitespace?
For that matter, exactly how many unintentionally pasted characters should
the interface be designed to handle for it to be "good" interface design?
At what level of user incompetence does a design turn from "bad" to
"good"?

Id's say learn to use you mouse properly.

 

[Thomas 'PointedEars' Lahn]

[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation of
HTML where the max field length of the input field is set to eight.

True, therefore ...

Setting it to eight prevents the user from flooding the field and
protects against possible code injection.

.... this is utter nonsense.


PointedEars

 

[Ivan Marsh]

[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation
of HTML where the max field length of the input field is set to eight.

True, therefore ...

Setting it to eight prevents the user from flooding the field and
protects against possible code injection.

... this is utter nonsense.

As always, your input is irrelevant.

 

[Lee]

Ivan Marsh said:

That is a matter of opinion.

Yes, just as "the user shouldn't be confused by the interface"
is a matter of opinion. There aren't too many people willing to
argue that it's an incorrect opinion, though.

No... the user in question is trying to add a ninth character as he's
already pasted eight characters into the field.

There is no *obvious* reason. The user can't see the space.
The user didn't choose to include the space. Microsoft made that
judgment for him.

A user interface design that allows any situation in which the
user is scratching their head wondering why it won't allow their
input is bad. This is not rocket science, or even controversial
among people who've made any study of man-machine interfaces.

I post it to the Javascript newsgroup because we are frequently
asked how to "prevent the user from entering...". With very few
exceptions, any attempt to prevent the user from entering anything
they believe is reasonable is a bad design. You should accept
what they give you and, if it's not what you want, explain that
fact to them. Again, this is a very basic user interface design
principle. You certainly can't hide behind the idea of protecting
yourself from bad data if you know the first thing about programming.


--

 

[Thomas 'PointedEars' Lahn]

[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation
of HTML where the max field length of the input field is set to eight.

True, therefore ...

Setting it to eight prevents the user from flooding the field and
protects against possible code injection.

... this is utter nonsense.

As always, your input is irrelevant.

We will see how irrelevant it is the moment someone easily passes more than
8 characters for that field to your server-side script with you not being
prepared for it, especially when the intention of the person is a buffer
overflow or code injection.


PointedEars

 

[Gregor Kofler]

Ivan Marsh meinte:

As always, your input is irrelevant.

Let's face it: It's correct.

Why should a maxlength attribute provide "protection"? Maxlength
supports the user by giving an intrinsic feedback, that's all.

"Code injection"... I can override the maxlength, I can have standalone
scripts feeding the server.
With the same logic, you could also suggest to use hidden inputs for
storing classified data, since it won't be displayed.

Gregor

 

[marss]

That, again, is a matter of opinion. I'd say it's a user issue and has
nothing to do with design. What if the field is supposed allow whitespace?
For that matter, exactly how many unintentionally pasted characters should
the interface be designed to handle for it to be "good" interface design?
At what level of user incompetence does a design turn from "bad" to
"good"?

Id's say learn to use you mouse properly.

I agree with you, must always be reasonable balance between the
complexity/importance of the problem and complexity of the solution.
Especially, if the problem is far-fetched...

 

[Bart Van der Donck]

[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation
of HTML where the max field length of the input field is set to eight.

True, therefore ...

... this is utter nonsense.

As always, your input is irrelevant.

It's not irrelevant - your statement was incorrect the way it was
formulated. I think it's a good habit to use MAXLENGTH, but it gives
you no protection against the things you mention. The only useful
check on string length (in regard to security issues) must be
performed at server.

Then, for injection attacks, use the same filters that you used when
the password was generated (a common check is e.g. alphanumeric +
underscore, which should set you safe).

Most kinds of buffer overflows / flooding cannot be prevented anyhow
if the attacker is persevering enough.

 

[Bart Van der Donck]

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.

It would be a bit unreasonable to expect that from a web developer.

IMHO nor the user nor the web application is to blame. Microsoft
Windows should not add this space character. If a word is double-
clicked, I think Microsoft should select it without its leading/
trailing spaces. Maybe that is the "bad user design" here.

Perhaps Microsoft adds the space for easy pasting towards another
document were the space is then automatically added for easily typing
further. I can't think of any other reason.

 

[Ivan Marsh]

Ivan Marsh wrote:
[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser
interpretation of HTML where the max field length of the input field
is set to eight.

True, therefore ...

Setting it to eight prevents the user from flooding the field and
protects against possible code injection.

... this is utter nonsense.

As always, your input is irrelevant.

It's not irrelevant - your statement was incorrect the way it was
formulated.

Whether my statement was incorrect or not the reply was irrelevant.

I think it's a good habit to use MAXLENGTH, but it gives you no
protection against the things you mention. The only useful check on
string length (in regard to security issues) must be performed at
server.

Then, for injection attacks, use the same filters that you used when the
password was generated (a common check is e.g. alphanumeric +
underscore, which should set you safe).

Most kinds of buffer overflows / flooding cannot be prevented anyhow if
the attacker is persevering enough.

See... now that's not an irrelevant response.

It should be noted that I was not writing a dissertation on code
injection. Setting maxlength does do exactly what I said it does... is it
a complete defense against code injection, of course not... can it be
circumvented, most things can... is it a good practice in conjunction with
checking input at the server... yes it is. You should do everything you
can to control user input.

 

[Lee]

Ivan Marsh said:

It should be noted that I was not writing a dissertation on code
injection. Setting maxlength does do exactly what I said it does... is it
a complete defense against code injection, of course not... can it be
circumvented, most things can... is it a good practice in conjunction with
checking input at the server... yes it is. You should do everything you
can to control user input.

You need to decide whether or not you value your customers.
If you do, you should do everything you can to make their
experience pleasant, or at a minimum, free of frustration.

The protection provided by maximum field lengths is so
slight as to pale to insignificance compared to the risk
of losing return business.

Doing "everything you can to control user input" is as
silly as putting a "Do not open!" sign on your wall safe.


--

 

[Ivan Marsh]

Ivan Marsh said:


You need to decide whether or not you value your customers. If you do,
you should do everything you can to make their experience pleasant, or
at a minimum, free of frustration.

I've had no trouble at all maintaining my customer base over the last 25
years.

 

[Ivan Marsh]

I've had no trouble at all maintaining my customer base over the last 25
years.

....oh, and for the record, since I've never attempted to write one
(perhaps our Vulcan friend has an answer for this):

Does the onPaste function in javascript have access to the data before
it's entered into an input box or does the input get stripped by the max
length of the input and then get processed by onPaste?

 

[Lee]

Ivan Marsh said:

I've had no trouble at all maintaining my customer base over the last 25
years.

Are you saying that you've been writing customer-facing GUI's
for 25 years, or just resorting to irrelevancies?


--

 

[Lee]

Ivan Marsh said:

...oh, and for the record, since I've never attempted to write one
(perhaps our Vulcan friend has an answer for this):

Does the onPaste function in javascript have access to the data before
it's entered into an input box or does the input get stripped by the max
length of the input and then get processed by onPaste?

Since I don't restrict user input at this level, I've never had
any use for an onPaste handler. I only audit input onChange and
onSubmit (both for the user's convenience, only) and, of course,
on the server side, to protect the application.







--

 

[Ivan Marsh]

Ivan Marsh said:

Are you saying that you've been writing customer-facing GUI's for 25
years, or just resorting to irrelevancies?

UI not necessarily GUI.