On Fri, 17 Oct 2008 11:05:42 -0700 (PDT), Jorge <jo***@jorgecha morro.comwrote:
>On Oct 17, 7:49Â*pm, "Evertjan." <exjxw.hannivo. ..@interxnl.net wrote:
>Jorge wrote on 17 okt 2008 in comp.lang.javas cript:
On Oct 17, 4:08Â*pm, "Evertjan." <exjxw.hannivo. ..@interxnl.net wrote:
>Secure clientside scripting authentication is a contradictio in
terminis.
I neither do nor said nothing about "secure clientside scripting
authentication" .
You don't need to. your Q is clear as it is.
It can be the only reason you asked about
getting rid of a login page script on the client.
It's not the only reason. The auth. request itself is obfuscated. It's
not a plain post-a-form. The details of the structure of the auth.
request are hidden if that code is out of sight. I don't want someone
to keep trying auth. requests one after the other. They can't if they
don't know its structure. That's what I'm trying to hide.
I think you're taking the wrong approach, recently I had some scriptkiddies
from NL decide to play games with the one form on my web site, and, after
some playing around I defeated them with a couple simple timestamps and
some minimal query content checking (for URLs).
As another pointed out, correct authentication is to use https, you cannot
hide normal http traffic as it is available to the client as part of
normal operation.
Another misthink is this idea of defeating a particular tool, firebug,
what of other tools, what of people simply looking into their browser
cache files? You cannot sidestep that with anything a followup script
can do -- the first script is tucked away in client browser.
Observation, script-kiddies are too stupid to go searching too deep.
Ultimate answer? What I did was to put in place a logging system and
some query validation:
(server-side, awk)
if (query_error) {
printf "[%u]\n", naddr out
print "query error:" out
if (and(query_erro r, 1)) {
print " query contains url" out
}
if (and(query_erro r, 2)) {
print " bad form timestamp" out
}
if (and(query_erro r, 4)) {
print " bad data timestamp" out
}
if (and(query_erro r, 8)) {
print " your time off >3 hours" out
}
print "use back button, try again" out
print "please report false positives" out
close(out)
printf "Location: %s\n\n", out
###print "Status: 205 Reset Content\n"
++do_exit; exit
}
Another cron job scans the logfile and locks out script-kiddies via the
firewall, so they no longer get access to the form.
Finally, the firewall rate limiter will jail any IP requesting services
too often. Having some script-kiddies play with your site can be a
wonderful opportunity to try out and install various strategies at the
server -- where the kiddies can't play and your scripts are safe from
public view. Or should be, if you properly implement access wrappers:
$ ls -l
total 28
drwxrwx--- 2 grant wheel 208 2008-10-18 00:04 archive/
-r-sr-xr-x 1 grant wheel 3104 2008-10-05 09:07 cc2ip.cgi*
-rwxrwxr-x 1 grant wheel 11613 2008-10-17 06:52 index.html*
-rw-r--r-- 1 grant wheel 5708 2008-10-17 06:52 index.html.gz
-rwxrwxr-x 1 grant wheel 444 2008-10-05 09:07 lookup-ip*
drwxrwxrwx 2 grant wheel 240 2008-10-18 00:02 public/
drwxrwx--- 2 grant wheel 128 2008-10-18 07:14 server/
Grant.
--
http://bugsplatter.id.au 
