Hacker News Reader

Comment by desdiv | Hacker News Reader

>The malware obtains the time and date by creating a new environment variable called $hcresult that contains what’s being returned by sending an HTTP request to the Google hosted link by executing this command:

>curl -sL https://script.google.com/macros/s/AKfycbyd5AcbAnWi2Yn0xhFRb...

What the hell, Google? Your domain name is one of the most trusted on the internet and yet you're hosting random user submitted scripts on there? What happened to googleusercontent.com?

View on HN

Looks like its getting the current time from the json response. How dare Google distribute the current time?

The parent comment isn't talking about the payload being returned, it's about what domain Google is hosting user content on.

The response from script.google.com is a 302 redirect to script.googleusercontent.com. IOW, google.com itself does not serve that user content.

But why does Google redirect that? Why not just return an error?

It's not like users will accidentally type in script.google.com and get mad if it fails. Those script URLs are being used only by app developers, who will test their apps and fix script source URLs that are broken. Calling a googleusercontent script at google.com should return a 4xx status code telling them to use the googleusercontent domain.

Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.

>Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.

I think you should read this again and then take a moment to think about the services people primarily visit google.com for.

Also, what exactly are "trusted domains"? Why do they matter to users clicking links?

On a website there's no way for an user to verify where a link is going to take them without actually clicking the link. The tooltip for example tends to be relatively easy to spoof.

The point is that it's an arbitrary user submitted script. In this case it was just the time, but it could have easily been a botnet command and control message or some other malicious content.

It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.

>It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.

But it is being served under googleusercontent.com?

Reply on news.ycombinator.com