Openbare formulierinzendingen importeren in een privénetwerk

Volg één openbare formulierinzending van het ontvangstrecord tot de privé-importeur, en houd validatie, inloggegevens en het afhandelen van nieuwe pogingen aan de juiste kant.

Een openbaar formulier dat nooit met het privénetwerk praat, levert toch gegevens op die het privénetwerk moet beoordelen. De tunnel verandert alleen wie wie belt. Alles na de download is een importbeslissing, en die hoort aan de privékant. Deze uitleg volgt één inzending van de browser tot een vastgelegd intern record.

Begin waar de inzending landt

De browser post naar een openbaar eindpunt, dat een rij in een gecontroleerd ontvangstarchief schrijft en niets meer dan een bevestiging teruggeeft. Dat archief is het overdrachtspunt, en het zou het enige moeten zijn waar de openbare laag naar kan schrijven. Bewaar de ruwe payload daar ongewijzigd, samen met het tijdstip van aankomst en een stabiele recordidentificatie.

Daarna haalt een privéwerker wachtende rijen door de tunnel op en beslist wat er met elk daarvan gebeurt. Die draait onder zijn eigen identiteit, en dat is het onderwerp van de volgende sectie.

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

Geef de importeur alleen de bevoegdheid die hij nodig heeft

Het openbare webproces en de identiteit die in de interne applicatie schrijft, zouden twee verschillende principalen moeten zijn. Een openbare server heeft geen interne beheerrechten nodig alleen omdat hij formuliergegevens moet afleveren, en één gedeeld account voor beide kanten maakt van elke webbug een interne schrijfactie. Geef de werker eigen inloggegevens, beperk die tot de ene importbewerking, en leg vast welke principal elke import uitvoerde. Die scheiding is wat de tunnelgrens betekenisvol maakt in plaats van decoratief.

Beperk ook van welke bron de werker mag lezen. Als de implementatie een wachtrij of een overdrachtsdienst gebruikt, houdt die dienst zijn eigen authenticatie en toegangsbeleid, omdat de VPN niets in de payload authenticeert.

Een kortlevende functie is niet vrijgesteld van dezelfde beoordeling. Terwijl die draait, verlenen de netwerkpositie en de inloggegevens nog steeds bevoegdheid, en een kortere levensduur maakt alleen het venster smaller. Levensduur is geen vervanging voor de beslissing welke bewerkingen de identiteit mag uitvoeren.

Valideer voordat er iets intern verandert

Openbare formuliervelden zijn door de aanvaller beheerste tekst tot het tegendeel bewezen is, en OWASP's richtlijn voor invoervalidatie rekent backendifluxen juist daarom tot de onbetrouwbare bronnen. Een versleutelde overdracht zegt dat de bytes intact zijn aangekomen, niet dat ze een toegestaan verzoek beschrijven. Parseer en valideer vóór elke bevoorrechte stap, zodat een slechte rij nooit een codepad bereikt dat kan handelen.

Bepaal de toegestane velden, hun formaten, hun groottes en de bedrijfsregels waaraan moet worden voldaan. Een datum kan goed gevormd zijn en toch verkeerd voor de gevraagde bewerking, en een payload die een interne account of een goedkeuringsstatus noemt, mag zichzelf geen van beide kunnen geven.

Stuur afgewezen rijen naar een beoordelingsuitkomst in plaats van een correctie te gokken of ze door te sturen naar een shell of een ruwe database-interface. Log de recordidentificatie en de mislukte regel, niet elk veld dat de aanvrager typte.

Maak een herhaalpunt op één bewerking

Als record submission-1042 twee keer wordt opgehaald omdat de eerste bevestiging verloren ging, heeft de werker een duurzame manier nodig om het bronrecord en het vastgelegde resultaat te herkennen. Een schema dat de taak één keer uitvoert, stelt niet vast dat elke rij één keer is toegepast. Dubbele levering is normaal, dus het ontwerp moet die opvangen.

Gebruik de eigen transactie en het eigen duplicaatmechanisme van de interne applicatie, en houd de bronidentificatie, de uitkomst en de bevestiging in één samenhangende reeks. Bevestig pas nadat de bedoelde bewerking is vastgelegd of duurzaam is toegewezen, en verwijder de ontvangstrij nooit alleen omdat de bytes zijn gedownload.

Bewijs het daarna met drie vaste testgevallen: een geldige rij, een verkeerd gevormde rij en dezelfde gecontroleerde bronidentificatie die twee keer wordt geleverd. Elk daarvan gaat door hetzelfde eindpunt dat de werker gebruikt.

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

De eerste twee rijen moeten in verschillende interne toestanden eindigen, en de derde moet de identificatie teruggeven die al voor dat bronrecord is vastgelegd in plaats van een tweede aan te maken. Alles anders betekent dat de import nog niet herhaalbaar is.

Gerelateerde artikelen