Re: WebObjects vulnerabilities?
Re: WebObjects vulnerabilities?
- Subject: Re: WebObjects vulnerabilities?
- From: Dov Rosenberg <email@hidden>
- Date: Wed, 13 Jul 2011 07:29:25 -0700
- Acceptlanguage: en-US
- Thread-topic: WebObjects vulnerabilities?
It is all java based and has nothing to do with WebObjects or Project
Wonder. We didn¹t try to integrate it that deeply. I suppose someone could
tie it into the WOContext and inspect the incoming request parameters in a
generic fashion or integrate it into some base WOComponents that know how
to validate its params via a whitelist or provide methods to safely encode
user input but we didn¹t do any of those things.
Our usage was with our JSP application that uses our custom JSP tag lib
built against EOF. We are in the process of integrating it into our web
services as well (also built using EOF).
It is very easy to use and has a bunch of configuration options for
intrusion detection and logging that are pretty useful
Dov
On 7/13/11 12:32 AM, "Simon" <email@hidden> wrote:
>this sounds really interesting. is there any code you can share back
>with wonder around this stuff ?
>
>simoin
>
>On 13 July 2011 05:24, Dov Rosenberg <email@hidden> wrote:
>> the general idea behind the OWASP approach is to provide encoders that
>> will make your user input strings safe so that they wont activate some
>> malicious scripting. The other thing it provides is the ability to
>>define
>> parameter specific whitelists that can be validated using REGEX
>> expressions to ensure that the values that are provided are within an
>> acceptable domain range. Of course it is very to come up with an unsafe
>> REGEX expression that allows all sorts of bad behavior to come thru.
>>
>> We use both capabilities in our application. The REGEX portion is nice
>> because it allows you perform good data validation which is essential to
>> avoid cross site scripting errors.
>>
>> The encoders provide the ability to properly encode strings for various
>> uses like SQL, HTML, URLs, CSS, javascripts, LDAP
>>
>> In your example below, the onfocus parameter would use the ESAPI
>> encodeForJavascript() to convert the write(1) autofocus into HTML
>>encoded
>> text that would not be executable.
>>
>> Dov
>>
>> On 7/12/11 4:01 PM, "Ramsey Gurley" <email@hidden> wrote:
>>
>>>That's two votes for owasp it seems.... How does it handle new
>>>techniques
>>>introduced by html5? Will it catch stuff like:
>>>
>>><input onfocus=write(1) autofocus>
>>>
>>>Found a rather large list of these at html5sec.org
>>>
>>>Ramsey
>>>
>>>On Jul 12, 2011, at 5:05 AM, Josef Burzler wrote:
>>>
>>>> WO-Applications are indeed vulnerable to cross-site-scripting if
>>>>end-users are allowed to submit HTML.
>>>> An example would be an Online-HTML-editor which allows users to edit
>>>>formatted text in their browsers.
>>>>
>>>> In order to remove unwanted and malicious code from the submitted HTML
>>>>and avoid cross-site-Scripting issues one has to filter the submitted
>>>>content on server side.
>>>> For this task I have found AntiSamy to be a useful solution
>>>> https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
>>>>
>>>> Josef
>>>>
>>>>
>>>> Am 12.07.2011 um 09:36 schrieb Simon:
>>>>
>>>>> i think core WO is still plagued with the wosid cross-scripting issue
>>>>>too. we patch it in ERXRequest - not sure if the patch ever made it
>>>>>into wonder though...
>>>>>
>>>>> simon
>>>>>
>>>>>
>>>>> On 12 July 2011 02:43, Mike Schrag <email@hidden> wrote:
>>>>> You have to be mindful of ever rendering any tainted strings ... Any
>>>>>string that came from user input should be considered a risk for cross
>>>>>site scripting, so that's any field editable by a user, or any query
>>>>>parameter, etc. If you append those strings to response or <WOString>
>>>>>render them, make sure to escape HTML or strip HTML.
>>>>>
>>>>> ms
>>>>>
>>>>> On Jul 11, 2011, at 9:41 PM, Mai Nguyen wrote:
>>>>>
>>>>> > Do you mean the issue of malicious HTML tags?
>>>>> >
>>>>> > I wonder what would be the best way to prevent those?
>>>>> >
>>>>> > thanks,
>>>>> >
>>>>> > mai
>>>>> >
>>>>> >
>>>>> > On Jul 11, 2011, at 6:36 PM, George Domurot wrote:
>>>>> >
>>>>> >> If you output strings with escapeHTML=false, you could have an
>>>>>issue.
>>>>> >> You may want to consider stripping all potential tags from strings
>>>>>prior to rendering, or at the time of entry.
>>>>> >>
>>>>> >> -G
>>>>> >>
>>>>> >> On Jul 11, 2011, at 6:01 PM, Mai Nguyen wrote:
>>>>> >>
>>>>> >>> Hello,
>>>>> >>> I have found some good information about WebObjects and security
>>>>>at the following wiki link:
>>>>> >>>
>>>>> >>>
>>>>>http://en.wikibooks.org/wiki/WebObjects/Web_Applications/Development/A
>>>>>ut
>>>>>hentication_and_Security
>>>>> >>>
>>>>> >>> However, there is no mention about SQL injections which seems to
>>>>>be an active subject lately. Is WebObjects pretty safe, as there is no
>>>>>need to generate SQL directly and access to the DB is going through
>>>>>the
>>>>>EOs normally?
>>>>> >>> Are there any other loopholes that I am not aware of?
>>>>> >>> About the following article:
>>>>> >>> http://support.apple.com/kb/TA26730?viewlocale=en_US
>>>>> >>> Would the normal WebObjects behavior be pretty safe if one does
>>>>>not allow the user to enter HTML tags? Does Project Wonder do
>>>>>something
>>>>>in this area?
>>>>> >>>
>>>>> >>> Many thanks for your advice,
>>>>> >>>
>>>>> >>> -mai _______________________________________________
>>>>> >>> Do not post admin requests to the list. They will be ignored.
>>>>> >>> Webobjects-dev mailing list (email@hidden)
>>>>> >>> Help/Unsubscribe/Update your Subscription:
>>>>> >>>
>>>>>ce
>>>>>tickets.com
>>>>> >>>
>>>>> >>> This email sent to email@hidden
>>>>> >>
>>>>> >
>>>>> > _______________________________________________
>>>>> > Do not post admin requests to the list. They will be ignored.
>>>>> > Webobjects-dev mailing list (email@hidden)
>>>>> > Help/Unsubscribe/Update your Subscription:
>>>>> >
>>>>>co
>>>>>m
>>>>> >
>>>>> > This email sent to email@hidden
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>.c
>>>>>o.uk
>>>>>
>>>>> This email sent to email@hidden
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>r.
>>>>>eu
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> --
>>>> Dr. Josef Burzler
>>>>
>>>> Phone +49-(0)941-69 84 84-37
>>>> email@hidden
>>>>
>>>> ===================================
>>>>
>>>> SELBSTDENKER AG - No Vision Too Far
>>>>
>>>> Gesandtenstraße 10
>>>> 93047 Regensburg
>>>> Phone +49-(0)941-69 84 84-0
>>>> Fax +49-(0)941-69 84 84-99
>>>>
>>>> email@hidden
>>>> http://www.selbstdenker.ag
>>>>
>>>> Niederlassung: Regensburg
>>>> Handelsregister: Regensburg HRB 7860
>>>> Vorstand/CEO: Herr Stephan Fürnrohr
>>>> Vors. des Aufsichtsrates/Chairman of the board:
>>>> Herr Dipl. Betriebswirt (FH) Richard Sibinger
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>>al
>>>>th.com
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>>Do not post admin requests to the list. They will be ignored.
>>>Webobjects-dev mailing list (email@hidden)
>>>Help/Unsubscribe/Update your Subscription:
>>>ra
>>>.com
>>>
>>>This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>.uk
>>
>> This email sent to email@hidden
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden