Si të importoni dërgesat e formularëve publikë në një rrjet privat

Një formular publik që nuk flet kurrë me rrjetin privat prapë prodhon të dhëna që rrjeta private duhet t'i gjykojë. Tuneli ndryshon vetëm kush telefonon kë. Gjithçka pas shkarkimit është një vendim importi dhe i përket anës private. Ky udhëzues ndjek një dërgesë nga shfletuesi deri në një regjistrim të brendshëm të konfirmuar.

Filloni aty ku ateron dërgesa

Shfletuesi dërgon në një pikë fundore publike, e cila shkruan një rresht në një depo pranimi të kontrolluar dhe nuk kthen asgjë më shumë se një konfirmim. Ajo depo është pika e dorëzimit dhe duhet të jetë e vetmja gjë në të cilën shtresa publike mund të shkruajë. Mbajini të dhënat e papërpunuara atje të pandryshuara, bashkë me kohën kur mbërritën dhe një identifikues të qëndrueshëm regjistrimi.

Më pas një punonjës privat tërheq rreshtat në pritje përmes tunelit dhe vendos çfarë të bëjë me secilin. Ai punon nën identitetin e vet, dhe ky është tema e seksionit tjetër.

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

Jepini importuesit vetëm autoritetin që i nevojitet

Procesi publik i uebit dhe identiteti që shkruan në aplikacionin e brendshëm duhet të jenë dy principalë të ndryshëm. Një server publik nuk ka nevojë për administrim të brendshëm vetëm sepse duhet të dorëzojë të dhëna formulari, dhe një llogari e përbashkët për të dyja anët e kthen çdo defekt uebi në shkrim të brendshëm. Lëshoni punonjësit kredencialet e veta, kufizojini ato në një operacion të vetëm importi dhe regjistroni cili principal kreu çdo import. Pikërisht ky ndarje e bën kufirin e tunelit kuptimplotë dhe jo dekorativ.

Kufizoni gjithashtu nga cili burim mund të lexojë punonjësi. Nëse implementimi përdor një radhë ose një shërbim transferimi, ai shërbim mban autentikimin dhe politikën e vet të aksesit, sepse VPN nuk autentikon asgjë brenda ngarkesës.

Një funksion jetëshkurtër nuk përjashtohet nga i njëjti shqyrtim. Ndërsa ekzekutohet, pozicioni i tij në rrjet dhe kredencialet e tij ende japin autoritet, dhe një jetë më e shkurtër vetëm sa ngushton dritaren. Jeta nuk është zëvendësim për vendimin se cilat operacione mund të kryejë identiteti.

Validoni përpara se të ndryshojë diçka e brendshme

Fushat e formularit publik janë tekst i kontrolluar nga sulmuesi derisa të provohet e kundërta, dhe udhëzimet e OWASP për validimin e hyrjes i numërojnë rrjedhat e backend-it mes burimeve të pabesueshme pikërisht për këtë arsye. Një transferim i enkriptuar thotë se bajtët mbërritën të paprekur, jo se përshkruajnë një kërkesë të lejuar. Analizoni dhe validoni përpara çdo hapi të privilegjuar, në mënyrë që një rresht i keq të mos arrijë kurrë në një rrugë kodi që mund të veprojë.

Përcaktoni fushat e lejuara, formatet e tyre, madhësitë e tyre dhe rregullat e biznesit që duhet të plotësohen. Një datë mund të jetë e formatuar mirë dhe prapë e gabuar për operacionin e kërkuar, dhe një ngarkesë që emërton një llogari të brendshme ose një status miratimi nuk duhet të mund t'i japë vetes asnjërën prej tyre.

Dërgojini rreshtat e refuzuar në një rezultat shqyrtimi në vend që të hamendësoni një korrigjim ose t'i përcillni në një shell ose një ndërfaqe të papërpunuar të bazës së të dhënave. Regjistroni identifikuesin e regjistrimit dhe rregullin që dështoi, jo çdo fushë që shtypi aplikanti.

Krijoni një pikë ripërpjekjeje në një operacion

Nëse regjistrimi submission-1042 tërhiqet dy herë sepse konfirmimi i parë u humb, punonjësi ka nevojë për një mënyrë të qëndrueshme për të njohur regjistrimin burim dhe rezultatin e tij të konfirmuar. Një plan që e ekzekuton punën një herë nuk vërteton se çdo rresht u zbatua një herë. Dorëzimi i dyfishtë është normal, kështu që dizajni duhet ta thithë atë.

Përdorni transaksionin dhe mekanizmin e trajtimit të dublikatave të vetë aplikacionit të brendshëm, dhe mbani identifikuesin burim, rezultatin dhe konfirmimin në një sekuencë koherente. Konfirmoni vetëm pasi operacioni i synuar të jetë regjistruar ose caktuar në mënyrë të qëndrueshme, dhe mos fshini kurrë rreshtin e pranimit vetëm sepse bajtët u shkarkuan.

Më pas provojeni me tre fixture: një rresht i vlefshëm, një rresht i formatuar gabimisht dhe i njëjti identifikues burim i kontrolluar i dorëzuar dy herë. Secili kalon nëpër të njëjtën pikë fundore që përdor punonjësi.

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

Dy rreshtat e parë duhet të përfundojnë në gjendje të brendshme të ndryshme, dhe i treti duhet të kthejë identifikuesin e regjistruar tashmë për atë regjistrim burim në vend që të krijojë një të dytë. Çdo gjë tjetër do të thotë që importi nuk është ende i përsëritshëm.