Python: Should an empty `netloc` count as a `py/url-redirection` sanitizer when `///evil.com` passes the check?
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- python
- Área
- security, testing-qa
Línea de trabajo
Read python/ql/lib/semmle/python/frameworks/Stdlib/Urllib.qll around NetlocCheck, then inspect python/ql/src/Security/CWE-601/UrlRedirect.qhelp, redirect_good2.py, and the ok8 case in python/ql/test/query-tests/Security/CWE-601-UrlRedirect/test.py. Reproduce the three-slash case and run the URL redirect query tests; done means the sanitizer, help example, and test annotations consistently account for the demonstrated bypass.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description of the issue
py/url-redirection treats a check that urlparse(target).netloc is empty as a sanitizer, and the query help recommends this check, together with an empty scheme, as a way to validate redirect targets. I'm wondering whether the check is meant to be complete, because for ///evil.com or ////evil.com, urlparse returns an empty scheme and an empty netloc, so the check passes, while browsers resolve the redirect to https://evil.com/.
Affected sanitizer
NetlocCheck treats a read of urlparse(...).netloc used as a condition, or compared with anything, as a barrier guard for the NoBackslashes state. The query help recommends it in redirect_good2.py, and ok8 in the query test annotates it # OK.
Steps to reproduce
The help example, unchanged:
from flask import Flask, request, redirect
from urllib.parse import urlparse
app = Flask(__name__)
@app.route('/')
def hello():
target = request.args.get('target', '')
target = target.replace('\\', '')
if not urlparse(target).netloc and not urlparse(target).scheme:
# relative path, safe to redirect
return redirect(target, code=302)
# ignore the target and redirect to the home page
return redirect('/', code=302)
The check from ok8, plus an unchecked redirect for comparison:
# Same check as `ok8` in python/ql/test/query-tests/Security/CWE-601-UrlRedirect/test.py
from flask import Flask, request, redirect
from urllib.parse import urlparse
app = Flask(__name__)
@app.route('/ok8')
def ok8():
untrusted = request.args.get('target', '')
untrusted = untrusted.replace("\\", "/")
if not urlparse(untrusted).netloc:
return redirect(untrusted, code=302) # OK
return redirect("/", code=302)
@app.route('/bad')
def bad():
return redirect(request.args.get('target', ''), code=302) # control: reported
py/url-redirection (and python-security-extended.qls) reports only /bad. With Flask's test client, the help example produces these Location headers, and ok8 produces the same ones:
target |
Location |
|---|---|
/home |
/home |
https://evil.com |
/ |
//evil.com |
/ |
///evil.com |
///evil.com |
////evil.com |
////evil.com |
new URL("///evil.com", "https://example.com/login") and new URL("////evil.com", "https://example.com/login") both give https://evil.com/ (WHATWG URL parser, as used by browsers).
This looks related to #16041: #16646 added the scheme check to the help example for https:/example.com, but URLs without a scheme that start with three or more slashes still pass. Django's url_has_allowed_host_and_scheme, which the help recommends for Django, rejects them explicitly (django/utils/http.py: "Chrome considers any URL with more than two slashes to be absolute, but urlsplit is not so flexible. Treat any url with three slashes as unsafe.").
The check also occurs in real code: KindleEar#734 used the same netloc/scheme check as the help example (url_for(...) if parts.netloc or parts.scheme else nextUrl), and ////evil.com bypassed it. DeepBI#169 describes the same bypass of a urlsplit scheme/netloc check.
Question
Is NetlocCheck intended to treat scheme-less URLs that start with three or more slashes as safe? Would it be reasonable to keep the taint unless such URLs are also rejected, as Django does, and to update the help example and the ok8 annotation accordingly?
Environment
- CodeQL CLI 2.27.2 (
codeql/python-queries1.8.12) - CodeQL repository commit for the links above:
781e068896eb7a1a104f1378e8f3f68a1074a015(the files are unchanged since 2.27.2) - Python 3.10.12, Flask 3.0.0, Werkzeug 3.0.1; Node.js v24.18.0 for the URL resolution; Linux/amd64
- Lenguaje dominante
- CodeQL
- Estrellas
- 10.3k
- Forks
- 2.1k
- Merge medio
- 2 d 10 h
- PR fusionados (30 d)
- 137
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/codeql
-
JavaScript externs model StorageEvent() with no type argumentPosiblemente ocupada @asgerf la tomó hace 9 días. Abiertofalse-positive javascript
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
github/codeql#22632 · 3 comentarios · 1 reacción · 2 asignados ·
Los mantenedores suelen responder en 1 día
-
Add AlertSuppression.ql for Rust (inline // codeql[...] suppression)Posiblemente ocupada @cnuss la tomó hace 210 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
github/codeql#21637 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
false-positive
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
github/codeql#21076 · 3 comentarios · 3 reacciones ·
Los mantenedores suelen responder en 1 día
-
Rust: Axum State captured by a closure is treated as remotePosiblemente ocupada @hvitved la tomó hace 1 día. Abierto
github/codeql#22912 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
github/codeql#22883 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de github/codeql
Issues similares
-
Results from sources can contain invalid host namesPosiblemente ocupada @Mzack9999 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
projectdiscovery/subfinder#1983 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
taylorwilsdon/google_workspace_mcp#1326 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
pypa/advisory-database#412 ·
Los mantenedores suelen responder en 1 día
-
refactor
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día