3 ms·

Amusingly half of those things have been modernized to run on HTTP, so browsers can already do them.

rocqua 4y ago
Except the very complicated 'same origin policy' makes it generally forbidden by browsers to do HTTP against local adresses.
- fulafel 4y ago
  It's not generally something browsers can do as there's no distinction about local addresses in IP (except localhost and IPv6 link-local addresses...) Also see DNS rebinding attacks: https://unit42.paloaltonetworks.com/dns-rebinding/ https://unit42.paloaltonetworks.com/dns-rebinding/
  - capableweb 4y ago
    CORS doesn't generally care if the final IP was resolved from localhost or example.com (or any other DNS entry), if the host doesn't have the right response to OPTIONS requests, you won't be able to communicate with it in the browser, unless your on the same IP/DNS as you're trying to talk to.
    - fulafel 4y ago
      There are CORS bypass techniques, CSRF exploitation via methods which are not checked by CORS such as img tags, and common exploitable misconfigurations (and maybe you can race the preflight check with dns rebinding attack?) - but the question of local address handling playing a part was the main point of my response. Here's some typical cases of csrf based vulnerabilities: https://seclists.org/fulldisclosure/2015/Mar/49 https://seclists.org/fulldisclosure/2015/Mar/49 https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-admin-password/ https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-... https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-016.txt https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-01... Remember, the S in IoT stands for security!
    - Thorrez 4y ago
      >OPTIONS requests OPTIONS requests only happen for cross-origin requests. With DNS rebinding, there are no cross-origin requests, so there will be no OPTIONS requests.
      - capableweb 4y ago
        But that requires you to load the page resource from that origin already, so if you're already in control of it, what would you want to do that you couldn't already?
        Thorrez 4y ago
        Here's how DNS rebinding works: 1. You have the victim user open a tab to your page at attacker.com . 2. After the page loads, you change the DNS record for attacker.com to make it point to 127.0.0.1 . 3. Javascript on the page makes requests to attacker.com and can now read and interact with whatever servers are running on the victim user's machine. Alternatively use 192.168.1.1 to attack the victim user's router. This attack will be blocked if the victim servers check the Host request header. Often they don't.
- IshKebab 4y ago
  Sites don't have to prevent browsers accessing other addresses. It's only protection against XSS, not against malicious sites.
Hamcha 4y ago
I mean it's nowhere as bad, and for legacy stuff usually CORS/SOP helps. New implementations that use websocket as their root (mostly for web browser compatibility) seem to take security more seriously out of the box, I use a couple apps in my day-to-day which expose APIs over Websocket and don't trust by default. - Vtube Studio has a auth dialog that pops up on first connection you must accept before commands are executed - obs-websocket by default requires a password to be used. There's always outliers sadly, for example "beefweb" (Foobar plugin) has auth but it's not enabled by default.

Except the very complicated 'same origin policy' makes it generally forbidden by browsers to do HTTP against local adresses.

fulafel 4y ago
It's not generally something browsers can do as there's no distinction about local addresses in IP (except localhost and IPv6 link-local addresses...) Also see DNS rebinding attacks: https://unit42.paloaltonetworks.com/dns-rebinding/ https://unit42.paloaltonetworks.com/dns-rebinding/
- capableweb 4y ago
  CORS doesn't generally care if the final IP was resolved from localhost or example.com (or any other DNS entry), if the host doesn't have the right response to OPTIONS requests, you won't be able to communicate with it in the browser, unless your on the same IP/DNS as you're trying to talk to.
  - fulafel 4y ago
    There are CORS bypass techniques, CSRF exploitation via methods which are not checked by CORS such as img tags, and common exploitable misconfigurations (and maybe you can race the preflight check with dns rebinding attack?) - but the question of local address handling playing a part was the main point of my response. Here's some typical cases of csrf based vulnerabilities: https://seclists.org/fulldisclosure/2015/Mar/49 https://seclists.org/fulldisclosure/2015/Mar/49 https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-admin-password/ https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-... https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-016.txt https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-01... Remember, the S in IoT stands for security!
  - Thorrez 4y ago
    >OPTIONS requests OPTIONS requests only happen for cross-origin requests. With DNS rebinding, there are no cross-origin requests, so there will be no OPTIONS requests.
    - capableweb 4y ago
      But that requires you to load the page resource from that origin already, so if you're already in control of it, what would you want to do that you couldn't already?
      - Thorrez 4y ago
        Here's how DNS rebinding works: 1. You have the victim user open a tab to your page at attacker.com . 2. After the page loads, you change the DNS record for attacker.com to make it point to 127.0.0.1 . 3. Javascript on the page makes requests to attacker.com and can now read and interact with whatever servers are running on the victim user's machine. Alternatively use 192.168.1.1 to attack the victim user's router. This attack will be blocked if the victim servers check the Host request header. Often they don't.
IshKebab 4y ago
Sites don't have to prevent browsers accessing other addresses. It's only protection against XSS, not against malicious sites.

Hamcha 4y ago

I mean it's nowhere as bad, and for legacy stuff usually CORS/SOP helps. New implementations that use websocket as their root (mostly for web browser compatibility) seem to take security more seriously out of the box, I use a couple apps in my day-to-day which expose APIs over Websocket and don't trust by default. - Vtube Studio has a auth dialog that pops up on first connection you must accept before commands are executed - obs-websocket by default requires a password to be used. There's always outliers sadly, for example "beefweb" (Foobar plugin) has auth but it's not enabled by default.