Request.get w Flask: wektor iniekcji, którego możesz nie zauważyć

Nieodebrana kontrola, która może Cię sporo kosztować: Requests.get i formularz żądania Flask

Wyobraź sobie: początkujący programista pracuje pod presją, aby dostarczyć nową funkcję. Otwiera aplikację Flask, dodaje nową trasę, pobiera parametr zapytania i przechodzi dalej.

				
					# Demonstrative example only — NOT executable, not exploitable
from flask import Flask, request
@app.route("/items")
def get_items():
    # Type casting avoids unsafe string injection
    item_id = request.args.get("id", type=int)
    # Safe usage: forces integer input, prevents injection

Na pierwszy rzut oka użycie tego żądania Flask wygląda dobrze. Ale pomiń typ=int i otwierasz drzwi do ataki wstrzyknięcia. Tego rodzaju ryzyka umykają przeglądom kodu, ponieważ „chodzi tylko o uzyskanie wartości”.

Gdzie kryje się ryzyko FProśba lask oraz FFormularz wniosku lask

Obie kolba.żądanie oraz kolba.formularz.żądania są niezaufanymi punktami wejścia. Każda zwracana przez nie wartość pochodzi bezpośrednio od klienta i powinna być traktowana jako potencjalnie wroga.

Brak weryfikacji lub oczyszczania tych danych może prowadzić do poważnych problemów bezpieczeństwa, w tym:

Zagrożenia te nie dotyczą wyłącznie baz danych i renderowania front-end; atakujący mogą również wykorzystywać dane wejściowe używane w szablonach lub przekazywane do podprocesów.

Bezpieczne wzorce pseudokodu:

				
					python
# ⚠️ Educational example only — not functional
env_target = input("Enter deployment environment: ")
simulate_deploy(env_target)  # Simulated for demonstration

Zapobiegawczy CI/CD egzekwowanie:

				
					# 1. Query parameter — Safe with casting
user_id = request.args.get("id", type=int)  # Enforces integer type

# 2. Form parameter — Safe with casting
username = request.form.get("username", type=str)  # Enforces string type

# 3. Template rendering safeguard
template_data = {"name": request.args.get("name", type=str)}  # Avoids untrusted HTML injection

# 4. Shell command safe handling
filename = request.args.get("file", type=str)
# Validate filename against known safe values before use in subprocess (not shown)

Nawet jeśli składnia wydaje się bezpieczna, używanie surowych lub niesprawdzanych wartości w szablonach lub poleceniach systemowych może stać się poważnym wektorem ataku.

Praktyczny przepływ wtrysku (bezpieczna symulacja)

Oto jak zazwyczaj objawia się wada wtrysku, w fikcyjnym, bezpiecznym scenariuszu:

Użytkownik wysyła do aplikacji odpowiednio spreparowany parametr zapytania.
Aplikacja odczytuje wartość za pomocą request.args.get() bez walidacji.
Wartość ta jest łączona bezpośrednio z zapytaniem SQL, ciągiem szablonu lub poleceniem powłoki.
System realizuje tę logikę, nieświadomy wstrzykiwanej treści.

Pseudokod (niezabezpieczony, jedynie poglądowy):

				
					# Insecure example — do not run in production
user_id = request.args.get("id")  # Missing type casting, no validation
query = f"SELECT * FROM users WHERE id = {user_id}"  # Risk of injection

Fikcyjny ślad dziennika:

				
					[INFO] Incoming request: /user?id=unexpected_input
[DEBUG] Parsed user_id: unexpected_input
[DEBUG] Constructed SQL: SELECT * FROM users WHERE id = unexpected_input

Mimo że w tym przykładzie użyto symboli zastępczych, pokazuje on, jak drobne niedopatrzenia w obsłudze danych wejściowych mogą prowadzić do poważnych luk w zabezpieczeniach.

Testy automatyczne mogą to pominąć, ponieważ zazwyczaj sprawdzają one prawidłowe typy danych wejściowych, a nie nieprawidłowe lub złośliwe.

Ukryte ryzyka w zależnościach Żądanie Flask oraz Formularz zamówienia kolby

Twój kod może być czysty, ale pakiety innych firm nadal mogą go uszkodzić.
Niektóre wtyczki lub biblioteki Flask wewnętrznie wywołują polecenie flask request lub flask request form bez walidacji.

Przykład z pakietami fikcyjnymi:

				
					python

# Insecure example — do not run in production
return AutoFormHandler.process()  # May use request.form.get() without validation

python

# Insecure example — do not run in production
query = build_query(request.args)  # May use request.args.get() without casting

In CI/CD, automatyczne aktualizacje zależności mogą po cichu wprowadzać niebezpieczne wywołania request.get lub podatne na ataki wzorce obsługi danych wejściowych.

Jak niebezpieczne Żądanie Flask Użycie nie przechodzi przez przeglądy kodu

W dynamicznych środowiskach drobne, ale niebezpieczne błędy często pozostają niezauważone, zwłaszcza gdy zmiana wydaje się niegroźna.

Przykład pull request różnica:

				
					# Insecure example — do not run in production
- user_id = request.args.get("id")
+ user_id = request.args.get("id")  # Still missing type casting

Komentarz recenzenta:
„Wygląda dobrze, to tylko pobieranie parametru”.

Tego rodzaju niedopatrzenia zdarzają się często z następujących powodów:

Błąd poznawczy:recenzenci mogą założyć, że request.args.get() jest domyślnie bezpieczne.
Presja czasu:kontrole bezpieczeństwa schodzą na dalszy plan, gdy zbliżają się ostateczne terminy.
Znajomość różnic:zmiana wydaje się niewielka, więc nie przyglądamy się jej bliżej.

