Subresource integrity

[Alwin Goh]

For anyone who can answer,

Is it possible to use subresource integrity (sri) on google recaptcha?

Would it be futile to even attempt to download the api.js file and generate an sri hash for it manually with ssh coz the js file has dynamic contents?

Is there any way to solve this class of problems using SRI checking or otherwise?

Thanks
Alwin

[Mike O]

Hey Alwin,

Did you ever find an answer to this? I'm implementing SRI now and have the same question. It's the only external resource we use that can't be moved locally.

Thanks,

Mike

[nma...@gmail.com]

I was checking this out today, and I don't think this is feasible.

As you mentioned, the issue is that Google changes the contents of the api.js file frequently. If you look at it yourself (it's a small file), you can see it mainly loads another, larger script. Right now, that script is https://www.gstatic.com/recaptcha/api2/v1525372547704/recaptcha__en.js. But you can see there's a timestamp right in the url (in milliseconds, so that's 11:35:47 PDT on May 3, 2018).

I tried downloading api.js and serving it myself, and it does work. But then you'll always be using the same version, which will become increasingly out of date. This probably misses the whole point of using reCAPTCHA, since I assume those frequent updates are to stay ahead of spammers as they learn how to circumvent it.

If it's any consolation, this is Google we're talking about, so I wouldn't worry much about malicious spoofing or changes to the script. If you're using an https link, no one can intercept the connection and serve a malicious version of the script, especially since Google's TLS is top-notch and they stay on top of new attacks and spoofed certificates. And it's not like you can really review the code anyway, so including this script at all means trusting whatever Google wants to serve.

Nick