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 ko koga poziva. Sve nakon preuzimanja je odluka o uvozu i pripada privatnoj strani. Ovaj pregled prati jednu prijavu od preglednika do potvrđenog internog zapisa.

Počnite tamo 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 skladište je točka predaje i treba biti jedino u što javni sloj može pisati. Držite sirovi sadržaj ondje nepromijenjen, zajedno s vremenom dolaska i stalnim identifikatorom zapisa.

Zatim privatni radnik povlači redove na čekanju kroz tunel i odlučuje što će s kojim. 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 mu trebaju

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 greš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 backend tokove ubrajaju među nepouzdane izvore. Šifrirani prijenos kaže da su bajtovi stigli neoštećeni, a ne da opisuju dopušten zahtjev. Parsirajte 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 je normalna, 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