Contact: Tel: 2726 - New Media Systems, 1st Floor South, Queens Walk
You have simply rewritten the HTML page in some other way to access the
data. You haven't hacked anything.
Hacking means to break the security means to access data that is not
intended for you. There is no security involved. You know how to login. You
probably have been given the password too. No hacking.
If a web site requires login with userid and password and you wrote a
program to by-pass that login process, or intercep it will be a hack.
Client side validation is never meant to be a security measure. Cilent side
validation is for prompt user interaction, to reduce round trips back to
server. After the form is finally accepted after having been validated on
the client side, you don't expect errors such as wrong date format, or
alphabetic characters for numeric values. On the server side, you would
still have to check a correctly formated date may still be a out of range
date. In most cases, it is like sematics check on the server side. For
security checks, you only do it on server side.
Cheers,
Charles
Bing Zhang <[EMAIL PROTECTED]> on 10/31/2000 07:51:02 AM
To: [EMAIL PROTECTED]
cc: (bcc: Charles Chen/YellowPages)
From: Bing Zhang <[EMAIL PROTECTED]>, 31 October 2000, 7:51 a.m.
Re: Design and Validation opinion. [Scanned by Yellow Pages PostMaster]
After I read this thread and the "Get to Post" thread, I have to raise a
question that concerns me for quite long tiem: what are good/effcient ways
to protect your html page from hacked by users?
I was once handled over a task to download some dynamic text pages from a
national weather center to files. It has a login page and several pages for
selecting combo boxes or clicking on some radio buttons and finally the
text
pages I want show up. Server side is cgi. I used a IE Web Browser component
in a simple Visual Basic program similating this whole process. It run
about
12 hours and saved 30,000+ files. I was actually hacking the html page.
Maybe the above data is not sensitive, I ever seen html pages with
javascripts that after you enter your username and password, it will pull
all sorts of your account data from datek. You can even trade stock with
these user written html pages. These are cerntaily very sensitive data.
Will the HttpSession from the servlet engine make the life easier for
servlet to detect that a request is submitted from a hacked html page? Or
we
have to use ad hoc method without any help from servlet container on this
regard, such as server side cookies, always use post, encoding urls and
etc?
Anyone out there doing such thing please share your experience.
Thanks
Bing
-----Original Message-----
From: Raj Kumar Jha
To: [EMAIL PROTECTED]
Sent: 10/30/00 10:44 PM
Subject: Re: Design and Validation opinion.
Hi Craig,
By validation I meant simple validations for form properly filled
or
not. It is a must to validate the data on the server end depending upon
the
need. Your observations are very true. hanks for correcting me.
Raj
----- Original Message -----
From: Craig R. McClanahan
To: [EMAIL PROTECTED]
Sent: Monday, October 30, 2000 11:51 PM
Subject: Re: Design and Validation opinion.
Raj Kumar Jha wrote:
> Hi,
> I suppose using javascript on the client side is a much better
way, in
> my opinion. You reduce the load on your server, network traffic and
thus
> gain in speed.
> Regards,
> Raj
>
Using client-side validation *only* is a good way to get your
application
hacked.
It is trivially simple to write a Java program (and only slightly harder
in
other languages :-) that submits an HTTP GET or POST request to your
application
on its own, which therefore bypasses all of your careful client-side
editing
tests.
Client-side editing is useful in improving your user interface (because
you
can
react to certain classes of errors more quickly), but you should
consider
server-side validation of everything to be mandatory for any serious
application.
Craig McClanahan
________________________________________________________________________
___
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
________________________________________________________________________
___
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