Bez jasnych reguł i automatycznego egzekwowania, te subtelne zagrożenia przedostają się do produkcji niezauważone.

Zapobieganie, które działa

Aby ograniczyć ryzyko wstrzyknięcia, należy połączyć walidację danych wejściowych, automatyczne skanowanie i pokrycie testowe.

Walidacja danych wejściowych z użyciem rzutowania i białej listy:

				
					user_id = request.args.get("id", type=int)
if user_id not in [1, 2, 3]:
    abort(400, "Invalid ID")

Rzutowanie wymusza wartość na bezpieczny typ, podczas gdy biała lista zapewnia, że przetwarzane są tylko znane, dobre wartości.

Testowanie bezpieczeństwa aplikacji statycznych (SAST) w CI/CD:

				
					name: Run SAST scan
  run: sast-tool --scan src/ --fail-on "request.args.get without type"

Ten krok pomaga wykryć niezweryfikowane request.args.get() or request.form.get() połączeń zanim dotrą do produkcji.

Testy jednostkowe w celu wymuszenia dezynfekcji:

				
					def test_invalid_type(client):
    response = client.get("/items?id=abc")
    assert response.status_code == 400
These tests ensure the app rejects malformed or malicious input consistently.
Integrating Into DevSecOps Pipelines
Middleware enforcement:
@app.before_request

Testy te zapewniają, że aplikacja konsekwentnie odrzuca nieprawidłowe lub złośliwe dane wejściowe.

Integracja z DevSecOps Pipelines

Wymuszanie oprogramowania pośredniczącego:

@app.before_request

				
					def sanitize_input():
    if "id" in request.args and not request.args.get("id", type=int):
        abort(400, "Invalid ID")
Pre-commit hook:

bash
if grep -R "request.args.get(" . | grep -v "type="; then
    echo "Unsafe request.args.get detected — please add type casting."
    exit 1
fi

Skanowanie zarówno kodu źródłowego, jak i zależności stron trzecich pomaga wychwycić niebezpieczne żądania.get, żądania Flask i użycie formularza żądania Flask zanim dotrą one do produkcji.

Ten problem wykracza poza Flask

Niebezpieczne przetwarzanie danych wejściowych nie jest unikalne dla Flaska, występuje we wszystkich frameworkach internetowych. Na szczęście rozwiązanie jest spójne: weryfikacja danych wejściowych na wczesnym etapie i z dużą dozą rygorystyczności.

Django (bezpieczny pseudokod):

				
					# Enforces integer type and applies whitelist
user_id = int(request.GET.get("id", "0"))
if user_id not in [1, 2, 3]:
    return HttpResponseBadRequest()

FastAPI (bezpieczne dzięki projektowi wykorzystującemu wskazówki dotyczące typów):

				
					from fastapi import Query
@app.get("/items")
def read_items(id: int = Query(..., ge=1, le=3)):
    return {"id": id}

Oba przykłady wymuszają typ i zakres danych wejściowych, zapewniając w ten sposób, że dane przychodzące są wiarygodne zanim dotrą do wrażliwych danych logicznych.

Niezależnie od tego, czy jest to Flask, Django czy FastAPI, każdy parametr żądania jest potencjalnym punktem wstrzyknięcia, jeśli nie zostanie poprawnie sprawdzony.

Wykorzystanie Xygeni do wykrywania w DevSecOps

W środowisku DevSecOps ręczne przeglądy nie wystarczą. Xygeni automatyzuje wykrywanie niebezpiecznych żądań Flask, formularzy żądań Flask i użycia request.get.

Praktyczne zastosowania DevSecOps:

Skanowanie statyczne: Flagi dowolne request.args.get() bez typ =oraz wywołania formularza żądania Flask, którym brakuje walidacji.
Analiza zależności:Monitoruje biblioteki w celu wykrycia niebezpiecznych wzorców, które mogą pojawić się w wyniku wywołań pośrednich.
Blokowanie niebezpiecznych połączeń: CI/CD kończy się niepowodzeniem, jeśli nowy kod wprowadza ryzykowne żądania.get lub niezweryfikowany dostęp do formularza.
Egzekwowanie linii bazowej:Śledzi zmiany, aby zapobiec przekształcaniu się bezpiecznych połączeń w połączenia niebezpieczne.

Automatyzacja tych kontroli zmniejsza ryzyko wystąpienia błędu ludzkiego i zapewnia ciągłość bezpieczeństwa bez spowalniania dostaw.

Więc: walidacja, dezynfekcja, automatyzacja

Oto sedno sprawy: requests.get, flask request i flask request form to wszystko domyślnie niezaufanyZ chęcią dostarczą złośliwe dane, jeśli nie podejmiesz żadnych działań.

Twoje trzy zasady:

Uprawomocnić dane wejściowe za pomocą rzutowania i białych list.
Sanitize zanim dane zostaną wykorzystane do przeprowadzenia wrażliwych operacji.
Automatyzuj sprawdza w twoim pipeline aby zatrzymać niebezpieczny kod przed wdrożeniem.

Pojedynczy niebezpieczny moduł obsługi żądań Flask, niesprawdzone pole formularza żądania Flask lub niechronione wywołanie request.get może zagrozić Twojej aplikacji. Traktuj każdy parametr jako potencjalnie niebezpieczny i pozwól, aby Twoje narzędzia DevSecOps… pipeline egzekwuj zasady za każdym razem.

Request.get w Flask: prosty wektor iniekcji, którego możesz nie zauważyć

Posty, które musisz przeczytać