Com importar els enviaments de formularis públics en una xarxa privada

Un formulari públic que mai no parla amb la xarxa privada igualment produeix dades que la xarxa privada ha de jutjar. El túnel només canvia qui truca a qui. Tot el que ve després de la baixada és una decisió d'importació i pertany al costat privat. Aquest recorregut segueix un enviament des del navegador fins a un registre intern consolidat.

Comenceu on arriba l'enviament

El navegador publica en un punt de terminació públic, que escriu una fila en un magatzem d'entrada controlat i no retorna res més que un acusament de recepció. Aquest magatzem és el punt de lliurament i hauria de ser l'única cosa on la capa pública pot escriure. Manteniu-hi la càrrega original sense canvis, juntament amb l'hora d'arribada i un identificador de registre estable.

A continuació, un treballador privat extreu les files pendents pel túnel i decideix què fer amb cadascuna. Funciona sota la seva pròpia identitat, que és el tema de la secció següent.

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

Dóna a l'importador només l'autoritat que necessita

El procés web públic i la identitat que escriu a l'aplicació interna haurien de ser dos subjectes diferents. Un servidor públic no necessita administració interna només perquè ha de lliurar dades de formulari, i un sol compte compartit per a tots dos costats converteix qualsevol error web en una escriptura interna. Emeteu per al treballador la seva pròpia credencial, limiteu-la a l'única operació d'importació i registreu quin subjecte ha fet cada importació. Aquesta separació és el que fa que la frontera del túnel sigui significativa i no decorativa.

Limiteu també de quina font pot llegir el treballador. Si la implementació fa servir una cua o un servei de transferència, aquest servei conserva la seva pròpia autenticació i política d'accés, perquè la VPN no autentica res dins de la càrrega.

Una funció de curta durada no queda exempta de la mateixa revisió. Mentre s'executa, la seva posició de xarxa i les seves credencials encara atorguen autoritat, i una vida més curta només estreny la finestra. La durada no substitueix la decisió sobre quines operacions pot fer la identitat.

Valideu abans que canviï res intern

Els camps dels formularis públics són text controlat per l'atacant fins que es demostri el contrari, i les directrius de validació d'entrada d'OWASP compten els fluxos del backend entre les fonts no fiables exactament per aquest motiu. Un transport xifrat diu que els bytes han arribat intactes, no que descriguin una petició permesa. Analitzeu i valideu abans de qualsevol pas privilegiat, perquè una fila dolenta no arribi mai a un camí de codi que pugui actuar.

Definiu els camps permesos, els seus formats, les seves mides i les regles de negoci que s'han de complir. Una data pot estar ben formada i tot i així ser incorrecta per a l'operació sol·licitada, i una càrrega que anomena un compte intern o un estat d'aprovació no ha de poder concedir-se'n cap dels dos.

Envieu les files rebutjades a un resultat de revisió en lloc d'endevinar una correcció o de reenviar-les a un intèrpret d'ordres o a una interfície directa de base de dades. Registreu l'identificador del registre i la regla que ha fallat, no tots els camps que ha escrit el sol·licitant.

Feu un punt de reintent en una sola operació

Si el registre submission-1042 s'extreu dues vegades perquè s'ha perdut el primer acusament, el treballador necessita una manera duradora de reconèixer el registre d'origen i el seu resultat consolidat. Una programació que executa la feina una vegada no demostra que cada fila s'hagi aplicat una vegada. El lliurament duplicat és normal, així que el disseny l'ha d'absorbir.

Feu servir el mecanisme propi de transaccions i de gestió de duplicats de l'aplicació interna, i manteniu l'identificador d'origen, el resultat i l'acusament en una seqüència coherent. Acuseu només després que l'operació prevista estigui consolidada o assignada de manera duradora, i no esborreu mai la fila d'entrada només perquè els bytes s'hagin baixat.

Després, demostreu-ho amb tres fitxers de prova: una fila vàlida, una fila mal formada i el mateix identificador d'origen controlat lliurat dues vegades. Cadascun passa pel mateix punt de terminació que fa servir el treballador.

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

Les dues primeres files han d'acabar en estats interns diferents, i la tercera ha de retornar l'identificador ja consolidat per a aquell registre d'origen en lloc de crear-ne un segon. Qualsevol altra cosa vol dir que la importació encara no és repetible.