By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,738 Members | 2,076 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,738 IT Pros & Developers. It's quick & easy.

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

P: n/a
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(globalReferenceToASecondScriptInitFunct ion), 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.
Oct 17 '08 #1
Share this Question
Share on Google+
30 Replies


P: n/a
On Oct 17, 10:47*am, Jorge <jo...@jorgechamorro.comwrote:
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(globalReferenceToASecondScriptInitFunct ion), 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.
Just clap your hands together and say hey presto..
Oct 17 '08 #2

P: n/a
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(globalReferenceToASecondScriptInitFunct ion), 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.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Oct 17 '08 #3

P: n/a
On Oct 17, 4:08*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
>
Secure clientside scripting authentication is a contradictio in terminis.
I neither do nor said nothing about "secure clientside scripting
authentication".

--
Jorge.
Oct 17 '08 #4

P: n/a
On Oct 17, 12:14*pm, Laser Lips <loudsphi...@gmail.comwrote:
>
Just clap your hands together and say hey presto..
Doesn't work. Got a better idea ?

--
Jorge.
Oct 17 '08 #5

P: n/a
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(globalReferenceToASecondScriptInitFunct ion), 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.
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
Oct 17 '08 #6

P: n/a
On Oct 17, 6:27*pm, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
>
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.
Oct 17 '08 #7

P: n/a
Jorge schreef:
On Oct 17, 6:27 pm, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
>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.

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
Oct 17 '08 #8

P: n/a
Jorge wrote on 17 okt 2008 in comp.lang.javascript:
On Oct 17, 4:08*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
>>
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.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Oct 17 '08 #9

P: n/a
On Oct 17, 7:07*pm, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
>
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.
Oct 17 '08 #10

P: n/a
On Oct 17, 7:49*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
Jorge wrote on 17 okt 2008 in comp.lang.javascript:
On Oct 17, 4:08*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
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.
Oct 17 '08 #11

P: n/a
Jorge schreef:
On Oct 17, 7:07 pm, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
>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.
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
Oct 17 '08 #12

P: n/a
On Oct 17, 7:49*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
>
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.
Oct 17 '08 #13

P: n/a
On Oct 17, 8:09*pm, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
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.
Oct 17 '08 #14

P: n/a
Jorge wrote on 17 okt 2008 in comp.lang.javascript:
On Oct 17, 7:49ˇpm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
>Jorge wrote on 17 okt 2008 in comp.lang.javascript:
On Oct 17, 4:08ˇpm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote
:
>>
>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.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Oct 17 '08 #15

P: n/a
On Oct 17, 8:25*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
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.
Oct 17 '08 #16

P: n/a
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
Oct 17 '08 #17

P: n/a
On Fri, 17 Oct 2008 11:05:42 -0700 (PDT), Jorge <jo***@jorgechamorro.comwrote:
>On Oct 17, 7:49¬*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
>Jorge wrote on 17 okt 2008 in comp.lang.javascript:
On Oct 17, 4:08¬*pm, "Evertjan." <exjxw.hannivo...@interxnl.netwrote:
>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_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
Oct 17 '08 #18

P: n/a
Jorge <jo***@jorgechamorro.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/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Oct 17 '08 #19

P: n/a
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.
Oct 17 '08 #20

P: n/a
On Oct 18, 10:48*am, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
>
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.
Oct 18 '08 #21

P: n/a
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.
Oct 18 '08 #22

P: n/a
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
Oct 18 '08 #23

P: n/a
On Oct 18, 2:21*am, Jorge <jo...@jorgechamorro.comwrote:
On Oct 17, 8:09*pm, Erwin Moller

<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
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.
Oct 18 '08 #24

P: n/a
On Oct 18, 5:31 pm, slebetman <slebet...@gmail.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.getElementsByTagName('head')
[0].appendChild(document.createElement('script')).inn erHTML=
unscramble(XHR.responseText);

--
Jorge.
Oct 18 '08 #25

P: n/a
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.getElementsByTagName('head')
[0].appendChild(document.createElement('script')).inn erHTML=
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
Oct 18 '08 #26

P: n/a
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
Oct 18 '08 #27

P: n/a
On Oct 19, 4:12*am, Jorge <jo...@jorgechamorro.comwrote:
On Oct 18, 5:31 pm, slebetman <slebet...@gmail.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.getElementsByTagName('head')
[0].appendChild(document.createElement('script')).inn erHTML=
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).
Oct 18 '08 #28

P: n/a
On Oct 19, 1:13*am, slebetman <slebet...@gmail.comwrote:
On Oct 19, 4:12*am, Jorge <jo...@jorgechamorro.comwrote:
On Oct 18, 5:31 pm, slebetman <slebet...@gmail.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.
Oct 19 '08 #29

P: n/a
On Oct 19, 1:13*am, slebetman <slebet...@gmail.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: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.
Oct 19 '08 #30

P: n/a
On Oct 17, 1:00*pm, Jorge <jo...@jorgechamorro.comwrote:
On Oct 17, 6:27*pm, Erwin Moller

<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
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...
Pfft. Why? Is it *that* good?

Forget it. You can't hide anything that comes from a Web server.
Oct 22 '08 #31

This discussion thread is closed

Replies have been disabled for this discussion.