How to completely destroy a script and make it disappear forever.

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 17, 8:25 pm, "Evertjan." <exjxw.hannivo. ..@interxnl.net wrote:

The amount of malicious requests is not in the ease of some sending by
many, but in the fact that one bad guy can sent quite a lot.

A DoS attack is a thing, and being able to get a password by the brute
force is another.

Your obfuscative quest is like Don Quigote's,
and I have nothing against windmills.

Security must be seen from every angle.

--
Jorge.

[Conrad Lender]

Re: How to completely destroy a script and make it disappear forever.

On 2008-10-17 20:33, Jorge wrote:

>The amount of malicious requests is not in the ease of some sending by
>many, but in the fact that one bad guy can sent quite a lot.

>
A DoS attack is a thing, and being able to get a password by the brute
force is another.

Then add a delay after a failed login attempt before you send a
response. Force people to use better passwords. Keep track of how many
login attempts are made from the same IP-Address in a specified time
frame, and lock out those who exceed the limit. Brute forcing takes a
while, and with these three measures (all on the server side!) you can
make it very hard.

>Your obfuscative quest is like Don Quigote's,
>and I have nothing against windmills.

>
Security must be seen from every angle.

Half-hearted attempts at security, i.e. measures that are only effective
against lazy script kiddies, give a false sense of security. To guard
youself against people who would brute-force passwords, there is *one*
big and strong door that you really have to close. Putting up fences and
warning signs around it won't do any good. In your case (login), that
big strong door is on the server, because you can't possibly control the
client.


- Conrad

[Grant]

Re: How to completely destroy a script and make it disappear forever.

On Fri, 17 Oct 2008 11:05:42 -0700 (PDT), Jorge <jorge@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

[Lasse Reichstein Nielsen]

Re: How to completely destroy a script and make it disappearforeve r.

Jorge <jorge@jorgecha morro.comwrites :

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.

Removing the script after it has been loaded will not protect you.
Nothing will, against a dedicated and even slightly competent
attacker.

Once you sent the script to the client, you should act as if
everything in it was common knowledge to everybody on the internet
(from a security perspective). Once it's on the client, nothing can
put it back in the box. Any attempt to do so will only fool those
who are pretty much incapable of exploiting it anyway.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 17, 9:22 pm, Conrad Lender <crlen...@yahoo .comwrote:

On 2008-10-17 20:33, Jorge wrote:
>

The amount of malicious requests is not in the ease of some sending by
many, but in the fact that one bad guy can sent quite a lot.

>

A DoS attack is a thing, and being able to get a password by the brute
force is another.

>
Then add a delay after a failed login attempt before you send a
response. Force people to use better passwords. Keep track of how many
login attempts are made from the same IP-Address in a specified time
frame, and lock out those who exceed the limit. Brute forcing takes a
while, and with these three measures (all on the server side!) you can
make it very hard.
>

Your obfuscative quest is like Don Quigote's,
and I have nothing against windmills.

>

Security must be seen from every angle.

>
Half-hearted attempts at security, i.e. measures that are only effective
against lazy script kiddies, give a false sense of security. To guard
youself against people who would brute-force passwords, there is *one*
big and strong door that you really have to close. Putting up fences and
warning signs around it won't do any good. In your case (login), that
big strong door is on the server, because you can't possibly control the
client.
>
  - Conrad

Thanks Erwin, Conrad, Grant, Lasse, Evertjan. I agree 100% with all
the things you said. I'm already doing most of the things that you are
suggesting (except fiddling with the firewall setup, Grant). May be
I'm just too paranoid. TFYT.

(Although you didn't even try to help me with the original
question :-)

Regards,
--
Jorge.

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 18, 10:48 am, Erwin Moller
<Since_humans_r ead_this_I_am_s pammed_too_m... @spamyourself.c omwrote:

>
Oh well, that is enough for today. I talk too much. :-)
>
Good luck!
>
Regards,
Erwin Moller

Erwin, thanks for sharing that story :-)

I know the network traffic can be sniffed. I know that even with ssl
no single line of JS can be hidden from a clients' eyes. I know they
can single-step through the code and see what it's doing or copy-paste
it for inspection. But then there's code obfuscation. See google app's
scripts gazpacho and you'll know what I mean. But only a small % of
the small % of people that might normally attempt to crack my app's
non obfuscated login attempt, will consider that the added effort is
worth it if the code is obfuscated. So, again, even though I know what
you all mean, I still think that it's not a mistake to think that
obfuscation counts as another barrier in their way...

@Grant:

ADSL clients with dynamically assigned IPs might be blocked by the
firewall if they inherit an attacker's IP, isn't it ?
And of course they will if they share the attacker's IP (when both are
coming from behind the same NAT router), right ?
Do you handle that case ?

TFYT.
Regards,
--
Jorge.

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 17, 9:22 pm, Conrad Lender <crlen...@yahoo .comwrote:

