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

[Jorge]

Hi,

I have a web app that loads 2 scripts incrementally. The first one
handles authentication/login. If a user is authenticated, a second
script gets loaded by inserting a script tag in the header, and code
execution is transferred to that second script by means of a
setTimeout(globalReferenceToASecondScriptInitFunction), in that 2nd
script's InitFunction any remaining references to any data or variable
or function of the first script are destroyed, plus the first script's
script tag is removed from the header and any reference to that tag in
JS is destroyed as well.

The question is, why does it still appear after that in firebug ?
Is there any way to make it dissapear forever ?

TIA,

 

[Laser Lips]

Hi,

I have a web app that loads 2 scripts incrementally. The first one
handles authentication/login. If a user is authenticated, a second
script gets loaded by inserting a script tag in the header, and code
execution is transferred to that second script by means of a
setTimeout(globalReferenceToASecondScriptInitFunction), in that 2nd
script's InitFunction any remaining references to any data or variable
or function of the first script are destroyed, plus the first script's
script tag is removed from the header and any reference to that tag in
JS is destroyed as well.

The question is, why does it still appear after that in firebug ?
Is there any way to make it dissapear forever ?

TIA,

Just clap your hands together and say hey presto..

 

[Evertjan.]

Jorge wrote on 17 okt 2008 in comp.lang.javascript:

Hi,

I have a web app that loads 2 scripts incrementally. The first one
handles authentication/login. If a user is authenticated, a second
script gets loaded by inserting a script tag in the header, and code
execution is transferred to that second script by means of a
setTimeout(globalReferenceToASecondScriptInitFunction), in that 2nd
script's InitFunction any remaining references to any data or variable
or function of the first script are destroyed, plus the first script's
script tag is removed from the header and any reference to that tag in
JS is destroyed as well.

The question is, why does it still appear after that in firebug ?
Is there any way to make it dissapear forever ?

Secure clientside scripting authentication is a contradictio in terminis.

 

[Jorge]

Secure clientside scripting authentication is a contradictio in terminis.

I neither do nor said nothing about "secure clientside scripting
authentication".

 

[Jorge]

Just clap your hands together and say hey presto..

Doesn't work. Got a better idea ?

 

[Erwin Moller]

Jorge schreef:

Hi,

I have a web app that loads 2 scripts incrementally. The first one
handles authentication/login. If a user is authenticated, a second
script gets loaded by inserting a script tag in the header, and code
execution is transferred to that second script by means of a
setTimeout(globalReferenceToASecondScriptInitFunction), in that 2nd
script's InitFunction any remaining references to any data or variable
or function of the first script are destroyed, plus the first script's
script tag is removed from the header and any reference to that tag in
JS is destroyed as well.

The question is, why does it still appear after that in firebug ?
Is there any way to make it dissapear forever ?

TIA,

Hi Jorge,

Why it still appears in firebug?
Well, you should actually ask the firebug developers.
My best guess is that firebug thought it might be handy for you for
debuggingpurposes. Next browser/debugging environment might make other
choises.

Why does this bother you?

Regards,
Erwin Moller

 

[Jorge]

Hi Jorge,

Why it still appears in firebug?
Well, you should actually ask the firebug developers.
My best guess is that firebug thought it might be handy for you for
debuggingpurposes. Next browser/debugging environment might make other
choises.

Why does this bother you?

I'm obfuscating the entry code. That script isn't in the .html file.
It gets loaded, quickly does its things, and inmediatly after that I'd
like it to disappear from sight...

Any ideas ?

Thanks,

 

[Erwin Moller]

Jorge schreef:

I'm obfuscating the entry code. That script isn't in the .html file.
It gets loaded, quickly does its things, and inmediatly after that I'd
like it to disappear from sight...

Any ideas ?

Thanks,

Hi Jorge,

Is this all about obfuscating?
In that case you might reread Evertjan's short answer, because that sums
it up quite nicely.
Sorry, that is just the way it is.

Remember that everything you send to the browser is, well, send to the
browser. Anybody can get his hands on it, inspect it, tweak it, etc.

If you need security for something, please restate your problem in more
detail. Maybe somebody can help.

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Evertjan.]

Jorge wrote on 17 okt 2008 in comp.lang.javascript:

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.

 

[Jorge]

Hi Jorge,

Is this all about obfuscating?
In that case you might reread Evertjan's short answer, because that sums
it up quite nicely.
Sorry, that is just the way it is.

