-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug,

I've been using Jakarta Struts lately, and they have a nifty Java-based
forms validation package ("Struts Validator") in it. It is just about
100% declarative, although the the downside is that you need to have
already bought into the Struts MVC world view. If you are doing a Struts
application, it fits in very nicely.

I view this as being highly complementary to the OWASP filters project,
so use of one should not preclude the other.

Just to give you a taste, here's a snip from the validation.xml that file:

<form name="registrationForm">
~ <field property="givenname"
~ depends="required,mask,minlength,maxlength">
~ <arg0 key="registrationForm.firstname.displayname"/>
~ <arg1 name="minlength" key="${var:minlength}" resource="false"/>
~ <arg1 name="maxlength" key="${var:maxlength}" resource="false"/>
~ <var>
~ <var-name>mask</var-name>
~ <var-value>^\w+$</var-value>
~ </var>
~ <var>
~ <var-name>minlength</var-name>
~ <var-value>2</var-value>
~ </var>
~ <var>
~ <var-name>maxlength</var-name>
~ <var-value>50</var-value>
~ </var>
~ </field>
~ <field property="sn"
~ depends="required,mask,minlength,maxlength">
~ <msg name="mask" key="registrationForm.lastname.maskmsg"/>
~ <arg0 key="registrationForm.lastname.displayname"/>
~ <arg1 name="minlength" key="${var:minlength}" resource="false"/>
~ <arg1 name="maxlength" key="${var:maxlength}" resource="false"/>
~ <var>
~ <var-name>mask</var-name>
~ <var-value>^[a-zA-Z]*$</var-value>
~ </var>
~ <var>
~ <var-name>minlength</var-name>
~ <var-value>2</var-value>
~ </var>
~ <var>
~ <var-name>maxlength</var-name>
~ <var-value>50</var-value>
~ </var>
~ </field>
~ ...
</form>

There are lots of articles on Struts, but none on secure forms design --
so I'm planning on writing a short article on this (in my copious free
time).

Best,

- --
Andrew Jaquith
Program Director
stake, Inc.
196 Broadway
Cambridge, MA 02139 USA
Email: ajaquithatstake.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546

Mark Curphey wrote:
| Intetresting you mention that but its a problem the
| OWASP Filters project is working on. It won't use a
| tag to mark code as untrusted however. There were
| some initial dealys in design but having spent some
| time with a few of the members recently, I know
| there will be working code with a few months for a
| few languages.
|
| Essentially they will produce some easy to impement
| API's that filter input and output making it easy
| for developers to do the right thing. It will be
| based on the concept of defining what is correct and
| expected input and then a set of stackable rules if
| you need to loosen things up or can't accuratly
| define that for various reasons. They will
| canonicalise input to specific character sets as
| part of the parsing process.
|
| A vision document will be posted on the OWASP site
| by the end of the week if your interested.
|
|
|
|
| ---- Doug Sibley <doug.sibleybmo.com> wrote:
|
|>
|>Hi,
|>
|>I think what we need to come up with is an easy
|
| way for
|
|>developers to create web-apps with user content in
|
| them
|
|>that isn't vulnerable to XSS. Expecting developers
|
| to
|
|>filter everything nicely and teaching them about
|>different javascript-type vulnerabilities is hard
|
| and
|
|>won't be successful (just think of all the
|
| egregious
|
|>security errors you've run across when dealing
|
| with web
|
|>apps).
|>
|>We need something like a tag a developer can use to
|>mark content as untrusted to the browser:
|><untrusted level="allow_static_html"
|>randomChallenge="AX7KSLKXLKJ23N"> $USER_INPUT
|></untrusted randomChallenge="AX7KSLKXLKJ23N">.
|
| Here the
|
|>malicious user couldn't insert any active code
|
| because
|
|>the browswer's rendering engine would turn off
|
| active
|
|>code (scripting, java, plugins, etc.) until a
|></untrusted> with the correct server-generated
|>randomChallenge. The default security level would
|>disable all HTML (leaving just plain-text). The
|>disadvantage to this solution is that (a) browsers
|>would need updating, and (b) good random numbers
|
| would
|
|>be needed.
|>
|>We could also go for a server solution/language
|>solution with embedded directives in pages. The
|
| format
|
|>would be similarly, a custom tag such as <untrusted
|>level="no_html"> $USER_INPUT </untrusted> but it
|>wouldn't need browser changes or a random
|
| challenge.
|
|>The untrusted tag would get parsed and anything
|
| between
|
|>the tag pair would be sanitized before being sent
|
| to
|
|>the browser by the types of filters that are now
|>proposed to filter XSS. For various languages the
|
| tag
|
|>may instead be a function call or other mechanism.
|>
|>The main benefit of such a solution (I would favor
|>server-based) is that of simplicity. The developer
|>would only have to do one simple thing in order to
|>guard against XSS and if other characters (i.e.
|
| some
|
|>weird unicode sequence) or new browser 'feature'
|>provides a new XSS attack method, only one library
|>needs to be changed versus every application
|
| created.
|
|>Another application of the technique would be a
|>function (e.g. safeSelectSQL =
|>sanitizeSelectQuery($INPUT_QUERY)) that sanitizes
|>simple select queries from webpages so that a user
|>input could be pasted into a select query without
|
| fear
|
|>of database comprimise (of course, a new database
|
| user
|
|>with read-only priviliges could be created but
|
| this is
|
|>unlikely to happen from experience).
|>
|>My main point is that I think the ideas are there
|
| for
|
|>how to protect ourselves, we just need to get these
|>ideas into tools and into the hands of the
|
| developers
|
|>that need them.
|>
|>
|>Doug.SibleyBMO.com
|>Applied Cryptographer
|>Department of Information Security
|>Bank of Montreal Group of Companies
|>Work: 416-513-5296 | Cell: 416-529-4642
|>
|>
|
| ====================================================
|
|>Lock it. Password it. Protect it. Information
|
| Security
|
|>Verrouillage. Mot de passe. Protection : Sicuriti
|>Informatique
|>
|
| ====================================================
|
|>These are my personal opinions and not those of the
|>Bank of Montreal Group of Companies.
|>
|>
|

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPVFoLYmbq0aJjPVGEQI3WQCfXQpCxfgt3H4UtbFNXPIzJ+dIvW0An01y
6m6AKygniYAPGyylBFePIwWC
=iwAA
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]