************************ 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/
