Sun vs. Microsoft JVMs

[Sudsy]

then erases them for you when you make some unrelated error.

arrgh!

Not to belabor the point (too late! some of you are likely saying) but
Struts handles this situation ably. If validation fails then the HTML
form fields are repopulated from the ActionForm.
It's not fair to make generalized criticisms when solutions are clearly
at hand. If your tools aren't doing a good job then perhaps it's time
to update your suite.

 

[Roedy Green]

Not to belabor the point (too late! some of you are likely saying) but
Struts handles this situation ably. If validation fails then the HTML
form fields are repopulated from the ActionForm.
It's not fair to make generalized criticisms when solutions are clearly
at hand. If your tools aren't doing a good job then perhaps it's time
to update your suite.

This is a good sign I am no longer a voice crying in the wilderness on
this. However, a solution based on JavaScript or Flash is not fully
portable. I'd like to see the same thing done with Applets.


I'd also like the solution to be extensible, so that you knock off an
app that basically was just a from with types and bounds, or you could
evolve that into a full blown Applet, that has power assist for data
entry. Anything based on JavaScript is going to remain in the barely
adequate category.

 

[Sudsy]

I'd also like the solution to be extensible, so that you knock off an
app that basically was just a from with types and bounds, or you could
evolve that into a full blown Applet, that has power assist for data
entry. Anything based on JavaScript is going to remain in the barely
adequate category.

So now we're really talking in circles! Should I even mention that XML
Schema provides constructs such as complexType...?
Roedy, the tools and technologies are there. Rather than lamenting
prior bad experiences, it might be time to use comptemporary tools to
achieve what you claim to desire.
So many (free!) tools to manipulate a design and generate appropriate
code...

 

[Roedy Green]

Roedy, the tools and technologies are there.

What are the names of some of them?

Is there one that works generating Java on both client and server?

 

[Steve Horsley]

One example is requiring use of Java 2 to turn on text antialiasing. Mike
Smith came up with a nice workaround to this problem at:
http://www.smithvalley.com/test/aademo.htm

Thanks for that link. Interestingly, on Firefox on Linux, the middle paragraph
is far and away the best lookingn one.

Steve

 

[Mickey Segal]

Thanks for that link. Interestingly, on Firefox on Linux, the middle paragraph
is far and away the best lookingn one.

It sounds like that environment does not do antialiasing for native
components such as Label in Java. Labels get antialiasing on Windows using
the Sun JVM in Netscape or Internet Explorer and on Macintosh using the
Apple JVMs 1.3 and 1.4 in Netscape, Internet Explorer and Safari.

 

[Roedy Green]

And it is developers that think like you that enable exploits like
buffer overflows, SQL injection, etc

Sudsy has it 100% right. The server can NEVER trust what the client is
sending it. ALWAYS revalidate EVERYTHING that you receive.

By all means, make it easy for the client by performing interactive
validation, prompting, etc.

In email, Rogan brought up the issue of what servers have to do to
revalidate Strings.

I mentioned earlier if the String must have one of a fixed set of
values how you can convert that to a country-index, state-index etc.
Then all you need do in the server is bounds check on the int.

For general strings, in DOS Abundance I categories characters as
numeric, alphabetic, lower case, upper case, accented, printable,
space, control char.

You can declare that a string can only contain certain classes of
character. That gets automatically checked on a keystroke basis, and
automatic conversion sometimes happens to lower case, to upper case,
or to strip accents.


If you had a similar facility in your client level validation, you
have to repeat it in the server. You don't need to deal with
translation, just validation, since any missing translation is clear
fraud.


Sometimes strings are combos of words, e.g. a list of fruit names from
a fixed list of fruit names. These can be converted to int bit masks.
The server does not need to validate these at all, just mask off any
unused bits.

 

[Guest]

To be fair, you can NEVER trust the client in a client-server
architecture. Someone will always find a way to present invalid
data to the server. You have to validate at both ends. Heck,
with a protocol like HTTP you have no choice: the data can be
generated by applications, not just users.
So instead of lamenting what applets COULD have become, take
advantage of the technologies available.
You obviously don't like the thin-client model, but to me it
represents the ultimate in accessibility and portability.
Same glass, different perception...

