davtur19/DotGit

.git recognition with 403 Forbidden

Closed this issue · 5 comments

calebstewart commented

Currently, the extension does not identify an exposed Git repository when the .git/ returns 403 Forbidden, however the files under the .git/ directory are accessible (such as .git/config etc).

I would expect the extension to still identify the repository, since it can see .git/config.

Thanks!

davtur19 commented

I need more details, if possible could you link the site with the .git exposed?

Alternatively can you tell me if there is "ref: refs/heads/" in "/.git/HEAD"?
Currently the identification is based on checking if that string is present in this file.

If the string is present in that file you could try:

  • Check if you have the latest version (4.2.2)
  • Check if .git checking is enabled in the options
  • If you can, you could also try to use the "delete all" button (the trash can icon) and possibly a reset of the settings, and then try to revisit the site.

Note: Obviously you delete all if you do the last step
Deleting everything could fix some bugs due to some updates and could fix the detection

If the string is not present in that file:
What would you recommend to detect the .git folder instead of checking .git/HEAD?
We would need something recognizable that there is in all .git, to be put as a control in place of the current one, in order not to increase the HTTP requests made to the sites visited.

calebstewart commented

Sure, the website is up here. It's for a Capture the Flag competition we are hosting. It will only be up until Sunday night, though. If you'd like/needed, we can keep that specific page up longer, though. The repository is there, and we can dump the repo with the InternetWache git dumper here.

  • I'm currently running 4.2.2
  • The .git checking is currently enabled
  • I don't know what "delete all" button you mean. Are you referring to the extension settings? I don't see that button currently. For awareness, I just installed the extension to test this on a new computer, so it should be in a pretty "clean" state.

That string is not in .git/HEAD, however .git/HEAD does exist, as does .git/config. I'm not going to pretend to be an expert on Git internals, but is the presence of .git/config and/or .git/HEAD not an solid indicator alone that there is a git repository present?

davtur19 commented

The check has been fixed, the problem is that I only checked if "ref: refs/heads/" existed and I didn't think there could even be a hash (the check exists to avoid false positives and not to check every single file in a folder .git generating useless traffic).

The button I was referring to is the one in the popup of the extension at the top right, the trash can icon with the X.
In any case that only resets the list of sites visited and sites with exposed folders.

If you know of other cases where the .git/HEAD file may not be present or contain something else let me know that I try to fix the check and avoid false positives, as I'm not an expert in Git internals either. 😄

davtur19 commented

Note:
Now with the update the extension will not detect the site if you have already visited it, as it keeps in memory the sites already checked in order not to send a request every time you browse the site.
Just click on the trash can to clear the list of sites and after that it should detect it once you visit it.

calebstewart commented

Awesome! Thanks for the quick turnaround! I appreciate it!