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: <4BE2F56D.6050201@extendedsubset.com>
Date: Thu, 06 May 2010 11:59:25 -0500
From: Marsh Ray <marsh@...endedsubset.com>
To: PsychoBilly <zpamh0l3@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: JavaScript exploits via source code disclosure


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/