[Esapi-dev] FW: [WEB SECURITY] [Tool Announcement] GroundspeedFirefox add-on

Mon Dec 14 22:56:32 EST 2009

Also - some links to the stuffs I am talking about.

http://www.devguru.com/Technologies/ecmascript/quickref/watch.html

http://msdn.microsoft.com/en-us/library/ms536956%28VS.85%29.aspx

The onpropertychange event could be a little tricky (as anything having to
do with IE usually is) in that the event doesn't cancel so the only way to
stop the script from processing would be to raise an exception. I am not
sure this would be ideal for users of ESAPI as it could potentially break
the entire page in the event that something outside of their own code tried
to modify the properties that are 'protected'.

Hmmm... I still think this behavior would be much better than allowing users
to be victims of a xss vuln on the server.

Mayhap it would be something that could be enabled or disabled as part of
the ESAPI configuration?

On Mon, Dec 14, 2009 at 8:50 PM, Chris Schmidt <chrisisbeef at gmail.com>wrote:

> After some research, it appears we may be able to, if nothing else, make
> this slightly more difficult on the client-side.
>
> In IE there is an onpropertychange event which is fired anytime the value
> of any object loaded in the DOM is changed. We could write an event handler
> function which checks if that property is anything listed in a protected or
> sealed objects list and raise an exception if it is, plus return false.
>
> In Mozilla there is a similar means of monitoring property changes with the
> watch() function.
>
> I will do a bit more research on the subject, but perhaps with this we
> could at least provide a bit of protection and this might also be a good
> value-add functionality for the ESAPI4JS dist overall. Providing developers
> with a means of 'protecting' their own JS Objects from being changed by code
> running in the same window sounds like a good idea overall.
>
> Thoughts?
>
>
> On Mon, Dec 14, 2009 at 4:46 PM, <chrisisbeef at gmail.com> wrote:
>
>> This definately raises an interesting conversation. Currently in
>> JavaScript, there is no mechanism to sign and seal code like there is in
>> Java. This instantly raises a question to me about the ability to verify
>> that the code that is being executed in the browser and representing itself
>> as ESAPI4JS, is, indeed, the code that was released. Short of a plaintext
>> diff that executes runtime (and sorely affects the user experience for those
>> using ESAPI4JS) I can think of no way to offer this type of "trust" for the
>> JavaScript code.
>>
>> There are interesting ways that you can make the code difficult to modify
>> during the runtime, which would more than likely be the bigger concern here,
>> but they are strictly able to make it more difficult. The fact that, by
>> definition, everything in JavaScript is *global* leaves us with the fact
>> that the code that was downloaded into the browser can be modified by other
>> code executed by the browser (for instance in a xss payload). Consider the
>> following:
>>
>> We have in the ESAPI4JS project, a function called
>> $ESAPI.encoder().encodeForJavaScript() - As part of an XSS payload (probably
>> a persistent XSS payload) the following code is executed after the ESAPI has
>> been loaded and initialized on the client side.
>>
>> $ESAPI.encoder().encodeForJavaScript = function( str ) { return str; }
>>
>> Or something even more nefarious. Basically, what this does it overwrites
>> the runtime definition of what that function is supposed to be doing.
>>
>> I am sure there are solutions to this problem ( SecurityManager type
>> functionality for JS maybe ) but all of them drastically increase the "size"
>> of the ESAPI which dissuades potential adopters from using the library.
>> People want all the functionality in the smallest possible footprint.
>>
>> I would love to hear if anyone has thoughts on how to mitigate this sort
>> of problem, as far as I can see this could be the biggest potential pitfall
>> to getting ESAPI4JS adopted widely.
>>
>> On Dec 14, 2009 2:48pm, "Boberski, Michael [USA]" <
>> boberski_michael at bah.com> wrote:
>> >
>> > To expand a little further,
>> >
>> >
>> >
>> > On the server side, the organization is trusting the
>> > developer of their server app and any reviews/processes/controls/etc.
>> they have
>> > in place to use ESAPI correctly.
>> >
>> >
>> >
>> > On the client
>> > side, the user needs to figure out who they should trust to use ESAPI
>> correctly
>> > since they're not writing their own code.
>> >
>> >
>> >
>> > There is no reason
>> > for the user to trust the server app other than if it's a trusted HTTPS
>> site or
>> > some such. But, before a user starts taking on their own protective
>> > gear, they should perhaps have some way to know if the gear can stop
>> bullets or
>> > not.
>> >
>> >
>> >
>> > Perhaps personal
>> > antivirus software or a personal firewall app would be a good analogy.
>> Higher
>> > chance it's working right if it's from McAffee or Microsoft, than
>> downloaded
>> > from a popup that appeared while I was surfing.
>> >
>> >
>> >
>> > Mike B.
>> >
>> >
>> >
>> >
>> >
>> >
>> > From: esapi-dev-bounces at lists.owasp.org
>> > [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Boberski,
>> Michael
>> > [USA]
>> > Sent: Monday, December 14, 2009 4:42 PM
>> > To: Jeff
>> > Williams; ESAPI-Developers
>> > Subject: Re: [Esapi-dev] FW: [WEB SECURITY]
>> > [Tool Announcement] GroundspeedFirefox add-on
>> >
>> >
>> >
>> >
>> >
>> > Doesn't this require trusting the client-side ESAPI code
>> > more than the server-side code? How can a user know to trust client-side
>> ESAPI
>> > code coming from one server as opposed to another? Shouldn't it be
>> signed or
>> > something so the user can check to see if it came from a trusted source,
>> or
>> > built into a browser plug-in that can be downloaded and its checksum
>> > verified? I don't think this problem is as simple as switching chairs,
>> from an
>> > everyone needs to protect themselves from the other guy perspective.
>> This
>> > situation is very similar to PKI cert path building/verification
>> > problem.
>> >
>> >
>> >
>> > Mike B.
>> >
>> >
>> >
>> >
>> >
>> >
>> > From: Jeff Williams
>> > [mailto:jeff.williams at aspectsecurity.com]
>> > Sent: Monday, December 14,
>> > 2009 12:25 PM
>> > To: Boberski, Michael [USA];
>> > ESAPI-Developers
>> > Subject: RE: [Esapi-dev] FW: [WEB SECURITY] [Tool
>> > Announcement] GroundspeedFirefox add-on
>> >
>> >
>> >
>> >
>> >
>> >
>> > Of
>> > course anyone can bypass any client-side controls in their own browser.
>>
>> > The point of controls like what we’re working on in ESAPI is to prevent
>> > *anyone else* from bypassing them. We don’t want attacks from the server
>>
>> > or anywhere else to allow an attacker to compromise the client-side
>> application,
>> > the browser, or the operating system.
>> >
>> >
>> > --Jeff
>> >
>> >
>> >
>> >
>> >
>> > From:
>> > esapi-dev-bounces at lists.owasp.org [mailto:
>> esapi-dev-bounces at lists.owasp.org]
>> > On Behalf Of Boberski, Michael [USA]
>> > Sent: Monday, December 14,
>> > 2009 12:06 PM
>> > To: ESAPI-Developers
>> > Subject: [Esapi-dev] FW:
>> > [WEB SECURITY] [Tool Announcement] GroundspeedFirefox
>> > add-on
>> >
>> >
>> >
>> > Hi,
>> >
>> > Doesn't
>> > something like this (below) defeat the controls in the planned ESAPI for
>> JS
>> > ?
>> >
>> > Sorry to
>> > still be dense on the topic. Please keep in mind I'm an supporter of
>> ESAPI in
>> > general, I just wish to understand.
>> >
>> > Best,
>> >
>> > Mike B.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > From: Felipe Moreno
>> > [mailto:felipe at wobot.org]
>> > Sent: Monday, December 14, 2009 11:15
>> > AM
>> > To: websecurity at webappsec.org
>> > Subject: [WEB SECURITY]
>> > [Tool Announcement] Groundspeed Firefox add-on
>> > I would like to announce the release of Groundspeed, an open
>> > source Firefox add-on to support manual webapp input validation
>> > testing.
>> >
>> > Groundspeed allows you to modify the target web application's
>> > interface by manipulating the forms and form elements loaded in the
>> page, in
>> > order to remove client-side controls and limitations.
>> >
>> > Some of the
>> > practical uses include changing hidden fields, select drop down lists
>> and other
>> > fields into text fields, removing size and length limitations on input
>> fields
>> > and modifying JavaScript event handlers to bypass client side validation
>> without
>> > actually removing it.
>> >
>> > You can find more information and download
>> > Groundspeed here: http://groundspeed.wobot.org
>> > --
>> >
>> > Felipe
>> >
>> >
>>
>
>
>
> --
> -- Chris
>
> OWASP ESAPI Developer
> http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
>
> Check out OWASP ESAPI for Java
> http://code.google.com/p/owasp-esapi-java/
>
> Coming soon OWASP ESAPI for JavaScript
> http://code.google.com/p/owasp-esapi-js/
>

-- 
-- Chris

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

Coming soon OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20091214/055be525/attachment.html 