Ako importovať podania z verejného formulára do súkromnej siete

Sledujte jedno podanie z verejného formulára od záznamu o prijatí po súkromný importér a udržte validáciu, prihlasovacie údaje a spracovanie opakovaní na správnej strane.

Verejný formulár, ktorý nikdy nekomunikuje so súkromnou sieťou, aj tak vytvára údaje, ktoré musí súkromná sieť posúdiť. Tunel mení len to, kto komu volá. Všetko po stiahnutí je rozhodnutie o importe a patrí na súkromnú stranu. Tento návod sleduje jedno podanie od prehliadača po zapísaný interný záznam.

Začnite tam, kde podanie pristane

Prehliadač odosiela na verejný koncový bod, ktorý zapíše riadok do kontrolovaného úložiska prijatia a vráti nič viac ako potvrdenie. Toto úložisko je odovzdávací bod a malo by byť jedinou vecou, do ktorej verejná vrstva môže zapisovať. Surové údaje tam uchovajte nezmenené, spolu s časom príchodu a stabilným identifikátorom záznamu.

Potom súkromný pracovník vytiahne čakajúce riadky cez tunel a rozhodne, čo s každým urobiť. Beží pod vlastnou identitou, a to je téma nasledujúcej časti.

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

Dajte importérovi len oprávnenia, ktoré potrebuje

Verejný webový proces a identita, ktorá zapisuje do internej aplikácie, by mali byť dva rôzne subjekty. Verejný server nepotrebuje internú administráciu len preto, že musí doručiť údaje formulára, a jeden zdieľaný účet pre obe strany mení akúkoľvek webovú chybu na interný zápis. Vydajte pracovníkovi vlastné prihlasovacie údaje, obmedzte ich na jednu operáciu importu a zaznamenávajte, ktorý subjekt vykonal každý import. Práve toto oddelenie robí hranicu tunela zmysluplnou, nie dekoratívnou.

Obmedzte aj to, z akého zdroja môže pracovník čítať. Ak implementácia používa front alebo prenosovú službu, táto služba si zachováva vlastnú autentifikáciu a prístupovú politiku, pretože VPN neautentifikuje nič vnútri obsahu.

Krátkodobá funkcia nie je z tej istej kontroly vyňatá. Kým beží, jej sieťová pozícia a prihlasovacie údaje stále udeľujú oprávnenia a kratšia životnosť len zužuje okno. Životnosť nenahrádza rozhodnutie o tom, ktoré operácie môže identita vykonávať.

Validujte skôr, než sa čokoľvek interné zmení

Polia verejného formulára sú text pod kontrolou útočníka, kým sa nepreukáže opak, a usmernenia OWASP na validáciu vstupu práve preto zaraďujú backendové toky medzi nedôveryhodné zdroje. Šifrovaný prenos hovorí, že bajty dorazili neporušené, nie že opisujú povolenú požiadavku. Parsujte a validujte pred každým privilegovaným krokom, aby sa zlý riadok nikdy nedostal do cesty kódu, ktorá môže konať.

Definujte povolené polia, ich formáty, ich veľkosti a obchodné pravidlá, ktoré musia platiť. Dátum môže byť správne naformátovaný a napriek tomu nesprávny pre požadovanú operáciu, a obsah, ktorý vymenúva interný účet alebo stav schválenia, si nesmie vedieť udeliť ani jedno z toho.

Zamietnuté riadky posielajte do výsledku kontroly namiesto hádania opravy alebo ich preposielania do shellu či surového rozhrania databázy. Zaznamenávajte identifikátor záznamu a pravidlo, ktoré zlyhalo, nie každé pole, ktoré žiadateľ napísal.

Vytvorte bod opakovania na jednej operácii

Ak sa záznam submission-1042 vytiahne dvakrát, pretože prvé potvrdenie sa stratilo, pracovník potrebuje trvalý spôsob, ako rozpoznať zdrojový záznam a jeho zapísaný výsledok. Rozvrh, ktorý úlohu spustí raz, nepreukazuje, že každý riadok bol použitý raz. Dvojité doručenie je bežné, takže návrh ho musí absorbovať.

Použite vlastnú transakciu a mechanizmus spracovania duplikátov internej aplikácie a udržte identifikátor zdroja, výsledok a potvrdenie v jednej súvislej postupnosti. Potvrďte až po tom, čo je zamýšľaná operácia zapísaná alebo trvalo pridelená, a nikdy neodstraňujte riadok prijatia len preto, že boli bajty stiahnuté.

Potom to dokážte tromi pevnými testovacími údajmi: platný riadok, nesprávne naformátovaný riadok a ten istý kontrolovaný identifikátor zdroja doručený dvakrát. Každý z nich prechádza tým istým koncovým bodom, ktorý pracovník používa.

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

Prvé dva riadky musia skončiť v rôznych interných stavoch a tretí musí vrátiť identifikátor už zapísaný pre tento zdrojový záznam namiesto vytvorenia druhého. Čokoľvek iné znamená, že import ešte nie je opakovateľný.

Súvisiace články