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 drosenb...@inquira.com wrote:
the general idea behind the OWASP approach is to provide encoders that
will make your user input strings safe so that
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
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 ...
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
My recommendation is to only use cookie session ids and actually throw very
early if you get a URL session id.
Sent from my iPhone
On Jul 12, 2011, at 3:36 AM, Simon si...@potwells.co.uk wrote:
i think core WO is still plagued with the wosid cross-scripting issue too. we
patch it in
I never understood that JIRA. How does the bad session ID get back into the
page? I would expect a session restoration error page if a bad session ID were
maliciously injected.
Ramsey
On Jul 12, 2011, at 6:51 AM, Mike Schrag wrote:
My recommendation is to only use cookie session ids and
That patch has been languishing in my inbox for almost a year now.
On Jul 12, 2011, at 12:36 AM, Simon wrote:
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
here you go, i just found a WO powered site on the web that will kindly
demonstrate the issue. it is sensitive to encoding, but this link should
work in chrome and firefox (not got any IE's nearby to test):
That looks like it may be an issue with ERXWOForm._appendHiddenFieldsToResponse
instead of ERXRequest.
Do you have any other examples of where this can occur?
Ramsey
On Jul 12, 2011, at 12:32 PM, Simon wrote:
here you go, i just found a WO powered site on the web that will kindly
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
nice one! yeah, that works. whacks in a new text field into your page
and gives it focus :-)
https://secure.kagi.com/cgi-bin/WebObjects/PQ?wosid=3D%22%3E%3Cinput%20onfocus=write(1)%20autofocus%3E
the wosid parameter in a webobjects url is a gaping backdoor for cross
site scripting (whether you
That's my main concern. It is happening on every ERXRequest. I'd rather not
waste the cycles if it can be handled in one method on ERXWOForm. Given the
info I have now, I'd be inclined to change the boolean arg at line 251 on
ERXWOForm and mark it fixed. Are there any other examples related
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
That is one case, but I think there are others. I don't think that an
ERXWOForm fix is going to get them all.
On Jul 12, 2011, at 5:23 PM, Ramsey Gurley wrote:
That's my main concern. It is happening on every ERXRequest. I'd rather not
waste the cycles if it can be handled in one method
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/Authentication_and_Security
However, there is no mention about SQL injections which seems to be an active
subject lately. Is
You want to use a plugin that uses bind variables and exclusively use EOF API's
for SQL generation. That's the best thing you can do to prevent sql injection.
ms
On Jul 11, 2011, at 9:01 PM, Mai Nguyen wrote:
Hello,
I have found some good information about WebObjects and security at the
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
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
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
Would it be sufficient to make sure that input strings (WOStrings) have
escapeHTML = true? or is it better to just strip HTML ourselves?
The wiki says:
If you are certain that your strings have no characters in them which might be
interpreted as HTML control characters, you get better
:59:37 -0700
To: Mike Schrag msch...@pobox.commailto:msch...@pobox.com
Cc: WebObjects Development
webobjects-dev@lists.apple.commailto:webobjects-dev@lists.apple.com
Subject: Re: WebObjects vulnerabilities?
Would it be sufficient to make sure that input strings (WOStrings) have
escapeHTML = true
21 matches
Mail list logo
