Kako uvesti prijave sa javnog obrasca u privatnu mrežu

Pratite jednu prijavu sa javnog obrasca od zapisa o prijemu do privatnog uvoznika i držite validaciju, akreditive i obradu ponovnih pokušaja na pravoj strani.

Javni obrazac koji nikada ne razgovara sa privatnom mrežom ipak proizvodi podatke koje privatna mreža mora procijeniti. Tunel menja samo to ko koga poziva. Sve posle preuzimanja je odluka o uvozu i pripada privatnoj strani. Ovaj vodič prati jednu prijavu od pregledača do zabeleženog internog zapisa.

Počnite tamo gde prijava sleće

Pregledač šalje na javnu krajnju tačku, koja upisuje red u kontrolisano skladište prijema i ne vraća ništa više od potvrde. To skladište je tačka predaje i trebalo bi da bude jedino u šta javni sloj može da upisuje. Držite sirovi sadržaj tamo nepromenjen, zajedno sa vremenom dolaska i stabilnim identifikatorom zapisa.

Zatim privatni radnik povlači redove na čekanju kroz tunel i odlučuje šta će sa svakim. Radi pod sopstvenim identitetom, a to je tema sledećeg odeljka.

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 ovlašćenja koja su mu potrebna

Javni veb proces i identitet koji upisuje u internu aplikaciju trebalo bi da budu dva različita subjekta. Javnom serveru nije potrebna interna administracija samo zato što mora da dostavi podatke obrasca, a jedan deljeni nalog za obe strane pretvara svaku veb grešku u interni upis. Izdajte radniku sopstvene akreditive, ograničite ih na jednu operaciju uvoza i beležite koji je subjekt izvršio svaki uvoz. To razdvajanje čini granicu tunela smislenom, a ne ukrasnom.

Ograničite i iz kog izvora radnik može da čita. Ako implementacija koristi red ili servis za prenos, taj servis zadržava sopstvenu autentifikaciju i politiku pristupa, jer VPN ne autentifikuje ništa unutar sadržaja.

Funkcija kratkog trajanja nije izuzeta od istog pregleda. Dok radi, njen mrežni položaj i akreditive i dalje daju ovlašćenja, a kraći životni vek samo sužava prozor. Životni vek nije zamena za odluku o tome koje operacije identitet može da izvrši.

Validirajte pre nego što se bilo šta interno promeni

Polja javnog obrasca su tekst pod kontrolom napadača dok se ne dokaže suprotno, i OWASP smernice za validaciju unosa upravo zbog toga svrstavaju backend tokove među nepouzdane izvore. Šifrovan prenos kaže da su bajtovi stigli neoštećeni, a ne da opisuju dozvoljen zahtev. Parsirajte i validirajte pre svakog privilegovanog koraka, tako da loš red nikada ne stigne do putanje koda koja može da deluje.

Definišite dozvoljena polja, njihove formate, veličine i poslovna pravila koja moraju da važe. Datum može biti ispravno formatiran i ipak pogrešan za traženu operaciju, a sadržaj koji imenuje interni nalog ili status odobrenja ne sme sebi moći da dodeli ni jedno ni drugo.

Odbijene redove šaljite u rezultat pregleda umesto da nagađate ispravku ili ih prosleđujete u školjku ili sirovi interfejs baze podataka. Beležite identifikator zapisa i pravilo koje nije prošlo, a ne svako polje koje je podnosilac otkucao.

Napravite tačku ponovnog pokušaja na jednoj operaciji

Ako se zapis submission-1042 povuče dvaput jer je prva potvrda izgubljena, radniku je potreban trajan način da prepozna izvorni zapis i njegov zabeležen rezultat. Raspored koji posao pokrene jednom ne dokazuje da je svaki red primenjen jednom. Dupla dostava je normalna, pa dizajn mora da je apsorbuje.

Koristite sopstvenu transakciju i mehanizam za obradu duplikata interne aplikacije i držite identifikator izvora, rezultat i potvrdu u jednom koherentnom nizu. Potvrdite tek kada je nameravana operacija zabeležena ili trajno dodeljena i nikada ne brišite red prijema samo zato što su bajtovi preuzeti.

Zatim to dokažite sa tri fiksirana primera: ispravan red, pogrešno formatiran red i isti kontrolisani identifikator izvora dostavljen dvaput. Svaki od njih prolazi kroz istu krajnju tačku koju 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 reda moraju da završe u različitim internim stanjima, a treći mora da vrati identifikator koji je već zabeležen za taj izvorni zapis umesto da stvori drugi. Bilo šta drugo znači da uvoz još nije ponovljiv.

Povezani članci