I don't think Roedy was suggesting that the server-side should abandon
data integrity checks; rather, that the client-side should offer data
integrity checks at the keystroke level, for the benefit of the user,
in addition to the server-side performing data integrity checks.

 

[Guest]

And it is developers that think like you that enable exploits like
buffer overflows, SQL injection, etc

Sudsy has it 100% right. The server can NEVER trust what the client is
sending it. ALWAYS revalidate EVERYTHING that you receive.

By all means, make it easy for the client by performing interactive
validation, prompting, etc. But DON'T even think of skimping on the
server side validation that you do.

Where did Roedy suggest the server should abandon important data
integrity checks? You appear to be reading something in his posts
which isn't there.

 

[Guest]

So have you looked at the Apache commons validator? It's the one used
by Struts, if memory serves. It's supposed to be able to generate
validating JavaScript for the browser. I still wouldn't trust any
incoming data, mind you, but at least it's a partial solution.
I've never use the client side validation, BTW. I do it all on the
server and display validation errors alongside or below the offending
field.

As someone who has watched user interfaces generally get WORSE with
the popularization of the world wide web, I can only say: yuck.

It would have been hugely beneficial if Microsoft hadn't poisoned
their JVM. We could all be enjoying a much more rich user interface
experience right now.

 

[Roedy Green]

And it is developers that think like you that enable exploits like
buffer overflows, SQL injection, etc

Sudsy has it 100% right. The server can NEVER trust what the client is
sending it. ALWAYS revalidate EVERYTHING that you receive.

I tried repeatedly to explain but you remain convinced I am advocating
risky behaviour. Far from it. The revalidation system I am suggesting
provides the same security as the traditional one, in theory, and more
security in practice.

1. When you transport numbers in binary, there are no keystrokes to
validate. Not only is it more efficient to avoid revalidating the
keystrokes, it is IMPOSSIBLE to revalidate them. They no longer exist.
All you need to do is validate the equivalent binary value. There is
nothing shoddy about this.

2. The system introduces no new holes for a hacker to exploit. There
is no way to exploit it to sneak in invalid values. If you don't
believe me, see if you can think of a way to do it. If you try, it
should soon become obvious why there is no leak. You are worrying
about imaginary, theoretically impossible, problems. You are doing
the equivalent of writing

if ( a > 2 || a > 2 )

because you are worried the first one might not take.

3. The revalidation required at the server is much simpler than the
validation done on the client. There this thus less chance it will be
coded incorrectly. It is easier to proofread, easier to test. There
is no temptation to skimp on validation to keep the serverside code
small.

4. It provides a proper separation of duty. Clients produce clean
data; servers deal only in clean data, with the final checks necessary
to ensure data truly has been cleaned, not to clean it.

5. Consider that if a hacker creates a record identical to the one you
create with your Applet, that is ok, no matter how he constructs it --
e.g. with a hex editor. You are not trying to block that. You are
merely trying to block any records a hacker would send you that could
not have come from your Applet. If you Applet allowed the keying of a
single field and insisted the value be between 100 and 200, the only
binary records it could produce are binary ints between 100 and 200.
So all you need do serverside is check if the binary int is between
100 and 200. There are no other possible acceptable records, and all
of them in that range are acceptable.

 

[Sudsy]

Where did Roedy suggest the server should abandon important data
integrity checks? You appear to be reading something in his posts
which isn't there.

From Roedy's post of 7/30 @ 00:22:
"The validation does NOT have to be repeated in full. For example a
number sent in binary need only be validated on bounds. There is no
need to recheck for alpha, number of decimal places, total fill etc."

I disagree. Fair enough?

 

[Roedy Green]

"The validation does NOT have to be repeated in full. For example a
number sent in binary need only be validated on bounds. There is no
need to recheck for alpha, number of decimal places, total fill etc."

I disagree. Fair enough?

No. You are simply wrong. Please provide a counterexample.

 

[Roedy Green]

I disagree. Fair enough?

I can't understand why you are having trouble with this unless you are
refusing to look at what I have said and are resorting to a rule of
thumb that checking is good. There is no way to sneak through an
invalid integer if you check the bounds on the binary representation.

