1775440 - Bypassing same-origin policy

Status: RESOLVED DUPLICATE of bug 1475605

(Core :: Networking: DNS, defect)

Description

[Clara]

Attachment: dnssever.py

Browsers respect some origin font for the request.
This policy prohibits PageA access to PageB's content if the protocols, ports or hostnames are different.
Each host can have one or more IP addresses, as well as it is common for the IP address to change from time to time.

The idea of the bypassing is:

1. Using authoritative name server we point our hostnameA to our webserver. We can also use a reverse proxy server as in the example
2. waiting user open our page http://hostnameA/page1.html from our webserver,
3. in an iframe the page1.html load other page of the same hostname http://hostnameA/page2.html,
4. we change the ip address of the hostnameA to an local IP par example 192.168.0.1 or even 127.0.0.1,
5. the javascript of the page1 try to open http://hostname/page2.html every 5 seconds, until the ip address will not be renewed,
6. for the Browser it is the same hostname, the schema and the port therefore "the same site".
7. Now we can access our target.

The problem with this idea is the browser cache and DNS cache. For that:

1. Our server should send no-cache no-store pragma and should close connection.
2. We open several pages for caught good ip and for find the solution as soon as possible.

Example of an valid headers:

HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 21 Jun 2022 09:02:35 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Cache-Control: no-cache, no-store

The exploite files
dnssever.py - simple DNS reverse proxy with randomly changing IP for attacker hostname (need twisted library installed), can be used authoritative name server
page1.html - Open several subpages, used to be able to catch a good IP address and bypass caches
page2.html - Trying to open as subframe target with the same domain name, checking if this is a good page
localhost/index.php - for localhost penetration testing
For test we need to run:
DNS server: python3 dnssever.py
HTTPServer with php supporting with html files in root directory

Tested and passed on:
102.0.5005.61 (Official Build) Arch Linux (64-bit)
102.0.5005.115 (Official Build) Arch Linux (64-bit)
102.0.5005.115 (Official Build) MacOS
102.0.5005.87
100.0.2 (64-bit) Firefox (mais prend environ 10 minute pour renouvelle le cache)
101.0.1 (64-bit) Firefox Arch Linux
101.0.1 (64-bit) Firefox MacOS
13.1.2(13609.3.5.1.5) Safari MacOs

The solutions

1. It is possible to add marker of the local network for "same origin policy" (requires changing the standard)
2. Create IP groups (ex. 192.168.0.0/24, 127::1, 10.0.0.0/8, others) and check each request if IP address has changed its group origin during the time of existence of the open page

Love & Peace
Clara <[e-mail]>

Comment 1

[Clara]

Attachment: index.php

Comment 2

[Clara]

Attachment: page1.html

Comment 3

[Clara]

Attachment: page2.html

Comment 4

[Clara]

Attachment: firefox.png

screenshort

Comment 5

[:Gijs (he/him)]

This is a straightforward DNS rebinding attack, right? This is a well-documented issue, even on wikipedia, cf. https://en.wikipedia.org/wiki/DNS_rebinding .

We have previously wontfixed the generic DNS rebinding attack in bug 1106687 - the suggestion there was that the solution is for servers to verify host headers from the request, and for servers to use https and certificates, which would make the attack impractical.

bug 1475605 has a more recent suggestion on what browsers could do to remedy against this kind of attack. Tom, should we just dupe this there? Am I missing something?

Comment 6

[Clara]

It's almost the same except it's the same hostname request and there's no '.' like in the bug 1106687 .

Here we see that
http://hostname.aaa/page2.html opens http://hostname.aaa/ (which is indeed localhost page) with permission to read this page content and execute javascript. In addition there is the exploit that works.

I saw the latest resolution, which tells us to use HTTPS.
it is true that it can protect against this type of attack, but even today there are many unprotected devices on local networks, for example developer servers and routers

Comment 7

[Tom Ritter [:tjr]]

Yes, I believe we can dupe it.

Comment 8

[Daniel Veditz [:dveditz]]

even today there are many unprotected devices on local networks, for example developer servers and routers

There are currently spec discussions about how to address the many problems with local devices.