Does this not work on mobile? I’m not seeing any of my web services show up on my server when opening this page in iOS Safari.
EDIT: In fact the status of local network scan doesn’t come up at all.
I can see your local web servers
111–120 of 198 posts
Re: I can see your local web servers
#112Other approach is to create a useful extension like: https://addons.mozilla.org/en-US/firefox/addon/yt-adblock/reviews/ disguise that you're inserting an iframe linking to your web server into every single page user opens, by naming variables and your tracking domain incorrectly and by waiting for an hour after installation (this may also help avoid automatic tests mozilla is doing) and then just sit back and wait an…
what is meant by, "users are banned from fixing the extension code locally"? i download and modify other people's extensions all the time.
Probably the signing requirement for release builds of Firefox.
Re: I can see your local web servers
#113His demo did not work so his message does not really get across. Maybe there ware ways to exploit it but if so he failed. I got a CORS rejection.
The demo may not have worked for you, but it does work and works for many other people. Just because your particular browser is secured does not mean the author failed.
Re: I can see your local web servers
#114Earlier quoted context omitted.
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
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 t…
> 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#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
Re: I can see your local web servers
#115Earlier quoted context omitted.
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
I don't quite understand your comment. Do you mean "shouldn't" whenever you wrote "should"?
yeah, I meant need, sorry
Re: I can see your local web servers
#116I only ever run my local dev server on port 80, and use a hosts file to assign custom (fake) domain names to each of the sites I want to run. I mentioned as much here a few years ago when I first came across this idea of assigning (and remembering) random unique port numbers to every one of your apps in development, and was surprised to hear that it's such a common practice. It seems sub-optimal for a lot of reasons,…
Unless I'm missing something, this only works if you are running one site at a time, or you have a single web server bound to port 80 that supports virtual hosts. You also need application and/or configuration support to get this working properly. And even then, if you run any software with an embedded web server you are usually out of luck unless you want to fiddle with a reverse proxy configuration. For these reaso…
IIS handles all this out of the box for me. I just bind the host name to the site in question. It sounds like maybe this isn’t something that other web servers do, which is surprising. The whole point of the operation is to seamlessly run 30 odd websites on one dev machine without needing to fiddle with port numbers or anything else.
Re: I can see your local web servers
#117Earlier quoted context omitted.
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 t…
> 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…
> 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.
Re: I can see your local web servers
#118Nope, 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
The post specifically mentions CORS and shows an example Express app that has CORS enabled.
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
Re: I can see your local web servers
#119I wrote some code a while back to find and detect other devices on your network, although it no longer seems to work on safari: http://joevennix.com/lan-js/examples/dashboard.html
The fingerprinting db it used can be found in the repo: https://github.com/joevennix/lan-js/blob/master/src/db.js
Re: I can see your local web servers
#120Earlier quoted context omitted.
> My question is: What is the risk of running one of these servers and then visiting some random web page? It depends on what you're exposing on those ports. If it's something sensitive, stop. Any web page can run javascript and as such, any web page has access to every port and service that your machine has access to ... because at that point, the web page is a program running on your machine with full network acces…
If it's got CORS enabled you can do a hell of a lot more than ping your server.
Wait, what? I think you means the opposite. If it's got CORS enabled, then you can't do anything unless the request is originating from the relevant domain.
Anyway, do not rely on firewalls (and CORS is a firewall) as the sole security measure. Do not create unauthenticated endpoints unless you want everybody to use them.