>
Then add a delay after a failed login attempt before you send a
response. Force people to use better passwords. Keep track of how many
login attempts are made from the same IP-Address in a specified time
frame, and lock out those who exceed the limit. Brute forcing takes a
while, and with these three measures (all on the server side!) you can
make it very hard.

I've setup such a delay, but when an IP's activity definitely looks
nasty (too many failed attempts), a 404 response is sent asap -not
delayed- and the connection is closed asap in an attempt to free the
socket for somebody else's use. Then a countdown timer is setup and
that IP will keep receiving 404 responses for any request it makes
until after the timer expires.

--
Jorge.

[Conrad Lender]

Re: How to completely destroy a script and make it disappear forever.

On 2008-10-18 12:35, Jorge wrote:

But then there's code obfuscation. See google app's
scripts gazpacho and you'll know what I mean. But only a small % of
the small % of people that might normally attempt to crack my app's
non obfuscated login attempt, will consider that the added effort is
worth it if the code is obfuscated. So, again, even though I know what
you all mean, I still think that it's not a mistake to think that
obfuscation counts as another barrier in their way...

....or an incentive. I have personally unobfuscated (de-obfuscated?) a
number of scripts, mostly to prove to the authors that it can be done
with little effort. Sure, it does add a barrier for those who are
looking for easy targets, but there are plenty of bored people on the
net, and curious people with too much time on their hands. Overall, I'm
not sure if it helps or hurts more.

@Grant:
>
ADSL clients with dynamically assigned IPs might be blocked by the
firewall if they inherit an attacker's IP, isn't it ?
And of course they will if they share the attacker's IP (when both are
coming from behind the same NAT router), right ?
Do you handle that case ?

I'm not Grant, but here's how we handle it: the IP based blocks are
temporary, usually between 4-24 hours. If they hit us again after that,
they get banned again. BTW, this is not restricted to web security, it
goes for all kinds of access (including SSH). A better approach might be
to remember aggressive IP addresses, and block them for a longer time if
they come back. At the moment we don't do it that way, because the
system is working well enough. It appears that once the griefers notice
the automatic block, they hardly ever return.

As for people behind NAT routers - we have no way of telling if there's
a NATed network behind a visitor IP, and we don't care. If one visitor
from that address misbehaves, he ruins it for the rest of them. Let
their admin sort it out. The same goes for dynamic addresses - they can
either wait until the ban is lifted, ask the site admins to remove it
manually, or complain to their ISP. If you want to be really nice and
friendly, don't block them completely at the firewall level; redirect
them to a page about how to repeal a ban instead.


- Conrad

[slebetman]

Re: How to completely destroy a script and make it disappear forever.

On Oct 18, 2:21 am, Jorge <jo...@jorgecha morro.comwrote:

On Oct 17, 8:09 pm, Erwin Moller
>
<Since_humans_r ead_this_I_am_s pammed_too_m... @spamyourself.c omwrote:

Hi Jorge,

>

Well, I don't know what or why you build it like that, BUT: wouldn't
things be much easier (and more secure) if you just used https?

>
But that solves another different problem.
>

What is it excactly you are trying to avoid?
Some scriptkiddo?

>
Or the wannabe-a-hacker child of an employee, or ..., you never know.

Child of employee maybe, but not the average script kiddie or wannabe
hacker much less a real hacker. Even a novice, if determined enough,
would at least try wget to fetch the script file. Firebug is just a
recent tool in the hacker toolbox that makes it easier to explore a
site. Remember, with javascript you can't hide the source. Even if you
manage to hide stuff from Firebug (which most developers would
consider a bug on Firebug's side and soon request Firebug developers
to patch) there are still lots of well known tools that lets me get
your script. Like httpwatch for example.

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 18, 5:31 pm, slebetman <slebet...@gmai l.comwrote:

>
Child of employee maybe, but not the average script kiddie or wannabe
hacker much less a real hacker. Even a novice, if determined enough,
would at least try wget to fetch the script file. Firebug is just a
recent tool in the hacker toolbox that makes it easier to explore a
site. Remember, with javascript you can't hide the source. Even if you
manage to hide stuff from Firebug (which most developers would
consider a bug on Firebug's side and soon request Firebug developers
to patch) there are still lots of well known tools that lets me get
your script. Like httpwatch for example.

To fight sniffing and curl lookalikes there's SSL/https, if not, the
innerHTML of the script can be received scrambled in an XHR :

document.getEle mentsByTagName( 'head')
[0].appendChild(do cument.createEl ement('script') ).innerHTML=
unscramble(XHR. responseText);

--
Jorge.

[Conrad Lender]

Re: How to completely destroy a script and make it disappear forever.

On 2008-10-18 22:12, Jorge wrote:

To fight sniffing and curl lookalikes there's SSL/https

