Sun vs. Microsoft JVMs

R

Roedy Green

I'd rather blame the INCREDIBLY buggy and far more incomplete
implementations (lack of 1.1 event model - later added, their own
security system instead of using java.security) that Netscape shipped.

There were teething pains, but that was long ago. The main thing
holding Applets back since Java 1.2 is the MS JVM.


Add up how many emails each of us has received from people complaining
about "broken" Applets. How many times have you shepherded some
stranger through the process of getting rid of the MS JVM and getting
the proper one installed? We each should send MS a giant bill.
 
R

Rogan Dawes

Roedy said:
You MUST validate in the workstation and revalidate in the server.
That duplication is no excuse for failing to do keystroke validation.
You do it to make life tolerable for your client.
The way to do it properly is to use a thick client to do keystroke
validation, field by field prompting, then send the data off in tidy
form to the server.

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.

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.

Rogan
 
M

Mark Preston

Steven said:
I wish MS and Sun would just come to some kind of agreement that would let
MS ship Java2 with Windows and Internet Exploder, but it's not going to happen.
It already did happen - but Microshaft still chooses not to do it.
 
M

Mickey Segal

Roedy Green said:
The way to do it properly is to use a thick client to do keystroke
validation, field by field prompting, then send the data off in tidy
form to the server.

I think Roedy is right, but only if you can count on the user having Java
installed.

For the registration form that people use to get access to our huge Java
applet, the registration uses a Java applet to create a form that rejects
obviously fake e-mail addresses, puts up appropriate state/province choices
depending on your country and provides real-time feedback about fields
remaining to be filled out. We can require Java for the form because we
require Java for the service, running our applet. We only require Java 1.1
for the registration form and for the huge applet.

For forms on other domains we don't assume that people have Java and do no
processing on the client computer.

Roedy is right that processing on the client machine is great, but one must
be careful if there is a chance that the user will not have Java.
Java-absence is probably pretty rare now, but I'd bet there are a few
percent of users in this category, though I have not seen any doctors in
this situation for years. However, a huge number of users are still stuck
at Java 1.1 and a Java-based form that assumes Java 2 will exclude a lot of
people.
 
M

Michael Borgwardt

Rogan said:
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 don't think you understood Roedy's point: what he said is that the server
should certainly repeat all validation that is security-critical, but
doesn't need to repeat the stuff that is basically just meant to protect
users from their own mistake, catch typos, and stuff like that.
 
R

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.

If you ship the a numeric result back to the server in binary, its
original form is irrelevant -- e.g. whether it contained alpha
characters commas or decimals etc. Think from the point of view of
someone trying to screw up your server. Just what sort of binary value
can he send you that will cause trouble? All you need do in the
server is check the bounds. That completely covers it. There is no
such thing as an invalid format binary number. All the rest of the
checks are irrelevant. They need only be done in the client which has
to deal with individual keystrokes.
 
R

Roedy Green

I don't think you understood Roedy's point: what he said is that the server
should certainly repeat all validation that is security-critical, but
doesn't need to repeat the stuff that is basically just meant to protect
users from their own mistake, catch typos, and stuff like that.

That is not what I am saying, but close. The point is if the client
massages the data into binary form, then there ARE almost no edits the
server CAN do. You don't send the original raw keystrokes. You send
BINARY data. The server can be 100% safe with duplicating only a tiny
fraction of the validation work that was done in the client.

Let me give a few more examples of the principle.

Let us say you had to key in a country name in the client, and ensure
it was in an official list of countries. The client may/may not allow
country abbreviations, misspellings, selection from a pulldown, allow
you to key part of the name and then select alternatives. Quite a
production. But when you are done, the client software can boil it
down to a single byte containing a country index.

All the server need so is a range check on that byte. EVERYTHING ELSE
is irrelevant at that point.

Ditto for a state of the union, province in Canada, date, credit card
number, SIN number, ...

Imagine a client software validation that helped you key a Canadian
telephone number, and insisted you get it in a particular format e.g.
(250) 361-9093. It might let you key letters of the alphabet and have
those automatically converted into the equivalent keypad digit
internally. The client software cross checks the number with the
province and queries the user if they really meant an out of province
area code. The client insists however on valid Canadian area codes, or
the 800 series. It may disallow the 555 exchange as silly. The client
boils this down to a single binary number and sends that to the
server.

All the server has to do is check the bounds. The other checks are
irrelevant to security, just to aid accuracy. The server might want
to revalidate that the area code is Canadian, but it is irrelevant if
it is out of province. If the server discovers an invalid Canadian
area code, it has detected a tampering attempt and should ring some
alarms.

My point is there really is very little duplication of effort. The
server operates an massaged data, so it can do its final check very
quickly without any security risk. There is no need at all to repeat
the keystroke validations. A bounds check can be done with a
microscopic server overhead compared with what the thin client folks
do sending in all the raw keystrokes.
 
R

Roedy Green

I think Roedy is right, but only if you can count on the user having Java
installed.

"thick client" means having Java or something similar intelligent
running in the client.

Since MS has screwed Java Applets, people are turning to Flash to get
decent thick clients.

This is a shame.

Everyone is dicking around wasting time with thin client stop gap crap
that only its mother could excuse. It is user HOSTILE. We need
something like JSP but that does the bulk of the data entry validation
in the client and that fills in forms automatically to handle the most
common forms tasks on the web.

It is a harder nut to crack, but anything less is nowhere near good
enough.
 
R

Rogan Dawes

