5 ms·

The Cross-Origin check be circumvented via DNS Rebinding: When you request mypage.com, my DNS returns the ip of my webserver. On all subsequent requests, it wil

The Cross-Origin check be circumvented via DNS Rebinding: When you request mypage.com, my DNS returns the ip of my webserver. On all subsequent requests, it will return 127.0.0.1. Now localhost is on the same origin as my page.

lostjohnny 7y ago
It doesn't matter, you should be in control of a DNS the user relies on and you should have your server send Access-Control-Allow-Origin: mypage.com or Access-Control-Allow-Origin: * which is not a default anywhere AFAIK and is domain based, not IP based And your server should be enabled to respond to mypage.com host header
- chronial 7y ago
  I don't quite understand your comment. Do you mean "shouldn't" whenever you wrote "should"?
  - m12k 7y ago
    I think they write 'should' when they mean 'need to if you want the aforementioned to be a practical attack vector'
  - lostjohnny 7y ago
    yeah, I meant need, sorry
- chronial 7y ago
  Based on m12k's suggested interpretation of your comment: > you should be in control of a DNS the user relies on You always are when a users visits your domain – you control the DNS of your domain. > Access-Control-Allow-Origin: * You don't need access-control headers, because you stay on the same domain. > Your server should be enabled to respond to mypage.com host header Most servers listening on localhost ignore the host header.
  - tgragnato 7y ago
    The short TTL is very sketchy and most NIDS(s) have contextual rules to detect DNS rebinding attacks. One may additionally filter private ranges from responses and HTTP requests by host headers. Not to mention TLS. It's useful against vulnerable IoT devices or home routers, but is it still effective to breach enterprise perimeters?
  - lostjohnny 7y ago
    > You always are when a users visits your domain – you control the DNS of your domain. I meant you need to control the poisoned DNS If I use 8.8.8.8 as DNS you can only work on the domains you already control, which is kinda useless > You don't need access-control headers, because you stay on the same domain. No, you don't My localhost server only respond to localhost and 127.0.0.1 host header Not to mypage.com Nginx does taht too by default https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L37 https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L... But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it
    - tgragnato 7y ago
      > But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain > you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs to the same query, thus it'd be mypage.com and mypage.com (not www.mypage.com).. bypassing the same origin restrictions of the browsers. https://capec.mitre.org/data/definitions/275.html https://capec.mitre.org/data/definitions/275.html
      - lostjohnny 7y ago
        > In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs But it doesn't really work. I query my DNS, on my home router, not your DNS. And the DNS on my home router query the ISP's DNS, which caches requests. I bet you can't go below few minutes resolution. I had this problem when validating the Letsencrypt DNS challenge, I had to let certbot run for almost 20 minutes before my home router picked up the new value. When I'm at work, I use the company's DNS, which ignores non standard TTLs and caches the first answer forever (well... almost) and disallow external domains that resolve to reserved IP addresses.
X-Istence 7y ago
This is the reason why my local DNS resolver won't allow returning private IP space (including localhost).

lostjohnny 7y ago

It doesn't matter, you should be in control of a DNS the user relies on and you should have your server send Access-Control-Allow-Origin: mypage.com or Access-Control-Allow-Origin: * which is not a default anywhere AFAIK and is domain based, not IP based And your server should be enabled to respond to mypage.com host header

chronial 7y ago
I don't quite understand your comment. Do you mean "shouldn't" whenever you wrote "should"?
- m12k 7y ago
  I think they write 'should' when they mean 'need to if you want the aforementioned to be a practical attack vector'
- lostjohnny 7y ago
  yeah, I meant need, sorry
chronial 7y ago
Based on m12k's suggested interpretation of your comment: > you should be in control of a DNS the user relies on You always are when a users visits your domain – you control the DNS of your domain. > Access-Control-Allow-Origin: * You don't need access-control headers, because you stay on the same domain. > Your server should be enabled to respond to mypage.com host header Most servers listening on localhost ignore the host header.
- tgragnato 7y ago
  The short TTL is very sketchy and most NIDS(s) have contextual rules to detect DNS rebinding attacks. One may additionally filter private ranges from responses and HTTP requests by host headers. Not to mention TLS. It's useful against vulnerable IoT devices or home routers, but is it still effective to breach enterprise perimeters?
- lostjohnny 7y ago
  > You always are when a users visits your domain – you control the DNS of your domain. I meant you need to control the poisoned DNS If I use 8.8.8.8 as DNS you can only work on the domains you already control, which is kinda useless > You don't need access-control headers, because you stay on the same domain. No, you don't My localhost server only respond to localhost and 127.0.0.1 host header Not to mypage.com Nginx does taht too by default https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L37 https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L... But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it
  - tgragnato 7y ago
    > But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain > you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs to the same query, thus it'd be mypage.com and mypage.com (not www.mypage.com).. bypassing the same origin restrictions of the browsers. https://capec.mitre.org/data/definitions/275.html https://capec.mitre.org/data/definitions/275.html
    - lostjohnny 7y ago
      > In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs But it doesn't really work. I query my DNS, on my home router, not your DNS. And the DNS on my home router query the ISP's DNS, which caches requests. I bet you can't go below few minutes resolution. I had this problem when validating the Letsencrypt DNS challenge, I had to let certbot run for almost 20 minutes before my home router picked up the new value. When I'm at work, I use the company's DNS, which ignores non standard TTLs and caches the first answer forever (well... almost) and disallow external domains that resolve to reserved IP addresses.

X-Istence 7y ago

This is the reason why my local DNS resolver won't allow returning private IP space (including localhost).