Sådan importeres offentlige formularindsendelser til et privat netværk

En offentlig formular, der aldrig taler med det private netværk, producerer stadig data, som det private netværk skal vurdere. Tunnelen ændrer kun, hvem der kontakter hvem. Alt efter downloadet er en importbeslutning, og den hører til den private side. Denne gennemgang følger én indsendelse fra browseren til en fastslået intern post.

Begynd hvor indsendelsen lander

Browseren sender til et offentligt endepunkt, som skriver en række i et kontrolleret modtagelseslager og ikke returnerer andet end en kvittering. Det lager er overdragelsespunktet, og det bør være det eneste, det offentlige lag kan skrive til. Hold den rå last uændret der sammen med ankomsttiden og en stabil postidentifikator.

Derefter trækker en privat arbejder ventende rækker gennem tunnelen og beslutter, hvad der skal ske med hver af dem. Den kører under sin egen identitet, hvilket er emnet i næste afsnit.

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

Giv kun importøren den myndighed, den har brug for

Den offentlige webproces og den identitet, der skriver til den interne applikation, bør være to forskellige principaler. En offentlig server har ikke brug for intern administration, blot fordi den skal levere formulardata, og en enkelt delt konto til begge sider gør enhver webfejl til en intern skrivning. Udsted arbejderen sine egne loginoplysninger, begræns dem til den ene importoperation, og registrer, hvilken principal der udførte hver import. Den adskillelse er det, der gør tunnelegrænsen meningsfuld og ikke dekorativ.

Begræns også, hvilken kilde arbejderen må læse fra. Hvis implementeringen bruger en kø eller en overførselsstjeneste, beholder den tjeneste sin egen autentificering og adgangspolitik, fordi VPN ikke autentificerer noget inde i lasten.

En kortlivet funktion er ikke fritaget for samme gennemgang. Mens den kører, giver dens netværksposition og dens loginoplysninger stadig myndighed, og en kortere levetid indsnævrer kun vinduet. Levetid er ikke en erstatning for at beslutte, hvilke operationer identiteten må udføre.

Validér, før noget internt ændres

Offentlige formularfelter er tekst, som en angriber styrer, indtil det modsatte er bevist, og OWASPs vejledning om inputvalidering regner backend-feed med blandt utroværdige kilder netop af den grund. En krypteret overførsel siger, at bytes ankom intakte, ikke at de beskriver en tillad request. Parse og validér før ethvert privilegeret trin, så en dårlig række aldrig når en kodesti, der kan handle.

Definér de tilladte felter, deres formater, deres størrelser og de forretningsregler, der skal gælde. En dato kan være velformet og stadig forkert for den operation, der anmodes om, og en last, der navngiver en intern konto eller en godkendelsesstatus, må ikke kunne tildele sig selv nogen af dem.

Send afviste rækker til et gennemgangsresultat i stedet for at gætte en rettelse eller videresende dem til en skal eller en rå databasegrænseflade. Log postidentifikatoren og den regel, der fejlede, ikke hvert felt, ansøgeren indtastede.

Lav et gentagelsespunkt ved én operation

Hvis posten submission-1042 trækkes to gange, fordi den første kvittering gik tabt, har arbejderen brug for en holdbar måde at genkende kildeposten og dens fastslåede resultat. En tidsplan, der kører jobbet én gang, godtgør ikke, at hver række blev anvendt én gang. Dobbelt levering er normalt, så designet skal absorbere det.

Brug den interne applikations egen transaktions- og dubletbehandlingsmekanisme, og hold kildeidentifikatoren, resultatet og kvitteringen i én sammenhængende sekvens. Kvittér først, efter at den tilsigtede operation er fastslået eller holdbart tildelt, og slet aldrig modtagelsesrækken, blot fordi bytes blev downloadet.

Bevis det derefter med tre testfiler: en gyldig række, en misdannet række og den samme kontrollerede kildeidentifikator leveret to gange. Hver af dem går gennem det samme endepunkt, som arbejderen bruger.

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

De to første rækker skal ende i forskellige interne tilstande, og den tredje skal returnere den identifikator, der allerede er fastslået for den kildepost, i stedet for at oprette en ny. Alt andet betyder, at importen endnu ikke kan gentages.