Kunderegister i CSV: behold rådata og visningskopi hver for seg
CSV til import og en trygg lesekopi kan ha forskjellige roller. Følg opprinnelig kundeverdi gjennom overleveringen før den tas inn i registeret.
Et kunderegister kan leveres som CSV til maskinimport og samtidig åpnes i et regneark for gjennomgang. Det er to forskjellige bruksformer. En bearbeidet visningskopi skal ikke bli autoritativ kundedata uten en forklart transformasjon. Dette gjelder også når endringen var ment å gjøre filen tryggere å vise.
OWASP beskriver at enkelte regneark kan tolke tekstfelt som formler ved åpning, og at beskyttende behandling kan påvirke de opprinnelige dataene. Det finnes ikke én universell regel som passer alle regneark og mottakere. Her er oppgaven å avtale en trygg overlevering, ikke å implementere en parser eller demonstrere skadelige formler.
Avklar hvem filen er laget for
En rådatafil skal ha avtalte kolonner, koder og uendrede kildeverdier. En lesekopi kan ha formatering, merking eller annen representasjon som hjelper medarbeideren å gjennomgå materialet. Begge kan være nyttige, men filenes roller må være synlige.
Spør hvilken fil som skal importeres, hvem som skal åpne en visningskopi, og hvordan verdier med uvanlig tegninnhold behandles. En fil sendt fra en kjent medarbeider kan fortsatt inneholde kundetekst hentet fra et eksternt system. Avsenderens navn beviser ikke at alle feltene er egnet for vilkårlig regnearktolking.
Bevar originalen uendret i et kontrollert mottak. Unngå at den først åpnes og lagres i et regneark før noen har avtalt hvordan det skal skje. Den første gjennomgangen bør ikke utilsiktet bli et nytt eksportformat som senere brukes som kilde.
En tekstverdi i tre roller
Eksemplet er en egen kontrollmodell med harmløse, syntetiske tegnverdier. Det inneholder ingen kjørbar angrepsformel. I prøven er originalverdien det oppdiktede kundenavnet =KUNDETEST. Tegnene er en harmløs testtekst, men det aktuelle regnearket kan forsøke formeltolking når det åpner feltet. En separat visningskopi får derfor et avtalt beskyttende prefiks.
| Representasjon | Eksempeltekst | Formål | Hva må kontrolleres? |
|---|---|---|---|
| Opprinnelig tekst fra registeret | =KUNDETEST | Autoritativ kundeverdi | Behold innhold og kilde |
| Merket visningskopi | VISNING: =KUNDETEST | Menneskelig gjennomgang | Forklar endret representasjon |
| Verdi til kunderegisterimport | =KUNDETEST | Maskinell overtakelse | Samsvar med godkjent original |
Markøren VISNING er bare en illustrasjon av forskjellig representasjon, ikke en generell sikkerhetsløsning for CSV.
Dersom prefikset fra visningskopien importeres som en del av kundenavnet, er verdien endret. Det kan gi feil visning på faktura eller hindre et oppslag mot en eksisterende motpart. At filen åpnes uten varsel, viser dermed ikke at den er riktig maskinelt importgrunnlag.
Det motsatte er også viktig: rådata skal ikke gjøres ufarlig for enhver visningsbruk ved å fjerne legitime tegn fra alle navn. Det kan skade kunderegisteret og skape nye navnekollisjoner. En avtalt løsning kan kreve forskjellige leveranseprofiler for import og visning, med dokumentert sammenheng mellom dem.
Kontroll av CSV-struktur løser et annet spørsmål
Sitering og separatorer bestemmer hvordan feltene deles opp. De er nødvendige formatopplysninger, men er ikke en garanti om hva et regneark vil gjøre med innholdet i det ferdig leste feltet. Bevar dette skillet i kontrollrapporten.
Desimaltegn og kolonneseparator gjelder beløpsparsing. Norske tegn og navnenormalisering gjelder en annen type transformasjon. En kontroll som er bestått på ett område skal ikke omtales som godkjenning av alle tre.
Prøv et avgrenset register med vanlig navn, tegnrik tekst, komma i adresse, ledende nuller i referanse og et tomt felt. La mottakeren sammenholde synlig verdi og faktisk importverdi. Bruk syntetiske person- og kundeopplysninger når den konkrete prøven ikke trenger virkelige identiteter.
Se etter endringer etter gjennomgangen
Et regneark kan endre verdi ved åpning, redigering eller ny lagring. Kontroll av bare den første filen er derfor utilstrekkelig hvis den faktiske overleveringen går gjennom en gjenlagret versjon. Noter hvilket program og hvilke eksportvalg som skapte den nye filen.
Velg noen poster fra originalen og følg dem gjennom den faktiske kjeden. Bevar referanser, tekst og antall kolonner. Hvis mottakeren sender tilbake en rettet fil, må rettelsen kunne skilles fra utilsiktet formatendring. Kildespor og transformasjon gjør det mulig å lokalisere forskjellen.
Når bør overleveringen stoppes?
Hold importen tilbake dersom det er uklart hvilken fil som er kilde, dersom navneverdier er endret uten forklaring, eller dersom mottakeren ikke kan vise resultatet for utvalgte poster. Et riktig radantall er ikke tilstrekkelig når innholdet er forandret.
Godta det avtalte omfanget når original og eventuell visningskopi har tydelige roller, transformasjoner er forklart og relevante importprøver viser riktig verdi. Referanseintegritet i datapakken bør også prøves når registeret følger åpne fakturaer eller andre dokumenter.
Primærkilde og produktgrense
- OWASP om CSV Injection beskriver forskjellen mellom tekst i kilde og mulig formeltolking i regneark, samt begrensninger ved beskyttende behandling.
Guiden beskriver en mottaksavtale for bokførere og dataeiere. Den bekrefter ingen innebygd sikkerhetsfunksjon, gir ingen utnyttelsesoppskrift og foreskriver ikke ett prefiks som en universell løsning.