Won't work. An attacker can use a local proxy to talk to your server
over SSL, and have plain HTTP traffic between the browser and the proxy.
Use SSL to protect the visitor from man-in-the-middle attacks, not to
protect the server from the visitor.

if not, the
innerHTML of the script can be received scrambled in an XHR :
>
document.getEle mentsByTagName( 'head')
[0].appendChild(do cument.createEl ement('script') ).innerHTML=
unscramble(XHR. responseText);

And you helpfully provide the unscamble() function and all necessary
keys to the client, and therefore to the attacker.

I know, it's frustrating. There's just no way to send secrets to a
browser in such a way that the browser can access them and the user
cannot. BTW, that's also the fundamental flaw of the various DRM
schemes, so you're in good company if you still think you can make it
work. But ultimately these attempts are doomed to fail - all that's
needed to break them is one bored hacker.


- Conrad

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 18, 10:40 pm, Conrad Lender <crlen...@yahoo .comwrote:

You keep telling me the obvious, and it isn't the point. Obfuscated
code is harder to understand and therefore to crack than pretty
printed and commented non-obfuscated source code. Sniffed obfuscated
data is meaningless unless you know how to unscramble it. That
additional effort on the part of an attacker is what I'm after, no
more, no less.

--
Jorge

[slebetman]

Re: How to completely destroy a script and make it disappear forever.

On Oct 19, 4:12 am, Jorge <jo...@jorgecha morro.comwrote:

On Oct 18, 5:31 pm, slebetman <slebet...@gmai l.comwrote:
>
>
>

Child of employee maybe, but not the average script kiddie or wannabe
hacker much less a real hacker. Even a novice, if determined enough,
would at least try wget to fetch the script file. Firebug is just a
recent tool in the hacker toolbox that makes it easier to explore a
site. Remember, with javascript you can't hide the source. Even if you
manage to hide stuff from Firebug (which most developers would
consider a bug on Firebug's side and soon request Firebug developers
to patch) there are still lots of well known tools that lets me get
your script. Like httpwatch for example.

>
To fight sniffing and curl lookalikes there's SSL/https,

Try httpwatch for yourself. It's a firefox/ie extension. SSL is not a
problem with httpwatch because it recieves its data AFTER it has been
decrypted.

if not, the
innerHTML of the script can be received scrambled in an XHR :
>
document.getEle mentsByTagName( 'head')
[0].appendChild(do cument.createEl ement('script') ).innerHTML=
unscramble(XHR. responseText);

No problem here because you will be providing me with your unscramble
function. All I need to do is copy/paste your unscramble function into
firebug and then copy/paste the whole XHR response into firebug as the
parameter to your unscramble function.

The only way out of this is to not use javascript -- use java or flash
instead to do your processing. Even then, there are decompilers out
there that will convert it back to source (though not the same source
but an equivalent source that does the same job).

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 19, 1:13 am, slebetman <slebet...@gmai l.comwrote:

On Oct 19, 4:12 am, Jorge <jo...@jorgecha morro.comwrote:
>

On Oct 18, 5:31 pm, slebetman <slebet...@gmai l.comwrote:

>

Child of employee maybe, but not the average script kiddie or wannabe
hacker much less a real hacker. Even a novice, if determined enough,
would at least try wget to fetch the script file. Firebug is just a
recent tool in the hacker toolbox that makes it easier to explore a
site. Remember, with javascript you can't hide the source. Even if you
manage to hide stuff from Firebug (which most developers would
consider a bug on Firebug's side and soon request Firebug developers
to patch) there are still lots of well known tools that lets me get
your script. Like httpwatch for example.

>

To fight sniffing and curl lookalikes there's SSL/https,

'and curl lookalikes' didn't belong there ^^^^ :

"To fight sniffing there's SSL/https, if not, for curl lookalikes the
innerHTML of the script can be received scrambled in an XHR : "

Ok ?

Try httpwatch for yourself. It's a firefox/ie extension. SSL is not a
problem with httpwatch because it recieves its data AFTER it has been
decrypted.
>

There's no need to install nothing. I can be seen it in firebug and in
Safari's web inspector.

--
Jorge.

[Jorge]

Re: How to completely destroy a script and make it disappear forever.

On Oct 19, 1:13 am, slebetman <slebet...@gmai l.comwrote:

>
No problem here because you will be providing me with your unscramble
function. All I need to do is copy/paste your unscramble function into
firebug and then copy/paste the whole XHR response into firebug as the
parameter to your unscramble function.
>

Even worse: the only tool you need to do the attack is the browser: no
curl no wget no proxy no nothing else: just inject the brute force
attack() JS code into the page... then comfortably type
javascript:atta ck(); into the url bar and hit enter.

And as it's so easy you'd better obfuscate the things at least a
little bit, or better yet as much as possible.

--
Jorge.