En savnet sjekk som kan koste deg penger: Requests.get og Flask-forespørselsskjema
Tenk deg dette: en juniorutvikler jobber under press for å levere en funksjon. De åpner en Flask-app, legger til en ny rute, henter en spørreparameter og går videre.
# 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
Ved første øyekast ser denne Flask-forespørselen grei ut. Men utelat type=int og du åpner døren til injeksjonsangrep. Dette er den typen risikoer som slipper forbi kodevurderinger fordi «det bare henter en verdi».
Der risikoen skjuler seg Flask-forespørsel og FLask forespørselsskjema
Begge kolbe.forespørsel og flaske.forespørsel.skjema er upålitelige inngangspunkter. Hver verdi de returnerer kommer direkte fra klienten og bør behandles som potensielt fiendtlig.
Hvis disse dataene ikke valideres eller renses, kan det føre til kritiske sikkerhetsproblemer, inkludert:
Disse risikoene gjelder ikke bare databaser eller frontend-rendering; angripere kan også utnytte inndata som brukes i maler eller sendes til underprosesser.
Sikre pseudokodemønstre:
python
# ⚠️ Educational example only — not functional
env_target = input("Enter deployment environment: ")
simulate_deploy(env_target) # Simulated for demonstration
Forebyggende CI/CD håndheving:
# 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)
Selv om syntaksen ser trygg ut, kan bruk av rå eller ukontrollerte verdier i maler eller systemkommandoer bli en alvorlig injeksjonsvektor.
Praktisk injeksjonsstrøm (sikker simulering)
Slik utfolder en injeksjonsfeil seg vanligvis, ved hjelp av et fiktivt, trygt scenario:
- En bruker sender en utformet spørreparameter til applikasjonen.
- Appen leser verdien ved hjelp av request.args.get() uten validering.
- Den verdien kobles direkte sammen til en SQL-spørring, malstreng eller skallkommando.
- Systemet utfører den logikken, uvitende om det injiserte innholdet.
Pseudokode (usikker, kun illustrerende):
# 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
Fiktiv loggsporing:
[INFO] Incoming request: /user?id=unexpected_input
[DEBUG] Parsed user_id: unexpected_input
[DEBUG] Constructed SQL: SELECT * FROM users WHERE id = unexpected_input
Selv om dette eksemplet bruker plassholdere, gjenspeiler det hvordan små forglemmelser i håndteringen av inndata kan føre til kritiske sårbarheter.
Automatiserte tester kan overse dette fordi de vanligvis tester for gyldige inputtyper, ikke misdannede eller ondsinnede.
Skjulte risikoer ved bruk av avhengigheter Kolbeforespørsel og Skjema for forespørsel om kolbe
Koden din kan være ren, men tredjepartspakker kan fortsatt ødelegge for deg.
Noen Flask-pluginer eller -biblioteker kaller internt flaskeforespørsler eller flaskeforespørselsskjemaer uten validering.
Eksempel med fiktive pakker:
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, kan automatiserte avhengighetsoppdateringer stille introdusere usikre forespørsler, hent-kall eller sårbare inndatahåndteringsmønstre.
Hvor utrygt Kolbeforespørsel Bruksslipper tidligere kodevurderinger
I fartsfylte miljøer går små, men farlige feil ofte ubemerket hen, spesielt når endringen virker harmløs.
Eksempel pull request forskjell:
# Insecure example — do not run in production
- user_id = request.args.get("id")
+ user_id = request.args.get("id") # Still missing type casting
Anmelderkommentar:
«Ser greit ut, det henter bare en parameter.»
Denne typen overseelse er vanlig på grunn av:
- Kognitiv skjevhetAnmeldere kan anta at request.args.get() er trygt som standard.
- TidspressSikkerhetskontroller blir satt i bakgrunnen når frister truer.
- Forskjell kjennskapEndringen ser liten ut, så den blir ikke gransket grundig.
Uten klare regler eller automatisert håndheving, glir disse subtile risikoene ubemerket inn i produksjonen.
Forebygging som virker
For å redusere risikoen for injeksjon, kombiner inputvalidering, automatisert skanning og testdekning.
Validering av inndata med casting og hvitlisting:
user_id = request.args.get("id", type=int)
if user_id not in [1, 2, 3]:
abort(400, "Invalid ID")
Casting tvinger verdien til en sikker type, mens hvitlisting sikrer at bare kjente gode verdier fortsetter.
Statisk sikkerhetstesting av applikasjoner (SAST) i CI/CD:
name: Run SAST scan
run: sast-tool --scan src/ --fail-on "request.args.get without type"
Dette trinnet bidrar til å oppdage uvaliderte request.args.get() or forespørsel.skjema.get() samtaler før de når produksjon.
Enhetstester for å håndheve sanering:
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
Disse testene sikrer at appen avviser feil eller ondsinnet inndata konsekvent.
Integrering i DevSecOps Pipelines
Håndheving av mellomvare:
@app.før_forespørsel
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
Skanner både koden din og tredjepartsavhengigheter hjelper med å fange opp usikre requests.get, flask request og flask request form use før det når produksjon.
Dette problemet går utover kolben
Usikker håndtering av inndata er ikke unik for Flask, den finnes på tvers av nettrammeverk. Heldigvis er løsningen konsekvent: valider inndata tidlig og strengt.
Django (sikker pseudokode):
# 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 (sikker i design ved bruk av typehint):
from fastapi import Query
@app.get("/items")
def read_items(id: int = Query(..., ge=1, le=3)):
return {"id": id}
Begge eksemplene håndhever inndatatype og -område, noe som sikrer at innkommende data er klarert før de når sensitiv logikk.
Enten det er Flask, Django eller FastAPI, er hver forespørselsparameter et potensielt injeksjonspunkt hvis den ikke valideres riktig.
Bruk av Xygeni for deteksjon i DevSecOps
I et DevSecOps-miljø er ikke manuelle gjennomganger nok. Xygeni automatiserer deteksjon av utrygge flaskeforespørsler, flaskeforespørselsskjema og requests.get-bruk.
Praktiske DevSecOps-applikasjoner:
- Statiske skanninger: Flagger alle request.args.get() uten type=, og kall på forespørselsskjema for flasker mangler validering.
- AvhengighetsanalyseOvervåker biblioteker for usikre mønstre som kan dukke opp via indirekte kall.
- Blokkering av usikre sammenslåinger: CI/CD mislykkes hvis ny kode introduserer risikable requests.get eller uvalidert skjematilgang.
- Grunnleggende håndhevingSporer endringer for å hindre at sikre anrop blir til usikre anrop.
Automatisering av disse kontrollene reduserer risikoen for menneskelige feil og holder sikkerheten kontinuerlig uten å bremse leveringen.
Så, valider, desinfiser, automatiser
Her er konklusjonen: requests.get, flask request og flask request form er alle ikke klarert som standardDe leverer gjerne skadelige data med mindre du tar affære.
Dine tre regler:
- Validere inndata ved hjelp av casting og hvitelister.
- rense før dataene berører sensitive operasjoner.
- Automat sjekker inn din pipeline for å stoppe usikker kode før utrulling.
En enkelt usikker flaskeforespørselsbehandler, et ukontrollert flaskeforespørselsskjemafelt eller et ubeskyttet requests.get-kall kan kompromittere applikasjonen din. Behandle alle parametere som potensielt fiendtlige, og la DevSecOps pipeline håndheve reglene hver gang.
