Hvernig á að flytja inn opinber eyðublaðsinnsendingar í lokað net

Fylgdu einni opinberri eyðublaðsinnsendingu frá móttökufærslu til einkainnflytjandans og hafðu sannprófun, skilríki og endurtekningartilraunir á réttri hlið.

Opinbert eyðublað sem talar aldrei við lokaða netið framleiðir samt gögn sem lokaða netið verður að dæma um. Göngin breyta aðeins því hver hringir í hvern. Allt eftir niðurhalið er innflutningsákvörðun og tilheyrir einkahlutanum. Þessi yfirferð fylgir einni innsendingu frá vafranum að staðfestri innri færslu.

Byrjaðu þar sem innsendingin lendar

Vafrinn sendir á opinn endapunkt, sem skrifar röð í stýrða móttökugeymslu og skilar engu nema staðfestingu. Sú geymsla er afhendingarstaðurinn, og hún ætti að vera það eina sem opinbera lagið getur skrifað í. Haltu hráu hleðslunni þar óbreyttri, ásamt komutímanum og stöðugri færslukennitölu.

Því næst dregur einkavinnsluaðili biðraðir í gegnum göngin og ákveður hvað gera skal við hverja. Hann keyrir undir eigin auðkenni, sem er efni næsta kafla.

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

Gefðu innflytjandanum aðeins það umboð sem hann þarf

Opinbera vefferlið og auðkennið sem skrifar í innra forritið ættu að vera tveir ólíkir aðilar. Opinber þjónn þarf ekki innri stjórnun bara vegna þess að hann verður að afhenda eyðublaðsgögn, og ein sameiginleg notandaaðgangur fyrir báðar hliðar gerir hverja veffullu að innri skrifum. Gefðu vinnsluaðilanum eigin skilríki, takmarkaðu þau við eina innflutningsaðgerð og skráðu hvaða aðili framkvæmdi hverja innflutning. Þessi aðskilnaður er það sem gerir mörk ganganna merkingarbær en ekki skrautleg.

Takmarkaðu líka frá hvaða uppsprettu vinnsluaðilinn má lesa. Ef útfærslan notar biðröð eða flutningsþjónustu heldur sú þjónusta eigin auðkenningu og aðgangsstefnu, því VPN auðkennir ekkert inni í hleðslunni.

Skammvinn aðgerð er ekki undanþegin sömu skoðun. Meðan hún keyrir veita netstaða hennar og skilríki hennar enn umboð, og styttri líftími þrengir bara gluggann. Líftími kemur ekki í stað ákvörðunar um hvaða aðgerðir auðkennið má framkvæma.

Sannprófaðu áður en eitthvað innra breytist

Reitir opinberra eyðublaða eru texti undir stjórn árásarmanns þar til annað er sannað, og leiðbeiningar OWASP um sannprófun inntaks telja bakendastrauma meðal óáreiðanlegra uppsprettna einmitt af þeirri ástæðu. Dulkóðuð flutningur segir að bætin hafi komið ósködduð, ekki að þau lýsi leyfðri beiðni. Þáttaðu og sannprófaðu fyrir hvert forréttindaþrep, svo slæm röð nái aldrei kóðaslóð sem getur brugðist við.

Skilgreindu leyfða reiti, snið þeirra, stærðir og viðskiptareglur sem verða að gilda. Dagsetning getur verið rétt sniðin og samt röng fyrir aðgerðina sem beðið er um, og hleðsla sem nefnir innri reikning eða samþykkisstöðu má ekki geta veitt sér hvort tveggja.

Sendu hafnaðar raðir í skoðunarniðurstöðu í stað þess að giska á leiðréttingu eða framsenda þær í skel eða hrágagnagrunnsviðmót. Skráðu færslukennitöluna og regluna sem brást, ekki hvern reit sem umsækjandinn skrifaði.

Búðu til endurtökupunkt á einni aðgerð

Ef færslan submission-1042 er dregin tvisvar vegna þess að fyrsta staðfestingin tapaðist þarf vinnsluaðilinn varanlegt leið til að þekkja upprunafærsluna og staðfesta niðurstöðu hennar. Tímaáætlun sem keyrir verkið einu sinni sannar ekki að hver röð hafi verið beitt einu sinni. Tvöföld afhending er eðlileg, svo hönnunin verður að taka við henni.

Notaðu eigin færslu- og tvíritavinnslu innra forritsins og haltu upprunakennitölunni, niðurstöðunni og staðfestingunni í einni samfelldri röð. Staðfestu aðeins eftir að fyrirhuguð aðgerð er staðfest eða varanlega úthlutuð, og eyðileggðu aldrei móttökuröðina bara vegna þess að bætin voru sótt.

Sannaðu það svo með þremur prófunarskrám: gildri röð, gölluðu röð og sama stýrða upprunakennitölu afhentri tvisvar. Hver þeirra fer í gegnum sama endapunkt og vinnsluaðilinn notar.

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

Fyrstu tvær raðirnar verða að enda í ólíkum innri stöðum, og sú þriðja verður að skila kennitölunni sem þegar er staðfest fyrir þá upprunafærslu í stað þess að búa til aðra. Hvað annað sem er þýðir að innflutningurinn er ekki enn endurtakanlegur.

Tengdir greinar