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
Hello,
fyi: I found the sitecatalyst software running on paypal.com to be
vulnerable to xss in the past. (unfiltered referer url was used as a
javascript value). Omniture/paypal didn't respond to my emails, paypal
fixed the issue after public disclosure.
Regards,
Thomas Pollet
On 14/01/2008, Mic
> This is from a current CNN home page:
>
> /* SiteCatalyst code version: H.10.
> Copyright 1997-2007 Omniture, Inc. More info available at
> http://www.omniture.com */
Omniture is one of (many) sites that do tracking for companies .. like
what your mouse moves over, how long it stays there, how
This is from a current CNN home page:
/* SiteCatalyst code version: H.10.
Copyright 1997-2007 Omniture, Inc. More info available at
http://www.omniture.com */
/ ADDITIONAL FEATURES
Plugins
*/
/* Specify the Report Suite ID(s) to track here */
v
This is from a current RoadRunner home page:
var _vjs="HBX0201.03u";
var
_dl=".exe,.zip,.wav,.wmv,.mp3,.mov,.mpg,.avi,.doc,.pdf,.xls,.ppt,.gz,.bin,.hqx,.dmg";
function _NA(a){return new Array(a?a:0)}
var
_mn=_hbq="",_hbA=_NA(),_hud="undefined",_huf="function",_ec=_if=_ll=_hec=_hfs=_hfc=_hfa=_ic=
http://www.gnucitizen.org/blog/yahoo-site-explorer-spider
This simple POC uses Yahoo Site Explorer Service to craw/spider other
webistes. It is written entirely with JavaScript - no server side
support was required from my side. The POC proves once again that
Web2.0 technologies open new ways of a
Ben Bucksch wrote:
> SirDarckCat wrote:
>> JaSiLDBG
>> JavaScript inLine Debugger
>
> Are you selling us the "javascript:" URL as "JaSiLDBG JavaScript inLine
> Debugger"? From all I can tell from your doc, you simply renamed
> "javascript:" to "JaSiLDBG".
Yes, I decided to overlook that. Nothi
Hi!
well "javascript:" is not an URL is an URI..
the document is not about the name of the technique (JaSiLDBG is the "code
name" we decided to use, you are free to name it as you want).
the document really is a handbook on how to use the "javascript" URI for
debugging web sites "on the fly".. I
SirDarckCat wrote:
> JaSiLDBG
> JavaScript inLine Debugger
Are you selling us the "javascript:" URL as "JaSiLDBG JavaScript inLine
Debugger"? From all I can tell from your doc, you simply renamed
"javascript:" to "JaSiLDBG".
Would have been more appropriate, and more useful, if you would have
SirDarckCat wrote:
> JaSiLDBG
> JavaScript inLine Debugger
>
> We wrote a document, explaining some of the capacities of this technique,
> and in the meantime, we also created some functions in a library that can
> help you using JaSiLDBG. The library is named: estigma its instalation, is
> very s
http://www.gnucitizen.org/blog/introducing-backweb
http://www.gnucitizen.org/backweb
I am quite happy to release the Backweb Attack Console.
The application is in its 0.1a release currently. This means that a
lot more work needs to be done. Right now it is quite stable and it
should work well wit
http://www.gnucitizen.org/projects/javascript-spider/
During the last couple of days I have been testing several attack
vectors to circumvent the browser security sandbox also known as the
same origin policy. There is a lot involved into this subject and I
will present my notes very soon.
The Jav
JavaScript Web Ping
Author: david.kierznowski_at_gmail.com
http://michaeldaw.org
The Idea:
1. We setup an Iframe
2. We dynamically load our target address with a timeout
3. If the document is loaded, we flag the host as being up.
4. If the host is down, the timeout is reached and we flag the host
Lazy Authorization Forcer
http://www.gnucitizen.org/projects/javascript-authorization-forcer/
This is an idea I am still developing but here you go POC is available
and it works. The malicious JavaScript presented here will try to
guess URLs that contain credentials. It is sort of Basic
Authentic
H D Moore wrote:
> 1) Create a metasploit payload for communicating with shell/meterpreter
> via DNS queries and replies. This will not be a 'small' payload by any
> means, but should be feasible for all DCERPC and browser bug exploits.
>
> 2) Develop a custom DNS server for *.msf.metasploit.com
On Sat, 12 Aug 2006, H D Moore wrote:
> 1) Create a metasploit payload for communicating with shell/meterpreter
> via DNS queries and replies. This will not be a 'small' payload by any
> means, but should be feasible for all DCERPC and browser bug exploits.
nstx code fits into 20 kB. Not small
Dear H Moore,
HDM> Heh. I actually have a plan for doing that :-)
Yipee :) As I saw the request made to the dns server I thought so.
HDM> * It may not be that useful, but it does seem like a fun hack. With any
HDM> luck, this can be accomplished using the built-in name resolution API in
HDM> wind
On Saturday 12 August 2006 12:16, Thierry Zoller wrote:
> OHoh, when can we expect a DNS tunnel, tunneling a shell through your
> DNS requests and DNS answers ? :) A nice remote shell thorugh dns
> tunnel over XSS. LOL :)
Heh. I actually have a plan for doing that :-)
1) Create a metasploit paylo
this one is cool one!
- Original Message -
From: "H D Moore" <[EMAIL PROTECTED]>
To:
Sent: Saturday, August 12, 2006 8:09 PM
Subject: Re: [Full-disclosure] JavaScript get Internal Address (thanks
toDanBUK)
Hello,
I worked on something similar, it uses Java in t
Dear H Moore,
HDM> I worked on something similar, it uses Java in the same way, but also uses
HDM> a custom DNS server to obtain even more information:
OHoh, when can we expect a DNS tunnel, tunneling a shell through your
DNS requests and DNS answers ? :) A nice remote shell thorugh dns
tunnel ov
Hello,
I worked on something similar, it uses Java in the same way, but also uses
a custom DNS server to obtain even more information:
Demo:
http://metasploit.com/research/misc/decloak/
Code:
http://metasploit.com/research/misc/decloak/HelloWorld.java
-HD
On Saturday 12 August 2006 03:55, pdp
hi martin. this script shows your internal IP address, which is
192.168.1.3. Attackers can use that to find how your internal network
looks like. In your case 192.168.1.0 is you home lan and 192.168.1.1
is probably your router.
cheers,
pdp
On 8/12/06, Martin Dipo Zimmermann <[EMAIL PROTECTED]> w
It appears that your scripts only result is 192.168.1.3 (tested on 5
sites). Dont think its quite ready to fly yet. But very interesting idea.
BR
Martin
pdp (architect) skrev:
http://www.gnucitizen.org/projects/javascript-address-info
http://f-box.org/~dan/jstest.html
The following technique
http://www.gnucitizen.org/projects/javascript-address-info
http://f-box.org/~dan/jstest.html
The following technique was brought to me by DanBUK
(http://f-box.org/~dan/). Dan managed to find the internal IP address
of the visiting client by establishing a socket between local host and
the remote
On Mon, May 16, 2005 at 11:45:03AM -0500, Raymond Joyal wrote:
> Other than disabling Javascript, what are my options for these new
> annoying popups?
A greasemonkey script, possibly. Pointing *.fastclick.com at localhost
in your hosts file might help, too.
I'm a big fan of Mike Skallas' adblock
Adblock extension for firefox with a filter for "*domain*" for whatever domains
you choose, can stop a lot of such things.
Raymond Joyal wrote:
Other than disabling Javascript, what are my options for these new
annoying popups?