mailing list archives
From: PsychoBilly <zpamh0l3 () gmail com>
Date: Thu, 06 May 2010 18:39:52 +0200
************************ Cluster #[[ Marsh Ray ]] possibly emitted, @Time [[ 06/05/2010 17:42 ]] The Following
Adversary simply modifies your page in transit to not use the
'jcryption', or to leak him a copy of the session key.
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
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.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/