epi052
[BUG] Ferox buster doesn't recognise 301 with protocol change
Describe the bug If application makes a 301 redirection and switches protocols feroxbuster doesn't recognise the redirection.
To Reproduce Scan an application that behaves like the one below: 200 GET 459l 1201w 16218c https://example.com/ 301 GET 7l 20w 237c https://example.com/css => http://example.com/css/ 301 GET 7l 20w 236c https://example.com/js => http://example.com/js/
Just to make things clear after redirecting to http://example.com/js/ app redirects browser back to https://example.com/js/. I have encountered multiple applications with this behaviour
Expected behavior Feroxbuster either should have a flag to ignore protocol change or in case of protocol change follow redirection to make sure it doesn't point to same application.
do you have a public bug bounty target or hackthebox (or some other platform) with a target that has this behavior handy? Otherwise I need to build a server to test etc..
It's nothing I can publicly share tough I think it's not uncommon so maybe you will stumble on something yourself ;) Anyway if you want me to test some test builds to know if it works let me know.
I have encountered same issue again, this time with 2.10.0. I attach a log as I can't do much more :D
301 GET 7l 11w 169c https://notatruename.com/css => http://notatruename.com/css/
200 GET 1l 1990w 55321c https://notatruename.com/js~
200 GET 1l 1990w 55321c https://notatruename.com/js.bak
200 GET 1l 1990w 55321c https://notatruename.com/js.bak2
200 GET 1l 1990w 55321c https://notatruename.com/js.old
200 GET 1l 1990w 55321c https://notatruename.com/js.1
200 GET 1l 1990w 55321c https://notatruename.com/.js.swp
301 GET 7l 11w 169c https://notatruename.com/js => http://notatruename.com/js/
200 GET 1l 1990w 55321c https://notatruename.com/.api.swp
308 GET 4l 24w 260c https://notatruename.com/api => http://notatruename.com/api/
200 GET 1l 1990w 55321c https://notatruename.com/assets~
200 GET 1l 1990w 55321c https://notatruename.com/assets.bak
200 GET 1l 1990w 55321c https://notatruename.com/assets.bak2
200 GET 1l 1990w 55321c https://notatruename.com/assets.old
200 GET 1l 1990w 55321c https://notatruename.com/assets.1
200 GET 1l 1990w 55321c https://notatruename.com/.assets.swp
301 GET 7l 11w 169c https://notatruename.com/assets => http://notatruename.com/assets/
200 GET 1l 1990w 55321c https://notatruename.com/fonts~
200 GET 1l 1990w 55321c https://notatruename.com/fonts.bak
200 GET 1l 1990w 55321c https://notatruename.com/fonts.bak2
200 GET 1l 1990w 55321c https://notatruename.com/fonts.old
200 GET 1l 1990w 55321c https://notatruename.com/fonts.1
200 GET 1l 1990w 55321c https://notatruename.com/.fonts.swp
301 GET 7l 11w 169c https://notatruename.com/fonts => http://notatruename.com/fonts/
405 GET 4l 23w 178c https://notatruename.com/api/login
302 GET 4l 24w 224c https://notatruename.com/api/ => http://notatruename.com/api/docs
401 GET 1l 2w 78c https://notatruename.com/api/logout
200 GET 213l 497w 6565c https://notatruename.com/api/docs
401 GET 1l 2w 78c https://notatruename.com/api/statistics
200 GET 1l 12970w 705933c https://notatruename.com/api/docs.json
401 GET 1l 2w 78c https://notatruename.com/api/users
301 GET 7l 11w 169c https://notatruename.com/api/static => http://notatruename.com/api/static/
I did dig a little more and I think it's caused by Nginx misconfiguration. Here similar issue is described: https://serverfault.com/questions/885046/how-to-prevent-nginx-redirecting-from-https-to-http-on-aws
that's interesting. so
https://example/js => http://example/js/ and http://example/js/ => https://example/js/
so, we'd either want to ignore the https->http redirect altogether, or follow from https, to http, and back to https-with-slash
i know i've been slacking on responses, but do you happen to recall if using --follow-redirects performed the following pattern i listed out above?
Sorry post was using wrong account.
This wouldn't work for this particular target as it was NOT listening on HTTP 😄 This wasn't a concern for service owner as issue occurred in redirects from /dir to /dir/ which do not occur usually in case of this application 😄
However I have found another target with same properties and no http:
301 GET 7l 20w 241c https://company.com/images => http://company.com/images/
404 GET 7l 23w 196c https://company.com/images~
404 GET 7l 23w 196c https://company.com/images.bak
404 GET 7l 23w 196c https://company.com/images.bak2
404 GET 7l 23w 196c https://company.com/images.old
404 GET 7l 23w 196c https://company.com/images.1
404 GET 7l 23w 196c https://company.com/.images.swp
301 GET 7l 20w 242c https://company.com/classes => http://company.com/classes/
404 GET 7l 23w 196c https://company.com/classes~
404 GET 7l 23w 196c https://company.com/classes.bak
404 GET 7l 23w 196c https://company.com/classes.bak2
404 GET 7l 23w 196c https://company.com/classes.old
404 GET 7l 23w 196c https://company.com/classes.1