Remember that everything you send to the browser is, well, send to the
browser. Anybody can get his hands on it, inspect it, tweak it, etc.

I know that. The authentication is done at the server and I could
leave it as it is now. But I'm obfuscating the code that builds the
authentication request as that will disuade most (not all) people to
even try to guess the details of the structure of the auth. request,
even though, I repeat, the authentication is done at the server side.

With the previous version of firebug, it was disappearing from the
scripts popup menu.

if (!obfuscated) { tinker(); } === (!obfuscated && tinker())

 

[Jorge]

Jorge wrote on 17 okt 2008 in comp.lang.javascript:



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.

 

[Erwin Moller]

Jorge schreef:

I know that. The authentication is done at the server and I could
leave it as it is now. But I'm obfuscating the code that builds the
authentication request as that will disuade most (not all) people to
even try to guess the details of the structure of the auth. request,
even though, I repeat, the authentication is done at the server side.

With the previous version of firebug, it was disappearing from the
scripts popup menu.

if (!obfuscated) { tinker(); } === (!obfuscated && tinker())

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?

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

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Jorge]

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.

Besides, handling the authentication isn't the same thing as
authenticating.

 

[Jorge]

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.

 

[Evertjan.]

Jorge wrote on 17 okt 2008 in comp.lang.javascript:

Jorge wrote on 17 okt 2008 in comp.lang.javascript:

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.

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.

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

 

[Jorge]

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.

 

[Grant]

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_error, 1)) {
print " query contains url" > out
}
if (and(query_error, 2)) {
print " bad form timestamp" > out
}
if (and(query_error, 4)) {
print " bad data timestamp" > out
}
if (and(query_error, 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.

 

[Lasse Reichstein Nielsen]

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

 

[Jorge]

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.



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,

 

[Erwin Moller]

Jorge schreef:

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

Shame, I thought we tried to answer that one too.
I'll do it again in more clear words:
Whatever the piece of JavaScript is you are trying to 'remove', it won't
help. It has been sent to the client, so it is/was there: no matter how
hard you try to remove it: it has still been sent, and thus ready for
inspection, modification, etc by anyone who has the slightest idea how
http works. You CANNOT hide that.

As for your original question: Why is is visible in this version, and
not that version og firebug: only the developers can tell you why they
decided to build it that way.
So unless one of them frequents this group, you have to ask them directly.

Bottomline: It actually doesn't matter what some piece of software tells
you (firebug in this case). Even IF the firebug developers decided to
remove your piece of JavaScript from their debugger, it STILL was
transmitted over the network, received by your browser.
So it doesn't matter what firebug tells you.

Here is a story that actually happened to me:
In my early days as webdeveloper I built a website with good fun
Shockwavegames. The scores of the players had to be received by the
server because we would give the best players a real prize: a bunch of
popular boardgames.
I thought I could outsmart smart hackers. In my case it was even harder
for a hacker to break my logic because it was embedded in a shockwave
(director) movie, and not in Javascript.
And I really thought I made an ultrasmart encoding, with a few
hard-to-break nonstandard tricks in it. How arrogant of me.
After a few months of prizes I noticed 1 player sent highscores that
hold strangely round numbers (excactly 50.000 eg), so I investigated
futher, and decided to contact the guy (I had his address because I
wanted to send him the boardgames).
He straightly admitted he hacked the thing and explained to me how
(network sniffing, and some simple decoding algorithm/program named
Primus I think). He also told me it took him half an hour in total to
break my protection.
I thanked him of course, and send him the prize. (In my opinion he
deserved a double prize because he learned me why my approach sucked.)

Moral for me: Never think you can outsmart the rest of the world.
When it comes to security, simply realize that there are people out
there with 10 times your math skills, 10 times your intelligence, and
who think 100 times faster. They WILL crack your code, and surely when
you try to make it hard for them: That is actually an insentive to break
it. (No honor is easy wins)

So, keep things simple:
- Make sure the only way into your system is a valid username/password,
don't even try to hide anything clientside, there is no point in doing so.
- If you care about a man-in-the-middle attack, use https.
- Run a real OS at the server.
- Make sure you understand who has access to the server, and what they
can do. (So no shared hosting, VM is OK though.)
- And also: be sure you agree to what Conrad Lender wrote: especially
the delay from the server before ansering to really annoy anyone who
tries brute force passwordbreaking. It is a simple measure and it really
has a great impact.

Oh well, that is enough for today. I talk too much.

Good luck!

Regards,
Erwin Moller

Regards,

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare