full-disclosure - Re: JavaScript exploits via source code disclosure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2v3af3d47c1005061009s2187f890m755ad36a5057a9ee@mail.gmail.com>
Date: Thu, 6 May 2010 19:09:39 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: Marsh Ray <marsh@...endedsubset.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: JavaScript exploits via source code disclosure

This is a seriously flawed argument.

JS == plain text. Full Stop.

If your JS is liking server source code then your whole system is seriously
flawed.

Did I say seriously? Make it "critically".

Now if you were talking about client-side source code, sure you are very
right to be afraid.
But last I checked, any kind of code that will be executed at some point can
be disassembled or worse, decompiled.

Oh and, who's the wise ass suggesting you use SSL to protect code?
How do you know the recipient is not a malicious user?
And if you get to know that, then by all means this system is nothing new
from current systems were a user logs in to an HTTPS-based site.






On Thu, May 6, 2010 at 6:59 PM, Marsh Ray <marsh@...endedsubset.com> wrote:

>
> I confess I don't understand all of what you wrote, but it doesn't have
> the ring of a bulletproof architecture.
>
> I prefer this one:
>
> Case B: Strong authentication and encryption using SSL.
>
> - Marsh
>
> On 5/6/2010 11:39 AM, PsychoBilly wrote:
> > ************************  Cluster #[[   Marsh Ray   ]] possibly emitted,
> > @Time [[   06/05/2010 17:42   ]] The Following #String
> > **********************
> >>
> >> Adversary simply modifies your page in transit to not use the
> >> 'jcryption', or to leak him a copy of the session key.
> >
> > Tss Tss, I'm not stating client-side javascript is secure / can be
> > obfuscated.
> > Just provided a hint
> >
> > 1 - let's say it's a customer login area
> > Case 1: legitimate user > usr+pw are transmitted encrypted, then ajax
> > get/post calls are then still encrypted + each request is followed by a
> > valid encrypted client session ID.
> > Case 2: Opponent > trying to exploit login > the pb here is getting thru
> > / not JS related // trying to exploit the ass > does not know any valid
> > encrypted session ID > server side can drop this with minimum ressource.
> > - not using encryption: server-side script drops connection ( as it has
> > the duty to decrypt posts )
> > - leak a session key: ok, fine the opponent does have a unique ID that
> > leads him to a login area.
> >
> > 2 - There's no login: it's an API // forget js because, yes, all the
> > logic is in the oponent hands & executed on opponent machine ( so source
> > encryption is useless ).
> >
> > 3- nobody can guess where/what is open on target machine, a proxy is
> > giving one port/valid encrypted ID or just drops connection.
> >
> >>
> >> This kind of thing will only deter people who don't know any better or
> >> people with little motivation to care about your data anyway. Using it
> >> is only an admission that you are either incompetent or don't have
> >> anything worth the slightest effort to steal.
> >>
> >> - Marsh
> >
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/