<div dir="ltr">A previous suggestion from the public was to explicitly only allow successful (200) results. Allowing 301 is arguably equally problematic.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 4:14 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jeremy,<br>
<br>
I’ve found a possible vulnerability with 3.2.2.4.6. Agreed-Upon Change to Website.  If the Random Value or Request Token is contained in the URI path, then certain websites will return it in the meta tag of the resulting page.  The pattern I found on a real website is:<br>
<br>
Request <a href="http://www.example.com/.well-known/pki-validation/06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b" rel="noreferrer" target="_blank">http://www.example.com/.well-known/pki-validation/06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b</a><br>
Returns 301 with Location: /search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b<br>
Request <a href="http://www.example.com/search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b" rel="noreferrer" target="_blank">http://www.example.com/search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b</a><br>
Returns 200 with a page containing:<br>
<meta property="og:title" content=".well-known/pki-validation/06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b: Search Results from Example"><br>
<meta property="og:url" content="<a href="http://www.example.com/search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b" rel="noreferrer" target="_blank">http://www.example.com/search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b</a>”><br>
<br>
I think this method needs to be updated to preclude the CA from using a URL containing the Random Value or Request Token.<br>
<br>
Thanks,<br>
Peter<br>
<span class="im HOEnZb"><br>
> On Apr 26, 2016, at 2:40 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
><br>
> Below (and attached) are the revised validation requirements. I’m looking for two endorsers.<br>
><br>
</span><span class="im HOEnZb">> 3.2.2.4.6. Agreed-Upon Change to Website<br>
> Confirming the Applicant's control over the requested FQDN by confirming the presence of a Random Value or Request Token (contained in the content of a file or on a web page in the form of a meta tag) under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that can be validated over an Authorized Port.<br>
><br>
> If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of (i) 30 days or (ii) if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines)<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div>