Slik importerer du innsendinger fra offentlige skjemaer til et privat nettverk

Et offentlig skjema som aldri snakker med det private nettverket, produserer likevel data som det private nettverket må vurdere. Tunnelen endrer bare hvem som ringer hvem. Alt etter nedlastingen er en importavgjørelse, og den hører til den private siden. Denne gjennomgangen følger én innsending fra nettleseren til en intern post som er ført inn.

Start der innsendingen lander

Nettleseren sender til et offentlig endepunkt, som skriver en rad inn i et kontrollert mottakslager og returnerer ikke mer enn en bekreftelse. Det lageret er overleveringspunktet, og det bør være det eneste det offentlige laget kan skrive til. Hold den rå nyttelasten der uendret, sammen med tiden den kom inn og en stabil postidentifikator.

Deretter henter en privat arbeider ventende rader gjennom tunnelen og bestemmer hva som skal gjøres med hver enkelt. Den kjører under sin egen 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 bare den myndigheten den trenger

Den offentlige nettprosessen og identiteten som skriver inn i den interne applikasjonen, bør være to forskjellige parter. En offentlig server trenger ingen intern administrasjon bare fordi den må levere skjemadata, og én delt konto for begge sider gjør enhver nettfeil om til en intern skriving. Utsted egne påloggingsdetaljer til arbeideren, begrens dem til den ene importoperasjonen, og registrer hvilken part som utførte hver import. Det skillet er det som gjør tunnelgrensen meningsfull i stedet for dekorativ.

Begrens også hvilken kilde arbeideren kan lese fra. Hvis implementasjonen bruker en kø eller en overføringstjeneste, beholder den tjenesten sin egen autentisering og tilgangspolicy, fordi VPN ikke autentiserer noe inne i nyttelasten.

En kortlevd funksjon er ikke fritatt fra samme gjennomgang. Mens den kjører, gir nettverksposisjonen og påloggingsdetaljene fortsatt myndighet, og en kortere levetid gjør bare vinduet smalere. Levetid er ikke en erstatning for å avgjøre hvilke operasjoner identiteten kan utføre.

Valider før noe internt endres

Offentlige skjemafelt er tekst som angriperen kontrollerer, til det motsatte er bevist, og OWASPs veiledning for inndatavalidering regner backend-strømmer blant utrygge kilder nettopp av den grunn. En kryptert overføring sier at bytene kom intakt frem, ikke at de beskriver en tillatt forespørsel. Pars og valider før ethvert privilegert steg, slik at en dårlig rad aldri når en kodebane som kan handle.

Definer de tillatte feltene, formatene deres, størrelsene deres og forretningsreglene som må gjelde. En dato kan være godt formatert og likevel feil for operasjonen som forespørres, og en nyttelast som navngir en intern konto eller en godkjenningsstatus, må ikke kunne gi seg selv noen av dem.

Send avviste rader til et gjennomgangsresultat i stedet for å gjette på en korreksjon eller videresende dem til et skall eller et rå databasegrensesnitt. Logg postidentifikatoren og regelen som feilet, ikke hvert felt søkeren skrev inn.

Lag et nytt-forsøk-punkt på én operasjon

Hvis posten submission-1042 hentes to ganger fordi den første bekreftelsen gikk tapt, trenger arbeideren en varig måte å kjenne igjen kildeposten og det førte resultatet. En plan som kjører jobben én gang, fastslår ikke at hver rad ble brukt én gang. Dobbel levering er normalt, så designet må absorbere det.

Bruk den interne applikasjonens egen transaksjon og mekanisme for duplikater, og hold kildeidentifikatoren, resultatet og bekreftelsen i én sammenhengende sekvens. Bekreft først etter at den tiltenkte operasjonen er ført inn eller varig tildelt, og slett aldri mottaksraden bare fordi bytene ble lastet ned.

Bevis det deretter med tre faste testdata: en gyldig rad, en feilformatert rad og den samme kontrollerte kildeidentifikatoren levert to ganger. Hver av dem går gjennom det samme endepunktet som arbeideren bruker.

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 radene må ende i forskjellige interne tilstander, og den tredje må returnere identifikatoren som allerede er ført inn for den kildeposten, i stedet for å lage en ny. Alt annet betyr at importen ennå ikke er repeterbar.