Ocuco Commit Det åpnet en bakdør
En ny funksjon er slått sammen for å håndtere brukeropplastede objekter. Alt består tester, men uker senere avslører en penetrasjonstest at angripere kan utføre kommandoer på serveren; resultatet av usikker deserialisering skjult i koden. Gapet fra deserialisering til ekstern kodekjøring kan være farlig lite, spesielt når serialiserte data fra åpen kildekode-pakker eller interne tjenester er klarert uten validering.
Hva er deserialisering i kode, hvorfor det er risikabelt, og hvor det gjemmer seg
Hva er deserialisering, sett fra utviklerperspektiv? Det er prosessen med å ta strukturerte data, JSON, XML, binære formater eller språkspesifikke serialiserte objekter, og gjøre dem om til objekter i minnet.
På egen hånd, deserialisering er ufarlig og vanlig, for eksempel:
- JavaLese objekter med Objektinndatastrøm
- PythonLaster inn data med pickle.load
- node.jsParsing av JSON med JSON.parse
Risikoen oppstår når deserialisering brukes på upålitelige data uten validering. En angriper kan lage inndata som utløser en gadgetkjede, eksisterende kodebaner som brukes på utilsiktede måter, noe som kan føre til ekstern kjøring av kode.
usikre deserialisering finnes ofte i:
- Åpen kildekode-pakker med usikre standardverdier
- Tilpasset kode som forutsetter at serialisert input er pålitelig
- Tredjeparts API-er returnerer serialiserte objekter uten verifisering
- Bygg gjenstander for eksempel:
- Java .ser filer som inneholder forhåndsserialiserte objekter.
- Python .pkl modellfiler i maskinlæringsarbeidsflyter.
- Serialiserte konfigurasjonsobjekter innebygd i Docker-bilder eller distribusjonsbeholdere
- Java .ser filer som inneholder forhåndsserialiserte objekter.
- Testarmaturer for eksempel:
- Gamle serialiserte testdata kopiert fra produksjonsøyeblikksbilder.
- Serialiserte nyttelaster lastet ned fra eksterne databaser for ytelses- eller regresjonstester.
- Gamle serialiserte testdata kopiert fra produksjonsøyeblikksbilder.
Disse filene kan bli introdusert i et repositorium og lastet inn automatisk under tester eller distribusjoner, noe som utløser usikre deserialisering in CI/CD pipelinefør koden i det hele tatt når produksjon.
Fra usikker deserialisering til ekstern kodekjøring: Angrepsveien
Utnyttelseskjeden for usikker deserialisering følger ofte et av disse mønstrene:
- Upålitelig inndata kommer inn i applikasjonen.
- Usikker deserialisering gjenskaper objekter uten begrensninger.
- En dingsekjede utløser eksisterende funksjonalitet på utilsiktede måter.
- Angriperen eskalerer privilegier og oppnår ekstern kodekjøring.
varianter:
- Java-dingskjeder utnytter gamle biblioteker som Apache Commons.
- Python .pkl modelllasting med innebygde skadelige objekter.
- Node.js JSON-parsing med eval () eller dynamisk import.
Strømme:
Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution
Slik oppdager du usikker deserialisering før sammenslåing
Å fange opp usikker deserialisering før kodesammenslåing er mye billigere enn å fikse det etter utrulling. En kombinasjon av automatisert analyse og proaktiv testing fungerer best:
- Statisk sikkerhetstesting av applikasjoner (SAST):
- Konfigurer skannere for å oppdage risikable API-er som Objektinndatastrøm, pickle.loadog YAML.load uten en sikker laster.
- Skann både kildekode og bygge-/testartefakter for usikre deserialisering mønstre.
- Vis funn direkte i pull requests slik at utviklere kan håndtere dem før de slår seg sammen.
- Konfigurer skannere for å oppdage risikable API-er som Objektinndatastrøm, pickle.loadog YAML.load uten en sikker laster.
- CI/CD Integrasjon:
Eksempel på arbeidsflyt:
sql
Commit → SAST scan → PR alert → Fix before merge
- Blokker sammenslåinger ved kritiske usikre deserialiseringsfunn for å forhindre at usikker kode når produksjonsgrener.
- Enhetstester med simulerte skadelige inndata:
- Opprett ufarlige, kontrollerte nyttelaster som etterligner vanlige serialiserte angrepsobjekter.
- Test hvordan applikasjonen håndterer dem; den bør avvise, rense eller logge inndataene i stedet for å behandle dem blindt.
- Inkluder disse testene i den automatiserte pipeline så de kjører på alle PR-er, og fanger opp usikker deserialiseringsatferd tidlig.
- Sørg for at testnyttelaster ikke er kjørbare og trygge å lagre i depotet, med fokus utelukkende på deteksjonslogikk.
- Opprett ufarlige, kontrollerte nyttelaster som etterligner vanlige serialiserte angrepsobjekter.
Denne lagdelte tilnærmingen kombinerer automatisert skanning med utviklereide tester, noe som sikrer at usikre deserialiseringsstier identifiseres og fjernes lenge før de kan bli sårbarheter for ekstern kodekjøring.
Forebyggingsstrategier for utviklere: Slik hindrer du deserialisering i å bli ekstern kodekjøring
- TillitsgrenserAvserialiser kun fra autentiserte, verifiserte kilder.
- Trygge API-er:
- Java: Sikre biblioteker med validering.
- Python: Bruk json.loads() enn pickle.loads() Hvor mulig.
- Node.js: Unngå eval () eller dynamisk kodeutførelse.
- Java: Sikre biblioteker med validering.
- Tillatelseslister og skjemaerBegrens tillatte objekttyper. Håndhev JSON-skjemaer.
- AvhengighetshygieneOvervåk for CVE-er som nevner deserialisering eller ekstern kodekjøring.
- Kodevurderinger: Legge til deserialisering sikkerhetskontroller til PR-anmeldelsesmaler.
Verktøymerknad: Verktøy som Xygeni Skann kode og avhengigheter for usikker deserialisering før sammenslåing, og identifiser høyrisikoområder slik at utviklere kan fikse dem tidlig.
Eksempel på deteksjonsmønstre på tvers av språk (Sikker pseudokode)
Alle eksemplene nedenfor er renset pseudokode som viser deteksjonsmønstre, ikke fungerende utnyttelser:
Java – Oppdage usikker API-bruk:
java
// BAD: Accepting untrusted input without validation
ObjectInputStream in = new ObjectInputStream(userInputStream);
Object obj = in.readObject(); // Unsafe - no class type checks
// GOOD: Validate allowed classes before processing
if (allowedClasses.contains(obj.getClass().getName())) {
process(obj); // Safe processing of approved classes
}
Python – Unngå usikker deserialisering:
python
import pickle
# BAD: Loading untrusted serialized data directly
data = pickle.loads(untrusted_input) # Unsafe - arbitrary object execution risk
# GOOD: Use JSON with schema validation
import json
data = json.loads(untrusted_input) # Safe when validated against schema
Node.js – Forhindre dynamisk kodekjøring:
javascript
// BAD: Executing code from parsed data
let obj = JSON.parse(untrustedInput);
eval(obj.code); // Unsafe - allows arbitrary code execution
// GOOD: Use fixed logic without dynamic execution
let safeObj = JSON.parse(untrustedInput);
process(safeObj); // Handle only expected properties and values
Automatisering av deteksjon i DevSecOps Pipelines: Fange opp deserialisering før den når produksjon
Automatisering av deteksjon av usikker deserialisering sikrer sårbarheter blir oppdaget og fikset før de fører til ekstern kodekjøring i produksjon.
Pipeline Skanning
- Kjør SAST på kildekode, konfigurasjonsfiler og byggeartefakter på alle commit.
- Oppdag usikre deserialiseringsmønstre i både applikasjonskode og avhengig.
Inspeksjon av gjenstander
- Skanne .ser, .pkl, og andre serialiserte filer for usikre mønstre før utrulling eller kjøring av tester.
Pull Request blokkerer
- Blokker slås sammen hvis usikker deserialisering oppdages.
- Vis handlingsrettet tilbakemelding i PR-er for å fremskynde utbedring.
Håndhevelse av enhetstest
- Inkluder enhetstester med simulerte ondsinnede inndata i CI/CD pipeline
- Mislykkede bygginger hvis applikasjonen behandler usikre serialiserte data i stedet for å avvise dem.
Unngå falske positiver uten å svekke reglene
- Ikke deaktiver deteksjonsregler for å «stille» varsler; dette kan føre til at ekte usikker deserialisering går uoppdaget.
- Bruk en kontrollert hviteliste (tillatelsesliste) for kjente sikre mønstre eller avhengigheter.
- Krev sikkerhetsvalidering før godkjenning av hvitelisteoppføringer.
- Hold hvitelisten under versjonskontroll og gjennomgå den med jevne mellomrom for å sikre at alle unntak forblir berettigede og trygge.
Xygenis rolle
- Integreres direkte i CI/CD pipelines for å skanne både kildekode og byggeartefakter.
- Oppdager usikre deserialiseringsmønstre og risikable avhengigheter tidlig i livssyklusen.
- Støtter policybasert hvitlisting med obligatorisk sikkerhetsgjennomgang, og balanserer deteksjonsnøyaktighet med utviklerproduktivitet.
Ligge i forkant av ekstern kodekjøring gjennom sikker deserialisering
Usikker deserialisering kan forbli ubemerket inntil den blir en direkte vei til ekstern kodekjøring. For å forhindre det kreves følgende:
- Forstå hva deserialisering er og hvordan det kan misbrukes.
- Integrering av automatisert deteksjon i utviklingsarbeidsflyten.
- Regelmessig gjennomgang av avhengigheter, byggeartefakter og serialiserte data som brukes i tester.
Xygenis praktiske rolle i denne prosessen:
- Skanning av kildekodeIdentifiserer usikre deserialiseringsmønstre på tvers av flere språk før koden slås sammen.
- Artefakt- og avhengighetsanalyse: Oppdager risikable serialiserte filer (.ser, .pkl, innebygd konfigurasjon) og tredjepartskomponenter med kjente sårbarheter.
- Policybaserte kontrollerStøtter en kontrollert tillatelsesliste med sikkerhetsvalidering, som sikrer at nødvendige unntak ikke introduserer reelle risikoer.
- Utviklertilbakemeldinger i kontekstFlagger den nøyaktige plasseringen og årsaken til usikker deserialisering inni pull requests, slik at utviklere kan fikse problemer umiddelbart og bekrefte tiltakene gjennom nye skanninger.
Ved å integrere sjekker som disse direkte i CI/CD, lag kan fange opp og avhjelpe usikre deserialisering før den i det hele tatt får sjansen til å eskalere til ekstern kodekjøring i produksjon.
