[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64034.1273150583@localhost>
Date: Thu, 06 May 2010 08:56:23 -0400
From: Valdis.Kletnieks@...edu
To: Ed Carp <erc@...ox.com>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: JavaScript exploits via source code disclosure
On Thu, 06 May 2010 01:03:09 PDT, Ed Carp said:
> Just for clarification, the business wants to put client-side
> Javascript on a customer-facing web site, and it's my job to figure
> out how to protect the back-end web services...sigh...
Get a copy of Firefox. Install the Tamper Data extension:
https://addons.mozilla.org/en-US/firefox/addon/966
Play a bit. Learn the two biggest secrets of Javascript web security:
1) In the end, you can't use Javascript to keep a determined attacker from
figuring out what you're sending to the web site.
2) You also can't depend on Javascript to prevent the attacker from sending
other (potentially tampered) requests.
These are basically special cases of a more general principle: You can't
depend on enforcing security using code that's running under the control
of the attacker. Unfortunately, a lot of people in this industry don't
understand this...
Your best strategy for securing the back end is to simply forget about the
Javascript, and just assume from the start that your attacker *can* and *will*
send you malicious crafted requests (xss, sql injection, forged session
cookies, or whatever). In general - if it makes you say "Oh, receiving *that*
would suck", it will be sent. And the more suckage it would cause, the
more you should expect the tampered request.
Content of type "application/pgp-signature" 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/
Powered by blists - more mailing lists