Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: JavaScript exploits via source code disclosure
From: Christian Sciberras <uuf6429 () gmail com>
Date: Thu, 6 May 2010 19:09:39 +0200

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 () extendedsubset 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/

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]