Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The HUD fails to connect to ws endpoints from a domain upgraded to https #525

Closed
halfluke opened this issue Jun 18, 2019 · 16 comments · Fixed by #540
Closed

The HUD fails to connect to ws endpoints from a domain upgraded to https #525

halfluke opened this issue Jun 18, 2019 · 16 comments · Fixed by #540
Assignees
Milestone

Comments

@halfluke
Copy link

Any website, even one that should be available in plain http, is automatically redirected to https when the Extensionhud extension is enabled.
This did not happen in version 2.7.0 and it causes problem with websockets which work on http

Steps to reproduce the behavior:

  1. Open firefox.
  2. Configure it to use zap proxy
  3. Go to any website available in http (I won't mention a specific one here)
  4. The browser is redirected to https (although the request in zap is logged as an http request)

Expected behavior
The website should be reachable in http (in my test, the https website is different and someway broken, the original website is intended to be reachable on http and not redirected to https)

Software versions

  • ZAP: 2.8.0
  • Add-on: Just ExtensionHUD extension... found via trial and error
  • OS: latest kali
  • Browser: Firefox Quantum 60.7.0esr 64 bit
@psiinon
Copy link
Member

psiinon commented Jun 18, 2019

@halfluke simple solution - disable the HUD :)
The HUD has to upgrade http -> https or it cant work.
However it sounds like theres a bug in the ZAP is not handling the websockets correctly.
Can you explain how websockets is used in your application? Exactly how is it failing?
Transferring to zap-hud...

@psiinon psiinon transferred this issue from zaproxy/zaproxy Jun 18, 2019
@halfluke
Copy link
Author

ah thanks.

Actually I was playing with damn vulnerable websockets, docker version

you start it with docker run -d -p 80:80 -p 8080:8080 tssoffsec/dvws
you have to put dvws.local in the host file (otherwise websockets do not work)
When finally I had everything working, kali updated ZAP to 2.8.0 and it stopped working again.
(I configured ZAP with port 8081 as a proxy listener)

What happens is that when dvws.local is redirected to https://dvws.local, all requests that use websockets simply do not go through. Not sure if it's relevant, if it's a zap issue or a dvws issue.

@psiinon
Copy link
Member

psiinon commented Jun 19, 2019

@halfluke thanks - having an example failure case makes this much easier to look into :)

@dscrobonia
Copy link
Contributor

Thanks for the clean report @halfluke ! Hopefully we can debug that one. We're also tracking the need to add documentation about this proces in #439 !

@JavanXD
Copy link

JavanXD commented Jul 2, 2019

grafik

I have the same problem running the owasp juice shop as docker container. Juice Shop is not accessible over https but zap is redirecting the page to https (`Location: https...`). This is why you can see a blank page on the left.

@psiinon
Copy link
Member

psiinon commented Jul 2, 2019

@JavanXD Thats strange, I've used the HUD against Juice Shop running in Docker many times without any problems.
The fact that JS is not accessible via https is a red herring - ZAP handles the http->https upgrade internally where necessary.
Are there any errors logged in the browser console?

@JavanXD
Copy link

JavanXD commented Jul 2, 2019

After trying a few things, I was able to spot the problem.
The JavaScript Files and the Stylesheets haven't been loaded correctly over HTTPS. Because I disabled to proxy them in:
image
Since the scripts cannot be loaded, the page is blank.

Example main.js:
image
@psiinon I do not know how best to solve it. Because ZAP does influence these requests by loading the page via HTTPS, but can then no longer take care of an HTTPS => HTTP downgrade (since the file types were excluded).

@psiinon
Copy link
Member

psiinon commented Jul 2, 2019

@JavanXD #531will hopefully fix that problem, as long as you dont disable proxying for them :) Are you able to try that out?

@psiinon
Copy link
Member

psiinon commented Jul 3, 2019

Re the original problem with dvwa this is still a problem - it fails with a security error trying to access ws://dvws.local:8080/
We'll probably need to rewrite the ws:// -> wss:// and handle the ws -> wss upgrade as well...

@psiinon psiinon self-assigned this Jul 3, 2019
@psiinon psiinon changed the title Automatic http to https redirection in browsers for ANY website when ExtensionHUD extension is enabled The HUD fails to connect to ws endpoints from a domain upgraded to https Jul 3, 2019
@psiinon psiinon added this to the 0.5.0 milestone Jul 3, 2019
@psiinon
Copy link
Member

psiinon commented Jul 3, 2019

Changed the title to make it more specific and we'll aim to fix this in the next version

@JavanXD
Copy link

JavanXD commented Jul 3, 2019

I never had a problem with ws and as long i don't disable proxying it works well. In my case it was just wrong configuration.

@psiinon
Copy link
Member

psiinon commented Jul 3, 2019

In the case of dvws it is a bug, but I have a (not too nasty) fix for it.
I'll add a pref for it as well in case it break other cases.

@halfluke
Copy link
Author

halfluke commented Jul 3, 2019

hi, so have you figured out if it's a problem with zap (hud) or with the dvws app? I'm following the discussion but I'm not sure I understand. You mentioned that the upgrade from http to https is handled internally by zap, but if a website cannot handle https, it won't be displayed. Do we still have to disable the HUD as you said in your first reply? Sorry about my confusion

@thc202
Copy link
Member

thc202 commented Jul 4, 2019

It's a problem with the HUD. Disabling the HUD was just a workaround, once this is fixed dvws will work properly with the HUD enabled.

@halfluke
Copy link
Author

halfluke commented Jul 4, 2019

ah ok thanks. So are they actually 2 related but different issues? One is the http to https upgrade and one is the ws to wss upgrade?

@thc202
Copy link
Member

thc202 commented Jul 4, 2019

There's only one (afaik), the ws to wss upgrade (http to https should be working fine).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

5 participants