There is a way to defeat that (somewhat). For every form that you have on your
site create an ID that must be passed with this form. Based on this ID you know
whether the form is being submitted in a way you want it (and even if it was
submitted already).
This of course doesn't defeat programs that actaully can follow the flow that
you impose (or even programs that can record mouse and keyboard events and play
them back). They don't just request URLs but use actual web page to perform
actions. They will log in, request something and log out.
So I guess you can limit the abuse somewhat but in the end there's always a way
around it because there is NO way that you can judge a request to be valid or
not based on the request itself. There is no way to know the INTENT of the
request (for example what's the difference between a program requesting weather
for some city every second for use in other program and a weather obsessive
person requesting it?).
The machines cannot judge that yet.
d.
Bing Zhang wrote:
> <<Comments inline.
>
> <<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.
>
> <I WONT SAY IT IS HACKING BECAUSE THE PROGRAM WAS DOING THE SAME THING A
> <PERSON COULD HAVE DONE BUT FASTER. I WOULD HACKING AS SEEING THE HTML
> <PAGES NOT MEANT FOR YOU.
>
> I mean hacking is that the request is not submitted through a html page
> downloaded from the server, instead through a user composed page. A lot of
> pages doing client side validation through javascript. A user composed page
> can change all these and submit an invalid request to server. Even the data
> is not sensitive, invalid data may trash your database, unless you duplicate
> the validation on server side, which means client side checking is useless.
>
> <<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.
>
> <WERE THESE DATA SESITIVE IN THE SENSE THAT NOBODY SHOULD HAVE SEEN THAT.
> <IT IS UP TO THE ADMINISTRATORS TO CHECK WHETHER THERE SITE IS BEING USED
> <FOR THE PURPOSE THEY ARE MEANT FOR BY LOOKING AT THE LOGS OR ... WHAT I <AM
> SAYING ONE CAN WRITE A SCRAPPER WHICH CAN TAKE CONTENT FROM WEBSITES <AND
> PUT THEM IN DATABASE AND SHOW THEM AS THERE OWN....IT IS DIFFICULT <TO AVOID
> ESPECIALLY IF SCRAPPER IS WRITTEN SMARTLY TO AVOID THESE <CATCHES.
> <WHAT I WOULD SAY THAT IF YOUR SITE IS SUCH THAT IT CAN BE "HACKED" BY
> <USER
> <IT CAN BE DONE BY PROGRAMS TOO.
>
> After you scan the lengthy log and find out the intruder, the damage has
> been long done. If a user can submit anything he wants, it will break your
> business logic quite easy, make your business logic hard to implment and
> error checking is tedious. What I am asking is that whether there is some
> help from servlet container such that we are in control, not busy reacting
> to user's invalid data.
>
> Look at the example of firewall, you can simply block some ports and
> protocols without implementing complicated logic to go inside each packet to
> analyze what is inside.
>
> ___________________________________________________________________________
> 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
--
David Mossakowski [EMAIL PROTECTED]
Programmer 212.310.7275
Instinet Corporation
"I don't sit idly by, I'm planning a big surprise"
___________________________________________________________________________
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