You claim you can. Give me an example how. Sending the original
keystrokes and revalidating them buys you no additional security.
You claim it does. Give me an example where that is true.

 

[Mickey Segal]

You claim you can. Give me an example how. Sending the original
keystrokes and revalidating them buys you no additional security.
You claim it does. Give me an example where that is true.

One could imagine examples where this is true if there are secret procedures
exposed by an applet. Imagine that 5 pieces of information are requested of
the user and combined to produce a composite score. If a servlet evaluated
all 5 original values and assigned a composite score this would be harder to
fool than if the applet sent just the composite score. Although the applet
would be doing the same calculation as the servlet, it would be less secure
since applets are less secure and single numbers are easier to probe/fool
than groups of 5 numbers.

I am not implying that this is necessarily a common occurrence. There are
many situations in which one would process input in real time in an applet
to alert the user to information that is not yet acceptable.

 

[Roedy Green]

Although the applet
would be doing the same calculation as the servlet, it would be less secure
since applets are less secure and single numbers are easier to probe/fool
than groups of 5 numbers.

Your hacker has the source code to your Applet compliments of any
number of decompiling tools. See
http://mindprod.com/jgloss/decompiler.html

So in principle he knows what sorts of message your applet could
generate and what it could not.

If you use a thin client, he does not even have to do that much work.
He just looks at the form.

If you want to make life awkward for him, you add some random EXTRA
checks not part of the Applet. He can't examine the server side code.

The practical problem is a hacker sending you legitimate data as far
as your edits are concerned, but actually fake -- e.g. phony orders
for goods, just to hassle you. Validation would not protect you
there.

To protect against that sort of thing, you could do something like
frequently change the format of the message (easy to do with thick
clients). Your hacker than has to KEEP reverse engineering your code.
With thin client, you are a sitting duck. You also ignore messages
from IPs caught in past hassling you.

 

[Roedy Green]

Although the applet
would be doing the same calculation as the servlet, it would be less secure
since applets are less secure and single numbers are easier to probe/fool
than groups of 5 numbers.

You can do the exact same thing sending the five numbers separately in
binary. That is orthogonal to whether you send original keystrokes or
binary equivalents.

 

[Guest]

From Roedy's post of 7/30 @ 00:22:
"The validation does NOT have to be repeated in full. For example a
number sent in binary need only be validated on bounds. There is no
need to recheck for alpha, number of decimal places, total fill etc."

I disagree. Fair enough?

No. You're being ridiculous.

If the client-side has already converted an alpha field to a numeric
country code, it makes sense that the server-side would then check
that numeric value to be sure it's in bounds.

There's no need to send the original alpha field to the server-side to
do both the conversion from alpha to numeric country code AND then do
the bounds check.

 

[Mark Preston]

An agreement works in both directions. If Microsoft chose not to distribute
Java2, there *is* no agreement.

There is a difference - they agreed in court as part of the court case
resolution. The agreement is in writing and fully and legally recorded.
It stopped having Microsoft broken up. The fact that they then decided
to go back on that legal agreement does, I admit, speak volumes about
how Microsoft operates and what it thinks of the law and legal process.

 

[Sudsy]

No. You're being ridiculous.

You asked for evidence. I provided it. So now you denigrate me.
And hide your e-mail address so I can't reply directly and keep
this off-list.

If the client-side has already converted an alpha field to a numeric
country code, it makes sense that the server-side would then check
that numeric value to be sure it's in bounds.

There's no need to send the original alpha field to the server-side to
do both the conversion from alpha to numeric country code AND then do
the bounds check.

Yes, there is. One of things you'll discover when developing commercial
applications using HTML forms is how much easier the job can be when you
use a framework. I'm partial to Struts but other people have their own
preferences.
In order to avoid the problem Roedy complained about, namely fields
being blanked when input fails validation, Struts will automatically
populate fields from a form. It can only do that when the fields are
stored in the ActionForm as a java.lang.String. So all your accessors
and mutators work with Strings. You perform the conversion after the
basic validation and validate against business rules.
This is a fairly standard architecture, BTW.