Kako uvesti prijave javnih obrazaca u privatnu mrežu

Pratite jednu javnu prijavu obrasca od zapisa o zaprimanju do privatnog uvoznika i zadržite provjeru, vjerodajnice i ponovne pokušaje na pravoj strani.

Javni obrazac koji nikad ne razgovara s privatnom mrežom ipak proizvodi podatke koje privatna mreža mora procijeniti. Tunel mijenja samo to tko koga poziva. Sve nakon preuzimanja odluka je o uvozu i pripada privatnoj strani. Ovaj pregled prati jednu prijavu od preglednika do potvrđenog internog zapisa.

Počnite ondje gdje prijava sleti

Preglednik objavljuje na javnom završnom odredištu, koje upisuje redak u kontrolirano skladište zaprimanja i ne vraća ništa više od potvrde. To je skladište točka predaje i trebalo bi biti jedino u što javni sloj smije pisati. Držite sirovi sadržaj ondje nepromijenjen, zajedno s vremenom dolaska i stalnim identifikatorom zapisa.

Zatim privatni radnik povlači retke na čekanju kroz tunel i odlučuje što će sa svakim. Radi pod vlastitim identitetom, o čemu govori sljedeće poglavlje.

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 uvozniku samo ovlasti koje su mu potrebne

Javni web proces i identitet koji piše u internu aplikaciju moraju biti dva različita subjekta. Javni poslužitelj ne treba internu administraciju samo zato što mora dostaviti podatke obrasca, a jedan zajednički račun za obje strane pretvara svaku web pogrešku u interni upis. Izdajte radniku vlastite vjerodajnice, ograničite ih na tu jednu operaciju uvoza i bilježite koji je subjekt izvršio svaki uvoz. Upravo to razdvajanje čini granicu tunela smislenom, a ne ukrasnom.

Ograničite i izvor s kojeg radnik smije čitati. Ako implementacija koristi red čekanja ili uslugu prijenosa, ta usluga zadržava vlastitu autentifikaciju i politiku pristupa, jer VPN ne autentificira ništa unutar sadržaja.

Kratkotrajna funkcija nije izuzeta od iste provjere. Dok radi, njezin mrežni položaj i njezine vjerodajnice još uvijek daju ovlasti, a kraći životni vijek samo sužava prozor. Životni vijek nije zamjena za odluku o tome koje operacije identitet smije izvršavati.

Provjerite prije nego se bilo što interno promijeni

Polja javnih obrazaca tekst su pod nadzorom napadača dok se ne dokaže suprotno, i OWASP-ove smjernice za provjeru unosa upravo zato backendove tokove ubrajaju među nepouzdane izvore. Šifrirani prijenos kaže da su bajtovi stigli neoštećeni, a ne da opisuju dopušten zahtjev. Analizirajte i provjerite prije svakog povlaštenog koraka, kako loš redak nikad ne bi došao do putanje koda koja može djelovati.

Definirajte dopuštena polja, njihove formate, veličine i poslovna pravila koja moraju vrijediti. Datum može biti ispravno oblikovan i ipak pogrešan za traženu operaciju, a sadržaj koji imenuje interni račun ili status odobrenja ne smije sam sebi dodijeliti ni jedno ni drugo.

Odbijene retke pošaljite na ishod pregleda umjesto da nagađate ispravak ili ih prosljeđujete ljusci ili sirovom sučelju baze podataka. Zabilježite identifikator zapisa i pravilo koje nije prošlo, a ne svako polje koje je podnositelj upisao.

Napravite točku ponovnog pokušaja na jednoj operaciji

Ako se zapis submission-1042 povuče dvaput jer je prva potvrda izgubljena, radnik treba trajan način da prepozna izvorni zapis i njegov potvrđeni rezultat. Raspored koji posao izvrši jednom ne dokazuje da je svaki redak primijenjen jednom. Dvostruka dostava normalna je pojava, pa je dizajn mora apsorbirati.

Upotrijebite vlastiti mehanizam transakcija i rukovanja duplikatima interne aplikacije i držite identifikator izvora, ishod i potvrdu u jednom povezanom slijedu. Potvrdite tek nakon što je namjeravana operacija potvrđena ili trajno dodijeljena i nikad ne brišite redak zaprimanja samo zato što su bajtovi preuzeti.

Zatim to dokažite s tri testna primjera: valjanim retkom, neispravnim retkom i istim kontroliranim identifikatorom izvora dostavljenim dvaput. Svaki prolazi kroz isto završno odredište koje radnik koristi.

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

Prva dva retka moraju završiti u različitim internim stanjima, a treći mora vratiti identifikator koji je već potvrđen za taj izvorni zapis, umjesto da stvori drugi. Bilo što drugo znači da uvoz još nije ponovljiv.

Povezani članci