File Screenshot Errors about gowitness HOT 5 OPEN

Potentially a bug?

Errors 1 & 3

As mentioned in the OP, running gowitness file will give me the errors:

1. ERR failed to witness url error="context deadline exceeded" url=http://api.DOMAIN.com
2. ERR failed to witness url error="could not retrieve attribute \"outerHTML\": No node with given id found (-32000)" url=https://app.DOMAIN.com

If I run the following one liner, GoWitness will complete successfully without an issue.

cat "../subd.txt" | while read line; do gowitness single -X 2560 -Y 1440 -F "http://$line"; done

Given this, I believe there is some sort of bug. Of course I can just use this in general, but that defeats the purpose of the File flag in GoWitness as well as the fact I cannot thread it. I would have to hack some code together so it would run in series in the background (; done &)

If there is anything else I can provide to hopefully get this resolved, I am more than happy to do so.

Error 2

I only get this on one subdomain out of the list of 13. When going to the same URL in my browser, I am given the following error:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

This tells me that the second error is server-side, and therefore not legitimate to this issue any more.

from gowitness.

Thanks, the extra information is useful. As a hypothesis on what's going on, single and file eventually enter the same code path for the screenshotting part, but with file we try a few things regarding the URL protocol to use by adding http and https if there is no protocol. With single we just parse whatever we got and use that. For this reason I think some of your targets may not be alive on ports 80 or 443, hence the errors you are seeing.

I have two things in mind to test (without knowing your targets):

• Can you check your input file and specify http in the file like you do for the while loop and test?
• Can you change the goroutines used in file to 1 with -t 1 on the file subcommand?

from gowitness.

Thanks for the reply. It seems that those two suggestions together work. I did attempt -t 1 before making this issue but it didn't change anything from the default run with errors. Something I should maybe note; now that I think about it, it's the same subdomains causing the issue. Is it generally recommended to have the URIs in the list? If so I would just be able to make it fall back from https to http if an error occurred with the https fetch.

Based on your hypothesis I thought I would change the order and see if that could be the case using the original command and they still spat out errors. Is there anything I can look for with the issue subdomains when loading it in my browser or maybe curl to see why? If preferable, I can provide you with the target if it makes it less tedious to figure it out. Thank you!

from gowitness.

Think the bigger thing here is that an error is not necessarily a bad thing. It's really just telling you it couldn't screenshot (or preflight) the remote end and will move on to the next target. Specifying the full URL is preferred to prevent gowitness from trying to find something that might not exist to begin with.

On the fallback idea, this is something I have planned for the v3 release.

from gowitness.

Understood. Because I had the time, I was able to set everything up on my PC and it seems gowitness file on the same list works perfectly fine.

Considering that fact and that Prefetch was receiving a 200 response code, could this potentially mean my Chromium is having issues? I uninstalled it and reinstalled it on Snap, but I still received the errors with gowitness file. Is there any suggestions on how I can go about troubleshooting this issue?

from gowitness.