[thelist] Webhook security

[Bill Moseley]

On Tue, Aug 28, 2012 at 11:05 AM, Jay Turley <jayturley at gmail.com> wrote:

> If you made all the callbacks from JavaScript using AJAX, would the
> built-in cross-domain policy prevent requests to a degree sufficient for
> your purposes?
>

Not sure we are talking about the same thing.   Maybe webhook was the wrong
term to use.

Imagine there's a RESTful web service where you can submit an order for
processing and you want to know when the order was shipped.

One option is to poll the service to check if the item was shipped.

Another option is when you submit the order you include a URL that the
service can later request when the order is shipped.  It's a notification
of an event.

It's similar to PayPal's IPN callbacks, except that with IPN you have to
call back to PayPal to authenticate that the data that was just sent by (we
assume) PayPal.

My question is about ways to authenticate that the request is really coming
from the right place without using something like PayPal's IPN that
requires another request.





>
> -Jay
>
> On Aug 28, 2012, at 9:52 AM, Bill Moseley <moseley at hank.org> wrote:
>
> > I want to implement webhooks -- user-defined URL callbacks that happen
> with
> > some event on our servers.   I would require all webhook (callbacks) over
> > SSL so that puts a requirement on the system I'm calling to support SSL,
> > which I'm ok with.
> >
> > How can the system I'm calling authenticate that the request is coming
> from
> > my servers?   Since I require SSL one option is client certificates.
> I've
> > not implemented client-side certs before, so not sure what is involved.
> > But, it seems like the best option.
> >
> > Our IP addresses may change or come from different machines so they
> cannot
> > be used.
> >
> > I could use some shared secret and build a hash of the return data to
> prove
> > I know the secret.   But, that does not prove the request is coming from
> my
> > servers -- just that whoever sent the request knows the secret.
> >
> > And by that logic if I know the shared secret, and I send over SSL then I
> > could just send the shared secret back in the request without hashing any
> > of the data and just the fact that I'm sending the shared secret should
> > validate the request is coming from me (because only I know the secret).
> >
> > I don't like overly complex hashing of parameters and all that when SSL
> > really handles authentication, message signing, man-in-the-middle, and
> > replay attack issues.
> >
> > --
> > Bill Moseley
> > moseley at hank.org
> > --
> >
> > * * Please support the community that supports you.  * *
> > http://evolt.org/help_support_evolt/
> >
> > For unsubscribe and other options, including the Tip Harvester
> > and archives of thelist go to: http://lists.evolt.org
> > Workers of the Web, evolt !
> --
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>



-- 
Bill Moseley
moseley at hank.org