Slik importerer du innsendingar frå offentlege skjema til eit privat nettverk

Eit offentleg skjema som aldri snakkar med det private nettverket, produserer likevel data som det private nettverket må vurdere. Tunnelen endrar berre kven som ringjer kven. Alt etter nedlastinga er ei importavgjerd, og ho høyrer til den private sida. Denne gjennomgangen følgjer éi innsending frå nettlesaren til ein intern post som er ført inn.

Start der innsendinga landar

Nettlesaren sender til eit offentleg endepunkt, som skriv ei rad inn i eit kontrollert mottakslager og returnerer ikkje meir enn ei stadfesting. Det lageret er overleveringspunktet, og det bør vere det einaste det offentlege laget kan skrive til. Hald den rå nyttelasta der uendra, saman med tida ho kom inn og ein stabil postidentifikator.

Deretter hentar ein privat arbeidar ventande rader gjennom tunnelen og avgjer kva som skal gjerast med kvar einskild. Han køyrer under sin eigen identitet, og det er temaet i neste avsnitt.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

Gi importøren berre den myndet han treng

Den offentlege nettprosessen og identiteten som skriv inn i den interne applikasjonen, bør vere to ulike partar. Ein offentleg server treng ingen intern administrasjon berre fordi han må levere skjemadata, og éin delt konto for begge sider gjer kvar nettfeil om til ei intern skriving. Utferd eigne påloggingsdetaljar til arbeidaren, avgrens dei til den eine importoperasjonen, og registrer kva part som utførte kvar import. Det skillet er det som gjer tunnelgrensa meiningsfull i staden for dekorativ.

Avgrens òg kva kjelde arbeidaren kan lese frå. Viss implementasjonen brukar ein kø eller ein overføringsteneste, held den tenesta si eiga autentisering og tilgangspolicy, fordi VPN ikkje autentiserer noko inne i nyttelasta.

Ein kortlevd funksjon er ikkje friteken frå same gjennomgang. Medan han køyrer, gir nettverksposisjonen og påloggingsdetaljane framleis myndet, og ei kortare levetid gjer berre vindauget smalare. Levetid er ikkje ei erstatning for å avgjere kva operasjonar identiteten kan utføre.

Valider før noko internt blir endra

Offentlege skjemafelt er tekst som åtakkaren kontrollerer, til det motsette er prova, og OWASPs rettleiing for inndatavalidering reknar backend-straumar blant utrygge kjelder nettopp av den grunn. Ei kryptert overføring seier at byta kom intakt fram, ikkje at dei skildrar ein tillaten førespurnad. Pars og valider før kvart privilegert steg, slik at ei dårleg rad aldri når ein kodebane som kan handle.

Definer dei tillatne felta, formata deira, storleikane deira og forretningsreglane som må gjelde. Ein dato kan vere godt formatert og likevel feil for operasjonen som blir føresett, og ei nyttelast som namngir ein intern konto eller ein godkjenningsstatus, må ikkje kunne gi seg sjølv nokon av dei.

Send avviste rader til eit gjennomgangsresultat i staden for å gjette på ei retting eller videresende dei til eit skal eller eit rå databasegrensesnitt. Logg postidentifikatoren og regelen som feila, ikkje kvart felt søkjaren skreiv inn.

Lag eit nytt-forsøk-punkt på éin operasjon

Viss posten submission-1042 blir henta to gonger fordi den første stadfestinga gjekk tapt, treng arbeidaren ein varig måte å kjenne att kjeldeposten og det førte resultatet. Ein plan som køyrer jobben éin gong, fastslår ikkje at kvar rad vart brukt éin gong. Dobbel levering er normalt, så designet må absorbere det.

Bruk den interne applikasjonen sin eigen transaksjon og mekanisme for duplikat, og hald kildeidentifikatoren, resultatet og stadfestinga i éin samanhengande sekvens. Stadfest først etter at den tiltenkte operasjonen er ført inn eller varig tildelt, og slett aldri mottaksrada berre fordi byta vart lasta ned.

Prov det deretter med tre faste testdata: ei gyldig rad, ei feilformatert rad og den same kontrollerte kildeidentifikatoren levert to gonger. Kvar av dei går gjennom det same endepunktet som arbeidaren brukar.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

Dei to første radene må ende i ulike interne tilstandar, og den tredje må returnere identifikatoren som alt er ført inn for den kjeldeposten, i staden for å lage ein ny. Alt anna betyr at importen enno ikkje er repeterbar.