<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 15, 2013 at 4:16 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 14/11/13 19:58, Christopher Armstrong wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Nov 14, 2013 at 10:44 AM, Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>>> wrote:<br>
<br>
    On 14/11/13 18:51, Randall Burt wrote:<br>
<br></div><div class="im">
        Perhaps, but I also miss important information as a legitimate<br>
        caller as<br>
        to whether or not my scaling action actually happened or I've been a<br>
        little too aggressive with my curl commands. The fact that I get<br>
        anything other than 404 (which the spec returns if its not a<br>
        legit hook)<br>
        means I've found *something* and can simply call it endlessly in<br>
        a loop<br>
        causing havoc. Perhaps the web hooks *should* be authenticated? This<br>
        seems like a pretty large hole to me, especially if I can max<br>
        someone's<br>
        resources by guessing the right url.<br>
<br>
<br>
    Web hooks MUST be authenticated.<br>
<br>
<br>
<br>
Do you mean they should have an X-Auth-Token passed? Or an X-Trust-ID?<br>
</div></blockquote>
<br>
Maybe an X-Auth-Token, though in many cases I imagine it would be derived from a Trust. In any event, it should be something provided by Keystone because that is where authentication implementations belong in OpenStack.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The idea was that webhooks are secret (and should generally only be<br>
passed around through automated systems, not with human interaction).<br>
This is usually how webhooks work, and it's actually how they work now<br>
in Heat -- even though there's a lot of posturing about signed requests<br>
and so forth, in the end they are literally just secret URLs that give<br>
you the capability to perform some operation (if you have the URL, you<br>
don't need anything else to execute them). I think we should simplify<br>
this to to just be a random revokable blob.<br>
</blockquote>
<br></div>
This is the weakest possible form of security - the whole secret gets passed on the wire for every request and logged in innumerable places. There's no protection at all against replay attacks (other than, hopefully, SSL).<br>

<br>
A signature, a timestamp and a nonce all seem like prudent precautions to add.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I can get behind the idea of adding timestamp and nonce + signature for the webhooks, as long as they're handled better than they are now :) i.e., the webhook handler should assert that the timestamp is recent and non-repeated. This probably means storing stuff in MySQL (or a centralized in-memory DB). My understanding is that even though we have signed URLs for webhooks in the current Heat autoscaling system, they're effectively just static blobs.</div>
<div><br></div><div>My original proposal for simple webhooks was based entirely around the idea that the current stuff is too complex, and offers no additional security over a random string jammed into a URL. (signing a static random string doesn't make it more guessable than the original random string...)</div>
</div><div><br></div>-- <br><div dir="ltr"><div>IRC: radix</div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>