Roedy said:
If you ship the a numeric result back to the server in binary, its
original form is irrelevant -- e.g. whether it contained alpha
characters commas or decimals etc. Think from the point of view of
someone trying to screw up your server. Just what sort of binary value
can he send you that will cause trouble? All you need do in the
server is check the bounds. That completely covers it. There is no
such thing as an invalid format binary number. All the rest of the
checks are irrelevant. They need only be done in the client which has
to deal with individual keystrokes.

OK, to use your example:

If you are checking the float that the user enters has 2 decimal points
(e.g. a currency), then serialise it and send it to the server, which
then uses that number, it is not important to check that the number is
still only precise to 2 decimal points?

I'll collect that 0.9 cent on every transaction, thanks ;-)

My perspective is that of a HTTP observer. Web applications check that
the input is correctly formatted, right type, etc, etc but the attacker
could modify all that between the browser and the server. He could add
parameters, change them from digits to alpha, remove parameters, etc

You CANNOT trust the client, because you do not control it, and
everything in between it and your server. If you are not rechecking
EVERYTHING on the server, you are going to get bitten. Simple as that.

And thinking that it does not apply to you, because you are using a
different/less widely spread protocol du jour is just fooling yourself.
If someone wants your stuff badly enough, they will find the gap that
you left.

Regards,

Rogan
 
R

Roedy Green

If you are checking the float that the user enters has 2 decimal points
(e.g. a currency), then serialise it and send it to the server, which
then uses that number, it is not important to check that the number is
still only precise to 2 decimal points?

You don't send a float. You send an int or long scaled by 100.

All you need is the bounds check.
 
R

Roedy Green

You CANNOT trust the client, because you do not control it, and
everything in between it and your server. If you are not rechecking
EVERYTHING on the server, you are going to get bitten. Simple as that.

Let me challenge you.

The transaction consists of nothing but an amount in pennies.

The client does any validations on the keystrokes you wish, then sends
in an amount as a binary int 4 bytes big endian.

Now you as hacker are to write a fake applet that can send in
dangerous data that you could not enter via the keyboard with the
legit applet.

All I do in the server is a binary bounds check, low and high, and of
course the obvious check that 4 bytes were received.

Just what are you going to send that can cause me trouble?

Since I am not sending the raw keystrokes, there is no need to repeat
the keystroke validations in the server. All that counts is the final
result.
 
S

Steven J Sobol

Mark Preston said:
It already did happen - but Microshaft still chooses not to do it.

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

Roedy Green

If you did start sending binary floats, you would have to do some sort
of NaN check as well as a bounds check. From a security point of
view, that should pretty well nail it. Exactly how the float was
constructed is immaterial.

If you had an int that only had a set of allowable values, e.g. shoe
sizes, you scrunch this down so that the allowable range is dense,
shoe size index. You can fluff it back up again in the server after
you do you the bounds check.
 
R

Roedy Green

I don't think you understood Roedy's point: what he said is that the server
should certainly repeat all validation that is security-critical, but
doesn't need to repeat the stuff that is basically just meant to protect
users from their own mistake, catch typos, and stuff like that.

From an independent binary int point of view, a simple bounds check
covers it. There is nothing else to test.

Of course, from a CROSS-FIELD point of view, you have to repeat the
checks in the server.

E.g. You are only allowed to have a zip code if you are in the USA.
You have to repeat that check both in client and server.

What I want is a tool that lets me write code that describes the
validations I want mostly declaratively. Then it generates the code
for both the client and server, automatically doing just the minimal
checks on the server, nothing that does not actually increase
security. Think it of as like a data dictionary of fields,
information on accessing them in SQL, validation rules, and cross
field rules. You would for example declare a variable as a YYYY-year
date in locale format, bounded by 1990-01-01 and today plus 30 days.
Its display name is "Invitation Date". Its description is "The date
of the most recent fundraising event this person has been invited to.
Blank means none."
 
S

Scott Ellsworth

Sudsy said:
Roedy Green wrote:


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.

Right, but without applets or javascript, it is difficult to have a
responsive web front end that will catch easy validation errors. The
backend still needs to validate, but the front end can prevent user
errors, if not user malicous behavior. For example, in a current
webapp, users must enter various plate ids. Validation of formats
prevents typos. (I am using Tapestry to do this validating input, which
uses Javascript.) It is kind of nice to do front end validation on user
input so they do not have to wait for a roundtrip.

Scott
 
R

Roedy Green

It is kind of nice to do front end validation on user
input so they do not have to wait for a roundtrip.

With FORMS you don't even have the notion of mandatory fields. You
find out about each one on each 10 second trip.
 
S

Sudsy

Roedy Green wrote:
What I want is a tool that lets me write code that describes the
validations I want mostly declaratively. Then it generates the code
for both the client and server, automatically doing just the minimal
checks on the server, nothing that does not actually increase
security. Think it of as like a data dictionary of fields,
information on accessing them in SQL, validation rules, and cross
field rules. You would for example declare a variable as a YYYY-year
date in locale format, bounded by 1990-01-01 and today plus 30 days.
Its display name is "Invitation Date". Its description is "The date
of the most recent fundraising event this person has been invited to.
Blank means none."

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

Sudsy

Roedy said:
With FORMS you don't even have the notion of mandatory fields. You
find out about each one on each 10 second trip.

So score another for Struts. You'll only get the first validation
error for each field but at least EVERY field is checked.
But this is nit-picking. We've all seen forms on the web which
mark those fields which are required (mandatory).
So I stand by my prior assertion: it's entirely possible to use
a thin client (web browser) for most applications if you spend
the time up-front to design a good GUI using a limited number of
basic elements.
 
R

Roedy Green

We've all seen forms on the web which
mark those fields which are required (mandatory)

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

arrgh!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top