Check injection betydning

• Instrumentering (positiv/neutral): Automatisk indførsel af runtime-kontroller i kode for at fange fejl og overtrædelser (f.eks. bounds-checks, null-checks, assertions). Her er check injection en teknik til at gøre programmer mere sikre og robuste.
• Sikkerhedsangreb (negativ kontekst): I mere løs og uformel brug kan udtrykket henvise til, at en angriber “injekterer” data eller udtryk, der påvirker en kontrolmekanisme (en “check”), så den fejlbedømmer eller kan omgås. Denne betydning overlapper med etablerede injektionskategorier (f.eks. SQL/LDAP/konfigurationsinjektion), men fokuserer på, at selve kontrollen påvirkes.
• QA/DevOps-praksis: Tilføjelse (“injektion”) af ekstra kontroller i byggelinjer, deployments eller platforme, fx policy checks, linters, sikkerhedsskanninger eller admissionskontroller i Kubernetes.

Udtrykket stammer fra engelsk: check (kontrol, validering) og injection (indsprøjtning/indsættelse). I dansk it-sprog bruges det ofte uoversat eller med bindestreg: “check-injection”. Nært beslægtede engelske synonymer er “check insertion” og “instrumentation of checks”.

I kompilatorer, testværktøjer og runtime-miljøer kan man automatisk indsætte ekstra kontroller for at opdage fejl tidligt og forbedre diagnostik.

• Bounds-check injection: Indfører grænsekontroller for array- eller bufferadgang.
• Null-/reference-checks: Indfører kontroller for at undgå null-pointer exceptions.
• Design-by-Contract/assertions: Automatisk injektion af pre/postbetingelser og invariants.
• Sanitizer-instrumentering: Værktøjer som AddressSanitizer/UndefinedBehaviorSanitizer indsprøjter checks for hukommelsesfejl og ubestemt adfærd.
• Sikkerhedskontroller: Indsprøjtning af autorisations- eller inputvalideringslogik via aspekter, bytecode weaving eller middleware.

Illustrativt eksempel (pseudokode):

// Før
int read(int* a, int i) { return a[i]; }
// Efter (med check injection)
int read(int* a, int i) {
  assert(a != NULL);
  assert(0 <= i && i < length(a));
  return a[i];
}

Fordele omfatter hurtigere fejlopsporing, bedre sikkerhedsegenskaber og mere præcise fejlrapporter. Omkostningerne er typisk runtime-overhead og evt. støj fra falske positiver, som dog ofte kan styres via konfiguration (f.eks. kun i test/CI).

I uformel sikkerhedsterminologi kan “check injection” beskrive situationer, hvor angriberen påvirker selve kontrolpunktet - altså den logik, der træffer en afgørelse (tillad/afvis). Det er ikke en standardiseret sårbarhedstype på linje med f.eks. SQL Injection, men et perspektiv på, at målet for manipulationen er kontrollen.

• Eksempler (konceptuelt, højniveau):

  • Indsprøjtning af data, der får en validering til at opføre sig uforudset (fx parser-forgiftning, parameterforurening), så en “check” misfortolker input.
  • Manipulation af politik-/regelfiler (policy-as-code), så adgangskontrollen “letteres”.
  • Indsprøjtning i udtryk, filtre eller forespørgsler, der specifikt beskytter et login eller en autorisationsbeslutning (overlapper med fx LDAP/SQL-injektion).

• Afværgeprincipper (kort): Strenge inputgrænser, parameterisering, kontekstafhængig kodning/escaping, uforanderlige politikker (immutable references), signering af regler/artefakter, adskillelse af pligter (SoD) og “deny-by-default”.

I moderne softwareleverancer “injicerer” man ofte ekstra kvalitetssikring direkte ind i udviklingsprocessen:

• CI-pipelines: Tilføjelse af statisk analyse, licenstjek, SAST/DAST, secret scanning.
• Policy-as-Code: Admission controllers (fx OPA Gatekeeper, Kyverno) der injicerer og håndhæver driftspolitikker ved deployment.
• Service mesh/Middleware: Sidecar- eller filter-baserede checks (ratelimiting, authz) injiceres uden ændring i applikationskoden.

• “Vi aktiverede check injection i testbuilds for at fange out-of-bounds-adgang.”
• “Sanitizerne laver i praksis automatisk check injection af hukommelses- og UB-kontroller.”
• “Ved at injicere preconditions fik vi bedre fejlrapporter i CI.”
• “Admission controlleren udfører check injection på alle deployments, så de følger vores policies.”
• “Angrebet rettede sig mod selve kontrolmekanismen - en slags ‘check injection’ - så valideringen blev omgået.”
• “Bytecode weaving bruges til check injection af autorisationslogik uden at ændre forretningskoden.”
• “Vi slog check injection fra i release-builds for at reducere overhead.”
• “En PR forsøgte at lempe en central regelfil; vi betragter det som forsøg på ‘policy/check injection’ i vores pipeline.”

• Instrumentering: check insertion, runtime-instrumentering, assertionsinjektion, guard-indsættelse, sikkerhedskontroller-instrumentering.
• Sikkerhedsangreb (overlappende/relateret): valideringsmanipulation, policy-injektion, konfigurationsinjektion, inputforgiftning, parser-manipulation. (Mere præcise standardtermer er fx SQL Injection, LDAP Injection, Header Injection, CSV/Formula Injection.)

• Fjernelse af checks: check removal, dead code elimination (hvis den fjerner overflødige kontroller).
• Blind tillid: “trust without verification” versus “trust but verify”.

• 1970’erne-1990’erne: Range checking og assertions i sprog og kompilatorer; tidlige runtime-biblioteker og debug builds med ekstra checks.
• 2000’erne: Forsknings- og industriværktøjer til memory safety (fx Purify, Valgrind-lignende værktøjer, SoftBound/CCured-tilgange) der injicerer kontroller.
• 2010’erne-nu: Udbredte sanitizers i kompilatorer (ASan/UBSan/TSan), AOP/bytecode weaving, CI-baseret “check injection” (linters, SAST, policy-as-code), samt platformniveau-kontroller i cloud/Kubernetes.

Udtrykket er mest almindeligt i tekniske kredse og forekommer både som “check injection” og “check-injection”. På dansk kan man parafrasere med “indsættelse/indsprøjtning af kontroller”. I sikkerhedskontekst er det ofte klarere at bruge de standardiserede sårbarhedsnavne (f.eks. “SQL-injektion”) og kun sige “check injection”, hvis man specifikt mener manipulation af selve kontrolpunktet.

• Instrumentering, tracing og observability
• Design by Contract og assertions
• Sanitizers og runtime checks
• Policy-as-code (OPA, Gatekeeper, Kyverno)
• Inputvalidering og kontekstafhængig escaping
• Injektionssårbarheder: SQL, LDAP, Command, Header, CSV/Formula
• Fault injection og chaos engineering (beslægtet idé om “indsprøjtning”, men målretter fejl frem for kontroller)

“Check injection” er et praktisk paraplyudtryk i it: oftest et positivt værktøj til at indføre flere kontroller i kode og processer; nogle gange en betegnelse for, at netop disse kontroller kan manipuleres. For tydelig kommunikation er det nyttigt at angive konteksten (instrumentering, QA/DevOps eller sikkerhed) og at bruge standardiserede sårbarhedstermer, når man beskriver konkrete angreb.