Nyilvános űrlapbeküldések importálása zárt hálózatba

Kövessen végig egy nyilvános űrlapbeküldést a fogadási rekordtól a zárt importőrig, és tartsa az érvényesítést, a hitelesítő adatokat és az újrapróbálkozásokat a megfelelő oldalon.

Egy nyilvános űrlap, amely soha nem beszél a zárt hálózattal, mégis olyan adatot állít elő, amelyről a zárt hálózatnak döntenie kell. Az alagút csak azt változtatja meg, ki kit hív. A letöltés utáni minden lépés importdöntés, és a zárt oldalhoz tartozik. Ez a végigvezetés egyetlen beküldést követ a böngészőtől egy rögzített belső rekordig.

Ott kezdje, ahol a beküldés landol

A böngésző egy nyilvános végpontra küld, amely sort ír egy felügyelt fogadási tárolóba, és nem ad vissza többet egy nyugtánál. Ez a tároló az átadási pont, és csak ez lehet az, ahová a nyilvános réteg írhat. Tartsa ott a nyers adatot változatlanul, az érkezés idejével és egy stabil rekordazonosítóval együtt.

Ezután egy zárt feldolgozó az alagúton át lehúzza a várakozó sorokat, és eldönti, mit tesz mindegyikkel. A saját identitása alatt fut, erről szól a következő szakasz.

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

Csak a szükséges jogosultságot adja az importőrnek

A nyilvános webes folyamat és a belső alkalmazásba író identitás két különböző fél legyen. Egy nyilvános kiszolgálónak nem kell belső adminisztráció, csak mert űrlapadatot kell eljuttatnia, és az egy közös fiók mindkét oldalra minden webes hibát belső írássá alakít. Adjon a feldolgozónak saját hitelesítő adatot, korlátozza azt az egyetlen importműveletre, és rögzítse, melyik fél végezte az egyes importokat. Ez az elkülönítés teszi az alagút határát jelentőssé, nem díszítővé.

Azt is korlátozza, melyik forrásból olvashat a feldolgozó. Ha a megvalósítás sort vagy átviteli szolgáltatást használ, az a szolgáltatás megtartja saját hitelesítését és hozzáférési szabályzatát, mert a VPN semmit nem hitelesít az adat belsejében.

A rövid életű függvény sem mentesül ugyanezen felülvizsgálat alól. Amíg fut, hálózati helyzete és hitelesítő adatai továbbra is jogosultságot adnak, és a rövidebb élettartam csak szűkíti az ablakot. Az élettartam nem helyettesíti annak eldöntését, milyen műveleteket végezhet az identitás.

Érvényesítsen, mielőtt bármi belső megváltozik

A nyilvános űrlapok mezői a támadó által vezérelt szöveg, amíg az ellenkezője be nem bizonyosodik, és az OWASP bemenet-érvényesítési útmutatása éppen ezért sorolja a háttérfolyamokat a nem megbízható források közé. A titkosított átvitel azt mondja, hogy a bájtok sértetlenül megérkeztek, nem azt, hogy engedélyezett kérést írnak le. Elemezze és érvényesítse minden kiemelt lépés előtt, hogy egy rossz sor soha ne érjen el cselekvésre képes kódútvonalat.

Határozza meg az engedélyezett mezőket, formátumaikat, méreteiket és a betartandó üzleti szabályokat. Egy dátum lehet jól formázott, és mégis hibás a kért művelethez, és az a terhelés, amely belső fiókot vagy jóváhagyási állapotot nevez meg, nem adhatja meg magának egyiket sem.

A visszautasított sorokat vizsgálati eredményhez küldje, ahelyett hogy javítást találgatna, vagy héjhoz, illetve nyers adatbázis-felülethez továbbítaná őket. A rekordazonosítót és a megsértett szabályt naplózza, ne minden mezőt, amelyet a kérelmező beírt.

Egyetlen művelethez csináljon újrapróbálkozási pontot

Ha a submission-1042 rekordot kétszer húzzák le, mert az első nyugta elveszett, a feldolgozónak tartós módra van szüksége a forrásrekord és annak rögzített eredménye felismeréséhez. Az az ütemezés, amely a feladatot egyszer futtatja, nem bizonyítja, hogy minden sor egyszer került alkalmazásra. Az ismételt kézbesítés normális, ezért a tervezésnek fel kell szívnia.

Használja a belső alkalmazás saját tranzakciós és duplikátumkezelési mechanizmusát, és tartsa a forrásazonosítót, az eredményt és a nyugtát egyetlen összefüggő sorrendben. Csak azt követően nyugtázzon, hogy a szándékolt művelet rögzítésre vagy tartósan hozzárendelésre került, és soha ne törölje a fogadási sort csak azért, mert a bájtok letöltődtek.

Aztán bizonyítsa három tesztfájllal: egy érvényes sorral, egy hibás sorral és ugyanazzal a felügyelt forrásazonosítóval kétszer kézbesítve. Mindegyik ugyanazon a végponton halad át, amelyet a feldolgozó használ.

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

Az első két sornak különböző belső állapotban kell végződnie, a harmadiknak pedig azt az azonosítót kell visszaadnia, amelyet már rögzítettek ahhoz a forrásrekordhoz, nem pedig másodikat létrehoznia. Bármi más azt jelenti, hogy az import még nem ismételhető.

Kapcsolódó cikkek