| ▲ | seszett 2 days ago |
| No, you can't expect everyone to know about every subdomain of google.com. I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive). |
|
| ▲ | michaelmior 2 days ago | parent | next [-] |
| > I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive). IIRC, this is the main reason GitHub moved Pages to github.io |
| |
| ▲ | michaelt 2 days ago | parent [-] | | The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies. This is why your gmail attachments should show up on googleusercontent.com instead of google.com Many years ago, some naive websites would let users upload images, but wouldn't validate their content; and some browsers would ignore file content type headers if they had a better guess. So an attacker could rename a .html to a .jpg, upload it as your user profile image, then direct people to www.example.com/avatars/eviluser.jpg and they'd get a HTML page and run its javascript. That's why, to this day, you sometimes see websites sending the header "X-Content-Type-Options: nosniff" which tells Internet Explorer 8 not to guess the content type. | | |
| ▲ | aaronmdjones 2 days ago | parent | next [-] | | > The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies. This was solved a long time ago by marking such cookies as "HTTP only", preventing client-side scripts from reading their values. Google does mark their account login cookies as both "Secure" (sent only over HTTPS) and "HttpOnly" (not exposed to client-side scripting). You can see this in the server response headers in the browser dev tools' network tab. Even a piece of first-party JavaScript loaded directly from google.com -- even with SRI -- cannot read these cookies for google.com. | | |
| ▲ | michaelt a day ago | parent [-] | | > This was solved a long time ago by marking such cookies as "HTTP only" That stops the attacker from exfiltrating your cookies with their evil JavaScript - but they can still have their script make http requests, and they’ll be made with your cookies. Or they can throw up a fake login page, which will fool plenty of users because it’s on the right URL, and do what they like with your inputs. Lots of attack options. | | |
| ▲ | blincoln 10 hours ago | parent [-] | | This is true, but additionally, the HttpOnly flag is now mostly a relic, because so much web app logic runs in JS in the browser and makes API calls. That code generally needs access to tbe cookies, or something equivalent, like a bearer token. |
|
| |
| ▲ | EE84M3i 2 days ago | parent | prev [-] | | SVGs are also images that can contain scripts if not validated. It's also relevant that github.io is on the public suffic list, which impacts a bunch of downstream things and isolates the subdomains from each other. | | |
| ▲ | fc417fc802 2 days ago | parent [-] | | > if not validated I thought script tags were an official part of SVG? Meaning that a valid SVG can contain embedded JS. | | |
|
|
|
|
| ▲ | asimpletune 2 days ago | parent | prev | next [-] |
| The main failure is that dkim still passed even though the email was modified in important ways. |
| |
| ▲ | seszett 2 days ago | parent | next [-] | | Well there are a few different big failures, from not signing the To: to allowing long arbitrary content in an email sent from a legitimate Google address... But I think Google sites is the most important one because it makes sites look like they are actually Google wherever one comes from, it could be a pop-under loaded by another site or whatever, I think it's a more universal avenue for phishing than just exploiting DKIM. | | |
| ▲ | aaronmdjones 2 days ago | parent [-] | | The To header was included in the DKIM signature. The reproduction section of the article shows the result of final delivery to the victim which shows the original To header. If that were removed it would invalidate the signature. |
| |
| ▲ | aaronmdjones 2 days ago | parent | prev [-] | | The body of the e-mail was not modified whatsoever. Nor were any of the signed headers of the e-mail, including the Subject, From, and To headers. |
|
|
| ▲ | pbhjpbhj 2 days ago | parent | prev | next [-] |
| There have been a few exploits over the years relying on sites.google.com because of the need to use a subdomain to make things work for the exploiters. I don't think I've ever seen Google advertise Sites either? Why not GoogleSites.com? |
|
| ▲ | iwontberude 2 days ago | parent | prev [-] |
| This criticism is not for everyone, it’s for us, the audience on HN that want novel stuff that is more hard than this. This is boring. |
