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" <rgur...@smarthealth.com> 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 <msch...@pobox.com> 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/Aut
>>>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      (Webobjects-dev@lists.apple.com)
>>> >>> Help/Unsubscribe/Update your Subscription:
>>> >>> 
>>>http://lists.apple.com/mailman/options/webobjects-dev/george%40boxoffice
>>>tickets.com
>>> >>>
>>> >>> This email sent to geo...@boxofficetickets.com
>>> >>
>>> >
>>> > _______________________________________________
>>> > Do not post admin requests to the list. They will be ignored.
>>> > Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>> > Help/Unsubscribe/Update your Subscription:
>>> > 
>>>http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.co
>>>m
>>> >
>>> > This email sent to msch...@pobox.com
>>> 
>>>  _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> 
>>>http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.c
>>>o.uk
>>> 
>>> This email sent to si...@potwells.co.uk
>>> 
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> 
>>>http://lists.apple.com/mailman/options/webobjects-dev/jmb-dev%40burzler.
>>>eu
>>> 
>>> This email sent to jmb-...@burzler.eu
>> 
>> -- 
>> Dr. Josef Burzler
>> 
>> Phone    +49-(0)941-69 84 84-37
>> j.burz...@selbstdenker.ag
>> 
>> ===================================
>> 
>> 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
>> 
>> b...@selbstdenker.ag
>> 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      (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> 
>>http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smartheal
>>th.com
>> 
>> This email sent to rgur...@smarthealth.com
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>Help/Unsubscribe/Update your Subscription:
>http://lists.apple.com/mailman/options/webobjects-dev/drosenberg%40inquira
>.com
>
>This email sent to drosenb...@inquira.com

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to