Implementing Google Safe Browsing server-side to sanitize untrusted input

#1

Post by kellanem » Mon, Mar 05, 2012, 1:19 PM UTC

Implementing Google Safe Browsing server-side to sanitize untrusted input
codeascraft.etsy.com

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#2

Post by nodata » Mon, Mar 05, 2012, 2:58 PM UTC

Privacy implications?

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#3

Post by jusob » Mon, Mar 05, 2012, 3:12 PM UTC

nodata wrote: post #2

Privacy implications?

With GSBv2, no URL is sent to Google. They recently introduced the Lookup API where users need to send the URL, but this is not what Etsy is using.

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#4

Post by obtu » Mon, Mar 05, 2012, 3:45 PM UTC

Interesting idea. There are some extra challenges when the scanning is not done live.

Does Etsy accept url shorteners? Including some that allow editing? Is it feasible to rewrite the content to have the redirected URLs?

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#5

Post by indec » Mon, Mar 05, 2012, 3:59 PM UTC

nodata wrote: post #2

Privacy implications?

The privacy risk for GSB in general is that you are sharing URLs with a (trusted) third party. That's most acute with the REST API, but most implementations (including gsb4ugc) cache a local copy of the lookup tables and so don't actually send URLs to Google. There is still a very occasional need to send a link to Google for validation, but in the server-side case the only context Google has for the request is the IP address of the server, which minimizes privacy risks as much as possible.

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#6

Post by indec » Mon, Mar 05, 2012, 4:12 PM UTC

obtu wrote: post #4

Interesting idea. There are some extra challenges when the scanning is not done live. Does Etsy accept url shorteners? Including some that allow editing? Is it feasible to rewrite the content to have the redirected URLs?

We "unroll" redirects as much as possible so that we can check the URL at the end.

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#7

Post by obtu » Mon, Mar 05, 2012, 5:25 PM UTC

indec wrote: post #6

obtu wrote: post #4

Interesting idea. There are some extra challenges when the scanning is not done live. Does Etsy accept url shorteners? Including some that allow editing? Is it feasible to rewrite the content to have the redirected URLs?

We "unroll" redirects as much as possible so that we can check the URL at the end.

In the sense of following them, or rewriting them as well?

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#8

Post by indec » Mon, Mar 05, 2012, 6:10 PM UTC

obtu wrote: post #7

indec wrote: post #6

Earlier quoted context omitted.

We "unroll" redirects as much as possible so that we can check the URL at the end.

In the sense of following them, or rewriting them as well?

We follow them on the server side and check the final URL we get to against the GSB database. We don't modify the user-generated content.

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#9

Post by underwater » Mon, Mar 05, 2012, 6:49 PM UTC

indec wrote: post #8

obtu wrote: post #7

Earlier quoted context omitted.

In the sense of following them, or rewriting them as well?

We follow them on the server side and check the final URL we get to against the GSB database. We don't modify the user-generated content.

I assume you check each step of the unrolling? Otherwise a malicious site could easily do:

   if (is_etsy_ip()) header('Location: http://www.google.com/') && die();

Re: Implementing Google Safe Browsing server-side to sanitize untrusted input

#10

Post by indec » Tue, Mar 06, 2012, 2:50 AM UTC

underwater wrote: post #9

indec wrote: post #8

Earlier quoted context omitted.

We follow them on the server side and check the final URL we get to against the GSB database. We don't modify the user-generated content.

I assume you check each step of the unrolling? Otherwise a malicious site could easily do: if (is_etsy_ip()) header('Location: http://www.google.com/') && die();

Well, generally following the redirects is actually somewhat redundant. The idea of GSB is that URLs that lead to bad things would all be identified and added to the database.

Customising attacks for a given site specifically adds complexity and cost to the attack, which is really the aim for all of this sort of work. Everything you can do to drive up the cost of the attack makes you a less inviting target.

It would be a mistake to think that usb4ugc (or tools like it) would protect everyone all the time. It's never a replacement for vigilance and education on the user-side, just a useful extra line of defense.