3 ms·

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.