Page Flow Controller in no-script mode

Jasper,

I found some issues with the ATM example in noscript mode, not sure if
they are the same you found:

1. There was an assertion that failed because a submission path was
not properly resolved.

http://forge.ow2.org/tracker/index.php?func=detail&aid=315406&group_id=168&atid=350207

2. By default, the page flow issues redirects, which our HTTP client
doesn't resolve by default. But here an HTTP submission shouldn't be
issue in the first place.

http://forge.ow2.org/tracker/index.php?func=detail&aid=315407&group_id=168&atid=350207

We will be looking into these.

You are right that submissions imply services exposed through HTTP. If
services are implemented by Orbeon Forms and running on the same
server, as will likely be the case when you use services to implement
page navigation, they better be protected, otherwise problems can
follow, as you realized.

A this point, we do not have a built-in solution for this. As you
noted, implementations usually are placed behind an Apache server or
similar setup. For example we have some minimal information on
specifically securing Form Runner services here:

http://wiki.orbeon.com/forms/doc/user-guide/form-runner-user-guide#TOC-Securing-Form-Runner

Now we like the idea of trying to secure this out of the box. Could
you flesh this out a little bit? Even better would be on the wiki. I
am happy to give you write access if you like.

-Erik

On Thu, Aug 26, 2010 at 5:40 AM, Jasper Linthorst
<[hidden email]> wrote:
> Hi Erik/Alessandro,
> I'm experiencing problems when using the page flow controller with Orbeon in
> no-script mode (just have a look at the ATM example in no-script mode).
> Could you let me know if there's a way to make this work, aside from
> switching to script-mode? TIA.
> Because of the problem mentioned above I've decided to switch to using
> submissions (with replace=all) from my xform in order to navigate from one
> xform to the other. This works fine, but made me think of the fact that the
> instance data passed in to a form can be submitted from any client, so there
> is no way to make sure that the data received in form2 was submitted by
> form1 (or at least the same orbeon server). Meaning that a hacker with
> knowledge of the used datamodel, can fake the instance dat we use to build
> our form (or submit to out pipeline). Am I correct?
> I would like to know if Orbeon comes with a solution to this problem (aside
> from fixing things through apache, url-rewriting, checking the remote-host
> or chaning the business logic), like only allow local-submissions to
> generate instance data, or maybe have the xforms server sign (using xml-dsig
> or something) and validate the submitted instance data to make sure it came
> from the same xforms-server. Please let me know if there's a solution to
> this already, or if I'm making the wrong assumptions. If not, I'd be happy
> to contribute something to fix this, let me know...
> Regards,
> Jasper
>

> --
> You receive this message as a subscriber of the [hidden email] mailing
> list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Hi Erik,

Thanks for your reply. I'm monitoring the isssues you created for the pfc in no-script mode.

My idea for securing this out-of-the-box would be to:

- extend the current submission handler with some sort of xxforms:sign or xxforms:encrypt attribute to be set.

- add properties to point out a keypair or keystore.

- use some javax.xml.crypto implementation to canonicalize/sign/encrypt the instance data that's submitted.

I think that would be all for the submitting part.

For the validation/decryption part I think we could settle with a certain processor that's called manually or from within the pfc/epilogue or something.

If you agree to the above, I'd be happy to write some things down on the wiki, but it would take some time since I'm pretty busy at the moment.

Feedback is very much appreciated!

Jasper

On Mon, Aug 30, 2010 at 7:32 PM, Erik Bruchez <[hidden email]> wrote:

Jasper,

I found some issues with the ATM example in noscript mode, not sure if
they are the same you found:

1. There was an assertion that failed because a submission path was
not properly resolved.

http://forge.ow2.org/tracker/index.php?func=detail&aid=315406&group_id=168&atid=350207

2. By default, the page flow issues redirects, which our HTTP client
doesn't resolve by default. But here an HTTP submission shouldn't be
issue in the first place.

http://forge.ow2.org/tracker/index.php?func=detail&aid=315407&group_id=168&atid=350207

We will be looking into these.

You are right that submissions imply services exposed through HTTP. If
services are implemented by Orbeon Forms and running on the same
server, as will likely be the case when you use services to implement
page navigation, they better be protected, otherwise problems can
follow, as you realized.

A this point, we do not have a built-in solution for this. As you
noted, implementations usually are placed behind an Apache server or
similar setup. For example we have some minimal information on
specifically securing Form Runner services here:

http://wiki.orbeon.com/forms/doc/user-guide/form-runner-user-guide#TOC-Securing-Form-Runner

Now we like the idea of trying to secure this out of the box. Could
you flesh this out a little bit? Even better would be on the wiki. I
am happy to give you write access if you like.

-Erik

On Thu, Aug 26, 2010 at 5:40 AM, Jasper Linthorst
<[hidden email]> wrote:
> Hi Erik/Alessandro,
> I'm experiencing problems when using the page flow controller with Orbeon in
> no-script mode (just have a look at the ATM example in no-script mode).
> Could you let me know if there's a way to make this work, aside from
> switching to script-mode? TIA.
> Because of the problem mentioned above I've decided to switch to using
> submissions (with replace=all) from my xform in order to navigate from one
> xform to the other. This works fine, but made me think of the fact that the
> instance data passed in to a form can be submitted from any client, so there
> is no way to make sure that the data received in form2 was submitted by
> form1 (or at least the same orbeon server). Meaning that a hacker with
> knowledge of the used datamodel, can fake the instance dat we use to build
> our form (or submit to out pipeline). Am I correct?
> I would like to know if Orbeon comes with a solution to this problem (aside
> from fixing things through apache, url-rewriting, checking the remote-host
> or chaning the business logic), like only allow local-submissions to
> generate instance data, or maybe have the xforms server sign (using xml-dsig
> or something) and validate the submitted instance data to make sure it came
> from the same xforms-server. Please let me know if there's a solution to
> this already, or if I'm making the wrong assumptions. If not, I'd be happy
> to contribute something to fix this, let me know...
> Regards,
> Jasper
>

> --
> You receive this message as a subscriber of the [hidden email] mailing
> list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws