4 ms·

Nope, you can't Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost/. (Reason: CORS header ‘Acce

Nope, you can't Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing) Anyway TypeError: /(192\.168\.[0-9]+\.)[0-9]+/.exec(...) is null i-can-see-your-local-web-servers:169:41

chronial 7y ago
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
- X-Istence 7y ago
  This is the reason why my local DNS resolver won't allow returning private IP space (including localhost).
deleted 7y ago
[deleted]
tlrobinson 7y ago
The post specifically mentions CORS and shows an example Express app that has CORS enabled.
- lostjohnny 7y ago
  CORS is not enabled by default anywhere, I have few servers running right now on my laptop and the page can't see any of them, because all of them have CORS disabled First thing you do when you enable CORS is to configure it to only respond to specific domains, so when you deploy to production you don't leave it open by accident. BTW if you enable CORS as in 'simple usage' in the docs, chances are the home page is a blank page and there will be nothing to be stolen
  - rewq4321 7y ago
    Recently I was testing a client-side algorithm that pulled a lot of data from the server and I thought my http server might have been the bottleneck, and so I spun up a few copies of the server but had to enable cors to get the client talking to them all. Newbs like me don't realise that localhost+cors = exposed to the www, so this article was very surprising and useful. This app is only used internally and so your deployment justification doesn't make sense for this case, but I will definitely make sure only specific domains are exempted in the future, thanks to this article.

chronial 7y ago

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
X-Istence 7y ago
This is the reason why my local DNS resolver won't allow returning private IP space (including localhost).

deleted 7y ago

[deleted]

tlrobinson 7y ago

The post specifically mentions CORS and shows an example Express app that has CORS enabled.

lostjohnny 7y ago
CORS is not enabled by default anywhere, I have few servers running right now on my laptop and the page can't see any of them, because all of them have CORS disabled First thing you do when you enable CORS is to configure it to only respond to specific domains, so when you deploy to production you don't leave it open by accident. BTW if you enable CORS as in 'simple usage' in the docs, chances are the home page is a blank page and there will be nothing to be stolen
- rewq4321 7y ago
  Recently I was testing a client-side algorithm that pulled a lot of data from the server and I thought my http server might have been the bottleneck, and so I spun up a few copies of the server but had to enable cors to get the client talking to them all. Newbs like me don't realise that localhost+cors = exposed to the www, so this article was very surprising and useful. This app is only used internally and so your deployment justification doesn't make sense for this case, but I will definitely make sure only specific domains are exempted in the future, thanks to this article.