How to completely destroy a script and make it disappear forever.
Jorge
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,
--
Jorge.
Laser Lips
Just clap your hands together and say hey presto..
Evertjan.
Secure clientside scripting authentication is a contradictio in terminis.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jorge
>
> Secure clientside scripting authentication is a contradictio in terminis.
>
I neither do nor said nothing about "secure clientside scripting
authentication".
--
Jorge.
Jorge
>
> Just clap your hands together and say hey presto..
Doesn't work. Got a better idea ?
--
Jorge.
Erwin Moller
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
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>
> 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,
--
Jorge.
Erwin Moller
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.
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
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>
> 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
> Jorge wrote on 17 okt 2008 in comp.lang.javascript:
>
> > 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.
--
Jorge.
Erwin Moller
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?
Jorge
>
> 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.
Jorge
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> 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.
--
Jorge.
Evertjan.
> On Oct 17, 7:49ÿpm, "Evertjan." <exjxw.hannivo...@interxnl.net> wrote:
>> Jorge wrote on 17 okt 2008 in comp.lang.javascript:
>>
>> > 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.
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.
--
Jorge.
Conrad Lender
>> 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
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.
--
http://bugsplatter.id.au
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
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jorge
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.
Erwin Moller
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,
> --
> Jorge.
Jorge
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>
> 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
> 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
> 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
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
>
> 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.getElementsByTagName('head')
[0].appendChild(document.createElement('script')).innerHTML=
unscramble(XHR.responseText);
--
Jorge.
Conrad Lender
> 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.getElementsByTagName('head')
> [0].appendChild(document.createElement('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
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
> On Oct 18, 5:31 pm, slebetman <slebet...@gmail.com> wrote:
>
>
>
> > 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.getElementsByTagName('head')
> [0].appendChild(document.createElement('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
> On Oct 19, 4:12 am, Jorge <jo...@jorgechamorro.com> wrote:
>
> > On Oct 18, 5:31 pm, slebetman <slebet...@gmail.com> wrote:
>
> > > 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
> 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:attack(); 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.
David Mark
Pfft. Why? Is it *that* good?
Forget it. You can't hide anything that comes from a Web server.