35 ms·

Do you even need to play with DNS caching? Aren’t subdomains excluded from cross-origin request blocking? Can badsite.com request a resource from subdomain.ba

by joemag 8y ago

Do you even need to play with DNS caching? Aren’t subdomains excluded from cross-origin request blocking? Can badsite.com request a resource from subdomain.badsite.com, and the browser will allow it. The JavaScript on badsite.com can be clever then, and begin probing <ip>.badsite.com, so all badsite DNS need to do is resolve that to <ip>.

detaro 8y ago
Same origin policy is an exact match on the protocol/domain/port tuple, so subdomains are not same origin.
- angry_octet 8y ago
  While this is true, it is complicated by TLS terminating cloud services and the complexity nightmare that is TLS. For example, sub-domain takeover. Basically, TLS rules don't behave exactly as CORS: https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aws-and-trailing-dot-domains/ https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aw... You could also use the dangling domain to get a Let's Encrypt certificate. It is quite common for sites to allow cross-origin loading from their own subdomains, with CORS and CSP headers.
dividuum 8y ago
Subdomains are excluded: the same-origin policy prevents that. You can still request resources (like images) from other domains, but usually there's no direct way to access the response to such requests. So you can't just fetch some JSON data from an API endpoint from another domain unless it's explicitly allowed by CORS, or workarounds like JSONP are available. If the target doesn't implement CSRF protection, this might still be enough to trigger unwanted actions. So if I add <img src='http://192.168.1.1/cgi-bin/reboot.cgi'> http://192.168.1.1/cgi-bin/reboot.cgi'> to a website, this might reboot your router, if it's rubbish. No rebinding needed for that. Rebinding enables you to do more than that. A vulnerable service can be interacted with just like your local backend. So you can send queries and read responses.

by joemag 8y ago

detaro 8y ago

Same origin policy is an exact match on the protocol/domain/port tuple, so subdomains are not same origin.

angry_octet 8y ago
While this is true, it is complicated by TLS terminating cloud services and the complexity nightmare that is TLS. For example, sub-domain takeover. Basically, TLS rules don't behave exactly as CORS: https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aws-and-trailing-dot-domains/ https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aw... You could also use the dangling domain to get a Let's Encrypt certificate. It is quite common for sites to allow cross-origin loading from their own subdomains, with CORS and CSP headers.

dividuum 8y ago

Subdomains are excluded: the same-origin policy prevents that. You can still request resources (like images) from other domains, but usually there's no direct way to access the response to such requests. So you can't just fetch some JSON data from an API endpoint from another domain unless it's explicitly allowed by CORS, or workarounds like JSONP are available. If the target doesn't implement CSRF protection, this might still be enough to trigger unwanted actions. So if I add <img src='http://192.168.1.1/cgi-bin/reboot.cgi'> http://192.168.1.1/cgi-bin/reboot.cgi'> to a website, this might reboot your router, if it's rubbish. No rebinding needed for that. Rebinding enables you to do more than that. A vulnerable service can be interacted with just like your local backend. So you can send queries and read responses.