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

Discussion in 'Javascript' started by Jorge, Oct 17, 2008.

  1. Jorge

    Jorge Guest

    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,
    --
    Jorge.
     
    Jorge, Oct 17, 2008
    #1
    1. Advertising

  2. Jorge

    Laser Lips Guest

    On Oct 17, 10:47 am, Jorge <> wrote:
    > 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,
    > --
    > Jorge.


    Just clap your hands together and say hey presto..
     
    Laser Lips, Oct 17, 2008
    #2
    1. Advertising

  3. Jorge

    Evertjan. Guest

    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.

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

    Jorge Guest

    On Oct 17, 4:08 pm, "Evertjan." <> wrote:
    >
    > Secure clientside scripting authentication is a contradictio in terminis.
    >


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

    --
    Jorge.
     
    Jorge, Oct 17, 2008
    #4
  5. Jorge

    Jorge Guest

    On Oct 17, 12:14 pm, Laser Lips <> wrote:
    >
    > Just clap your hands together and say hey presto..


    Doesn't work. Got a better idea ?

    --
    Jorge.
     
    Jorge, Oct 17, 2008
    #5
  6. Jorge

    Erwin Moller Guest

    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,
    > --
    > 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
     
    Erwin Moller, Oct 17, 2008
    #6
  7. Jorge

    Jorge Guest

    On Oct 17, 6:27 pm, Erwin Moller
    <> 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.
     
    Jorge, Oct 17, 2008
    #7
  8. Jorge

    Erwin Moller Guest

    Jorge schreef:
    > On Oct 17, 6:27 pm, Erwin Moller
    > <> 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.



    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
     
    Erwin Moller, Oct 17, 2008
    #8
  9. Jorge

    Evertjan. Guest

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

    > On Oct 17, 4:08 pm, "Evertjan." <> 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.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Oct 17, 2008
    #9
  10. Jorge

    Jorge Guest

    On Oct 17, 7:07 pm, Erwin Moller
    <> 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, Oct 17, 2008
    #10
  11. Jorge

    Jorge Guest

    On Oct 17, 7:49 pm, "Evertjan." <> wrote:
    > Jorge wrote on 17 okt 2008 in comp.lang.javascript:
    >
    > > On Oct 17, 4:08 pm, "Evertjan." <> 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.
     
    Jorge, Oct 17, 2008
    #11
  12. Jorge

    Erwin Moller Guest

    Jorge schreef:
    > On Oct 17, 7:07 pm, Erwin Moller
    > <> 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.


    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
     
    Erwin Moller, Oct 17, 2008
    #12
  13. Jorge

    Jorge Guest

    On Oct 17, 7:49 pm, "Evertjan." <> wrote:
    >
    > 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.
     
    Jorge, Oct 17, 2008
    #13
  14. Jorge

    Jorge Guest

    On Oct 17, 8:09 pm, Erwin Moller
    <> 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.
     
    Jorge, Oct 17, 2008
    #14
  15. Jorge

    Evertjan. Guest

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

    > On Oct 17, 7:49ÿpm, "Evertjan." <> wrote:
    >> Jorge wrote on 17 okt 2008 in comp.lang.javascript:
    >>
    >> > On Oct 17, 4:08ÿpm, "Evertjan." <> 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.

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

    Jorge Guest

    On Oct 17, 8:25 pm, "Evertjan." <> 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.
     
    Jorge, Oct 17, 2008
    #16
  17. Jorge

    Grant Guest

    On Fri, 17 Oct 2008 11:05:42 -0700 (PDT), Jorge <> wrote:

    >On Oct 17, 7:49 pm, "Evertjan." <> wrote:
    >> Jorge wrote on 17 okt 2008 in comp.lang.javascript:
    >>
    >> > On Oct 17, 4:08 pm, "Evertjan." <> 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_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
     
    Grant, Oct 17, 2008
    #17
  18. Re: How to completely destroy a script and make it disappearforever.

    Jorge <> writes:

    > 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.'
     
    Lasse Reichstein Nielsen, Oct 17, 2008
    #18
  19. Jorge

    Jorge Guest

    On Oct 17, 9:22 pm, Conrad Lender <> wrote:
    > 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, Oct 17, 2008
    #19
  20. Jorge

    Erwin Moller Guest

    Jorge schreef:
    > On Oct 17, 9:22 pm, Conrad Lender <> wrote:
    >> 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 :)


    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.



    --
    "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
     
    Erwin Moller, Oct 18, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Trint Smith
    Replies:
    13
    Views:
    1,520
  2. Colin Graham
    Replies:
    3
    Views:
    684
    Anders Norås [MCAD]
    Dec 16, 2004
  3. Jeremy S.
    Replies:
    6
    Views:
    515
    Jeremy S.
    Jan 22, 2005
  4. hh
    Replies:
    0
    Views:
    2,887
  5. Ook
    Replies:
    2
    Views:
    352
Loading...

Share This Page