Improve URL validation for external wiki and external issues

[lafriks]

Fixes #4703

[codecov-io]

Codecov Report

Merging #4710 into master will increase coverage by 0.07%.
The diff coverage is 79.59%.

@@            Coverage Diff             @@
##           master    #4710      +/-   ##
==========================================
+ Coverage   20.63%   20.71%   +0.07%     
==========================================
  Files         166      167       +1     
  Lines       32314    32355      +41     
==========================================
+ Hits         6669     6702      +33     
- Misses      24665    24672       +7     
- Partials      980      981       +1

Impacted Files	Coverage Δ
routers/repo/setting.go	6.68% <0%> (-0.08%)	⬇️
modules/validation/binding.go	100% <100%> (ø)	⬆️
modules/validation/helpers.go	92.3% <92.3%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0449330...960c1d8. Read the comment docs.

[techknowlogick]

@lafriks I have some thoughts about blocking localhost URLs. Some users might host Gitea behind a reverse proxy under a sub-path which means they might need to have localhost (or 127.0.0.1) as a valid external issues URL (assuming they host everything on same machine).

Edit: We should deal with blocking in the SSRF patch to make it customizable.

[lafriks]

@techknowlogick even if you run gitea behind reverse proxy this validates only URL's that will be presented for user not server<->server communication.

[techknowlogick]

@lafriks yes, I understand. But a user might run JIRA locally (hopefully they don't), but that might be possible, this would block them from doing that.

[lafriks]

when creating these function I had in mind to reused/extend them for SSRF fix later but this is not what this PRs is about :)

[lafriks]

You mean user is running gitea&jira on local laptop and accessing it by localhost? Chance of such need is close to zero and anyway you can use your hostname/lan ip. Besides this PR will not break existing configurations but just won't allow adding such urls in future

[techknowlogick]

@lafriks lolya. that's correct. I also believe chance is near zero, but as this wouldn't prevent a DNS re-binding attach (say for example I set local.techknowlogick.com to 127.0.0.1) this would bypass our validation and would be accepted, so I think unless we do a DNS lookup for the URL we shouldn't block it unless we block all cases.

My opinion is weakly held, I also see the merits of what you've said, so my LG-TM on this PR still applies.

Edit: Fixed my typos

[techknowlogick]

@lafriks I see the TODO now (thanks for the reminder in chat). That's acceptable for me. Please disregard what I've said above. My LG-TM is now 100%

[lunny]

LGTM

[lafriks]

Make LG-TM work

[lunny]

@lafriks please send a back port PR.