mitmweb isn't protected against DNS rebinding

[atx]

The mitmweb interface does not seem to include protection against DNS rebinding. This could be exploited by a malicious website to either access the sniffed data or run arbitrary Python scripts on the filesystem by setting the scripts config option.

I have hacked together a PoC here (nothing really special to be seen though).

[mhils]

Thanks for raising this. Any recommendations on how we can fix this best?

[atx]

I like the Jupyter implementation - effectively password protect the web interface, but pass an access token to your webbrowser.open call not to annoy the user too much. As a simpler alternative, you can implement Host header based whitelist (allowing localhost or IP address access by default).

[atx]

CVE-2018-14505 has been assigned to this issue

[mhils]

Thanks again - we've just released mitmproxy 4.0.4, which includes the fix from #3243. :)

[chrisooo3]

@mhils Is it possible to turn it off and allow DNS rebinding?

[stellarpower]

Would also like to know if this can be disabled - my instance is behind a reverse proxy so I am presuming this is safe enough for what I need it for, and accessing it externally would be helpful.

[ananthb]

Yes would love for this to be configurable.

[DenisBalan]

As @Kriechi merged #3243 into the master.
Also mentioning @mhils @atx

Whats the problem having by default DnsBinding protection enabled,
but have this option configurable?

In our case, for internal usage purposes, we need to fork this repo and revert mentioned PR in order to fulfill our needs.

IMHO, thats not the best way to do that.
Just make secure by default, and configurable for those who knows what they are doing

[chrisbecke]

What the actual ...... ..... A day spent trying to figure out why a docker swarm Traefik router for mitmweb.example.com always returned 404.

[hoogi91]

@chrisbecke regarding traefik you need to disable passHostHeader see below example using compose - hope it helps you too :)

mitmproxy:
    image: mitmproxy/mitmproxy
    tty: true
    command: "mitmweb --web-host *"
    labels:
      - "traefik.http.services.mitmproxy.loadbalancer.server.port=8081"
      - "traefik.http.services.mitmproxy.loadbalancer.passHostHeader=false"

[chrisbecke]

@hoogi91, thanks for the tip.
Ive tried using a customrequestheader middleware to set host to 1.1.1.1 - but the web socket fails and leaves the GUI in a "connecting" state and it never updates.
Setting "passHostHeader" to false causes it to show "connection lost" immediately, so I don't know if this is better or worse :/

[hoogi91]

@chrisbecke ah sry, forgot to mention them too, you also need to add a middleware that drops some request headers to make the websocket work:

      - "traefik.http.routers.mitmproxy-https.middlewares=mitmproxy-header@docker"
      - "traefik.http.middlewares.mitmproxy-header.headers.isDevelopment=true"
      - "traefik.http.middlewares.mitmproxy-header.headers.customrequestheaders.Host="
      - "traefik.http.middlewares.mitmproxy-header.headers.customrequestheaders.Origin="

[SciLor]

Workaround for nginx-proxy-manager for the webinterface.

location / {
proxy_set_header Host localhost:$port;
proxy_set_header Origin http://localhost:$port;
proxy_pass $forward_scheme://$server:$port;

expires off;
proxy_http_version 1.1;
proxy_redirect $forward_scheme://$http_host:$port $forward_scheme://$http_host;
proxy_buffering off;

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Cookie $http_cookie;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

[wu0407]

It is work for kubernetes traefik ingressRoute:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  annotations:
    kubernetes.io/ingress.class: traefik2
  name: mitmproxy
  namespace: xxxx
spec:
  entryPoints:
  - web
  routes:
  - kind: Rule
    match: Host(`web.xxxx.com`)
    services:
    - kind: Service
      name: mitmproxy
      namespace: weimob-ops
      port: 8081
    middlewares:
    - name: mitmproxy-web-header
      namespace: xxx
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: mitmproxy-web-header
  namespace: xxx
spec:
  headers:
    customRequestHeaders:
      # hack to remove origin request Host header
      # may be relate https://github.com/traefik/traefik/pull/6502
      Host: " " # this is a space 
      Origin: ""
    isDevelopment: true

[davet2001]

Here's what I eventually got working on haproxy for a mitmproxy home assistant addon (Docker container).

frontend main
    bind *:8081

    http-response del-header    x-frame-options
    default_backend             mitmweb

backend mitmweb
    balance     roundrobin
    http-request set-header Host 127.0.0.1:9090
    http-request set-header Origin http://127.0.0.1:9090
    server  mitm    127.0.0.1:9090 check

In my case, haproxy is listening on 8081, then proxying this to a mitmproxy instance running its web server on 9090. Both of these are inside a docker container.

The http:// on the origin header line turned out to be important. I'm not fully sure why, but without this, the websocket connection was not allowed through haproxy to mitmproxy.

[jasonholloway]

A further potentially helpful snippet for users of Kubernetes' Nginx controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-vhost: "127.0.0.1:8081"

[ryansorensen]

For anyone using Caddy as their reverse proxy:

https://mitmproxy.example.com {
	reverse_proxy * localhost:8081 {
		header_up Host 127.0.0.1:8081
		header_up Origin http://127.0.0.1:8081
	}
}

example docker-compose.yml

services:
  mitmproxy:
    image: mitmproxy/mitmproxy
    command: mitmweb --web-host 0.0.0.0
    ports:
      - 8080:8080
      - 8081:8081
    volumes:
      - /mitmproxy-data:/home/mitmproxy/.mitmproxy