projectdiscovery / nuclei

Fast and customizable vulnerability scanner based on simple YAML based DSL.
https://docs.projectdiscovery.io/tools/nuclei
MIT License
20.3k stars 2.48k forks source link

output will be the [ redirected to ] URL and not the host/URL that got scanned which causes the redirection #2485

Closed osamahamad closed 2 years ago

osamahamad commented 2 years ago

Nuclei version:

2.7.5

Current Behavior:

in the latest version of nuclei I observed that when a hit is generated with in a template that follows redirect then the output will be the [ redirected to ] URL and not the host/URL that got scanned which causes the redirection. This was not the case in older nuclei version

Expected Behavior:

I found it so annoying and I wished there is an argument in nuclei to display at least both the subdomain and the redirected domain that is vulnerable or just an argument that display the subdomain only and not the ( redirected to ) as vulnerable similar to the old versions.

Steps To Reproduce:

For example: use the following target bullsheet.me make usual subfinder command and find its subdomain and scan them with nuclei full templates. A lot of results will be similar to image image image image image

See , that the researcher can not actually know which subdomain that results in a redirect to those vulnerable domains for example one of them is buscocampo.com ( I can not know which subdomain of bullsheet.me actually have a redirect to buscocampo.com which is vulnerable to mysql native password info issue )

Anything else:

image

jimen0 commented 2 years ago

Hey @osamahamad if you could please share a reproducible example (template, cli command and target url) I'd be happy to push a fix for this so it works again as expected.

osamahamad commented 2 years ago

hey, @jimen0 @ehsandeep

Observe the results and tell me if you can understand anything for a huge amount of templates hits. I think that should be prioritized more, there are a lot of hosts on the web that will redirect you to a domain that does not belong to the original domain at all ( 3rd party, promotion ..etc ) and this version will generate hits to the ( redirected to ) domain and display to the user only the last redirection.

This means if a template that follows redirect spots a vuln in x.com and x.com actually redirects to y.com , nuclei will display y.com hit only, researcher will get confused between the results because it is hard to determine in-scope and out-of-scope domains in this way.

jimen0 commented 2 years ago

Please, share a minimal, reproducible example. I won't be scanning a third party without any authorization in such an aggressive way to debug this. @osamahamad

osamahamad commented 2 years ago

@jimen0 Use any template name which is ( info ) fingerprint templates provided in the example above on the same list. mx-service-detector , ssl-dns-names ..etc , otherwise, I can't help u with anything else.

jimen0 commented 2 years ago

Quick reproducer:

id: jimeno-test 

info:
  name: Test for nuclei
  author: jimeno
  severity: info

requests:
  - method: GET
    path:
      - "{{BaseURL}}/hello"
    redirects: true
    max-redirects: 10
    matchers:
      - type: word
        words:
          - 'illustrative examples in documents'

Run the following listener:

package main

import (
    "fmt"
    "log"
    "net/http"
    "net/http/httputil"
)

func main() {
    http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
        b, _ := httputil.DumpRequest(r, true)
        fmt.Printf("[+] Received request:\n%s\n", b)

        http.Redirect(w, r, "https://example.com/", http.StatusFound)
    })

    if err := http.ListenAndServe("127.0.0.1:3000", nil); err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
}
$ go run ./cmd/nuclei -t /tmp/example.yaml -u http://127.0.0.1:3000/ -silent
[2022-09-06 09:13:19] [jimeno-test] [http] [info] https://example.com/

@osamahamad if I got this correctly your point is that nuclei's output should say http://127.0.0.1:3000/ instead of https://example.com/. Is that right?

osamahamad commented 2 years ago

Hi @jimen0 Exactly, this behavior was updated in 2.7.2 as part of https://github.com/projectdiscovery/nuclei/issues/2008 to display host where you actually get the hit and not the input host. I think a solution for this is either by adding an argument to return back the old behavior or an argument that displays both hosts, the input host, and the redirection host.

jimen0 commented 2 years ago

hey pd team @Ice3man543 @forgedhallpass what is the intended behavior? Thanks!

forgedhallpass commented 2 years ago

Based on what we've discussed, probably we'll want to revert certain parts of the previous modifications. We'd want something like:

  1. [ ] TODO 1:

    • if the redirect happens to another domain, show the original domain in the output, to prevent confusion
    • input: example.com, redirect to anotherdomain.com, then show example.com
    • if the redirect is within the same domain, then show the redirected path
    • if input http://example.com, redirect to https://example.com, then show https://example.com
    • if input http://example.com, redirect to http://example.com/login, then show http://example.com/login
  2. [ ] TODO 2:

    • Furthermore we'll want to extend the JSON output to include both the original and redirected locations.
  3. [ ] TODO 3:

    • Test cases to cover the above mentioned scenarios

@ehsandeep will have to confirm the requirements first.

ehsandeep commented 2 years ago

This issue will be indirectly fixed after implementation of https://github.com/projectdiscovery/nuclei/issues/2612 and updating existing templates, where redirects: true is used with host-redirects: true with some exception where global redirects might be intended.