OK, scratch "plain text" and instead "human readable code".
Because, let's face it, obfuscators don't do much in the face of
real/determined hackers/attackers.
On Fri, May 7, 2010 at 6:37 AM, Nick FitzGerald wrote:
> Christian Sciberras wrote:
>
> > This is a seriously flawed argument.
>
> Cor
Christian Sciberras wrote:
> This is a seriously flawed argument.
Correct...
> JS == plain text. Full Stop.
...but that has nothing to do with the reasons why.
First, because it is simply wrong (FSVO "plain text").
For just one trivial example, the following Javascript doesn't look
anything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If his users are authenticated via say regular form login, he can
pass some sort of hash which identifies the user and session to the
service, with the authentication wrapper being server side, which
begs the question, do you trust your users...
How w
A proxy or 'web-service firewall' prior to the 'protected' web service is
the correct answer.
Obfuscating the client code be it JavaScript, Interpreted (Java, CLR, etc)
or Native ignores the notion that the client controls hardware, OS, the
executing process and the network.
Signals can be interc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Unless you wrap your service methods with some form of an
authentication, your webservice's are just as public as any other
"world" accessible part of your site. Are the pages calling these
services behind any sort of authentication?
On Thu, 06 May 20
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 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 ]] p
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 stati
You may write a "proxy" that sits between your client and your
internal databroker which only allows some defined methods and params?
What else was the question?
Regards
2010/5/6, Ed Carp :
> Just for clarification, the business wants to put client-side
> Javascript on a customer-facing web site,
On 5/6/2010 9:00 AM, PsychoBilly wrote:
> http://www.jcryption.org/
A perfect example of what doesn't work.
>From the site:
> Normally if you submit a form and you don’t use SSL, your data will be sent
> in plain text.
> But SSL is neither supported by every webhost nor it’s easy to install/appl
http://www.jcryption.org/
Cluster #[[ Ed Carp ]] possibly emitted, @Time [[
06/05/2010 10:03 ]] The Following #String **
> Just for clarification, the business wants to put client-side
> Javascript on a customer-facing web site, and it's my j
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:
Ed Carp wrote:
> We've got a lot of JQuery code that calls back-end web services, and
> we're worried about exposing the web services to the outside world -
> anyone can "view source" and see exactly how we're calling our web
> services.
>
> Are there any suggestions or guidelines regarding prote
El Thursday 06 May 2010 07:44:07 Ed Carp va escriure:
> We've got a lot of JQuery code that calls back-end web services, and
> we're worried about exposing the web services to the outside world -
> anyone can "view source" and see exactly how we're calling our web
> services.
>
> Are there any sugg
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...
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.or
We've got a lot of JQuery code that calls back-end web services, and
we're worried about exposing the web services to the outside world -
anyone can "view source" and see exactly how we're calling our web
services.
Are there any suggestions or guidelines regarding protecting one's
source from such
16 matches
Mail list logo
