Kā importēt publiskās formas iesniegumus privātā tīklā

Izsekojiet vienam publiskās formas iesniegumam no saņemšanas ieraksta līdz privātajam importētājam un turiet validāciju, akreditācijas datus un atkārtojumu apstrādi pareizajā pusē.

Publiska forma, kas nekad nesazinās ar privāto tīklu, joprojām rada datus, kas privātajam tīklam ir jāizvērtē. Tunelis tikai maina to, kurš kuram piezvanīs. Viss pēc lejupielādes ir importa lēmums, un tas pieder privātajai pusei. Šis apskats izseko vienam iesniegumam no pārlūka līdz ierakstītam iekšējam ierakstam.

Sāciet tur, kur iesniegums nonāk

Pārlūks nosūta pieprasījumu uz publisku galapunktu, kas ieraksta rindu kontrolētā saņemšanas krātuvē un atgriež ne vairāk kā apstiprinājumu. Šī krātuve ir nodošanas punkts, un tai jābūt vienīgajai lietai, kurā publiskā slānis drīkst rakstīt. Turiet neapstrādātos datus tur nemainītus, kopā ar ierašanās laiku un stabilu ieraksta identifikatoru.

Pēc tam privāts darbinieks caur tuneli izvelk gaidošās rindas un izlemj, ko darīt ar katru. Tas darbojas ar savu identitāti, un tas ir nākamās sadaļas temats.

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

Piešķiriet importētājam tikai nepieciešamās pilnvaras

Publiskajam tīmekļa procesam un identitātei, kas raksta iekšējā lietotnē, jābūt diviem dažādiem subjektiem. Publiskam serverim nav vajadzīga iekšēja administrēšana tikai tāpēc, ka tam jāpiegādā formas dati, un viens kopīgs konts abām pusēm pārvērš jebkuru tīmekļa kļūdu iekšējā rakstīšanā. Izsniedziet darbiniekam tā paša akreditācijas datus, ierobežojiet tos ar vienu importa darbību un pierakstiet, kurš subjekts veica katru importu. Tieši šī atdalīšana padara tuneļa robežu jēgpilnu, nevis dekoratīvu.

Ierobežojiet arī to, no kāda avota darbinieks drīkst lasīt. Ja ieviešana izmanto rindu vai pārsūtīšanas pakalpojumu, šis pakalpojums saglabā savu autentifikāciju un piekļuves politiku, jo VPN neautentificē neko datu iekšienē.

Īslaicīga funkcija nav atbrīvota no tās pašas pārbaudes. Kamēr tā darbojas, tās tīkla pozīcija un akreditācijas dati joprojām piešķir pilnvaras, un īsāks mūžs tikai sašaurina logu. Mūžs neaizstāj lēmumu par to, kādas darbības identitāte drīkst veikt.

Validējiet, pirms kaut kas iekšējs mainās

Publiskās formas lauki ir uzbrucēja kontrolēts teksts, līdz pierādīts pretējais, un OWASP ievades validācijas norādījumi tieši tāpēc pieskaita aizmugures plūsmas neuzticamiem avotiem. Šifrēta pārsūtīšana nozīmē, ka baiti ieradās neskarti, nevis ka tie apraksta pieļaujamu pieprasījumu. Parsējiet un validējiet pirms jebkura privileģētā soļa, lai slikta rinda nekad nesasniegtu koda ceļu, kas var rīkoties.

Definējiet atļautos laukus, to formātus, izmērus un biznesa noteikumus, kas jāievēro. Datums var būt pareizi formatēts un tomēr nepareizs pieprasītajai darbībai, un datiem, kas nosauc iekšēju kontu vai apstiprinājuma statusu, nedrīkst būt iespējas pašiem sev piešķirt kaut vienu no tiem.

Noraidītās rindas sūtiet uz pārskatīšanas iznākumu, nevis miniet labojumu vai pārsūtiet tās uz čaulu vai neapstrādātu datubāzes saskarni. Reģistrējiet ieraksta identifikatoru un neizdevušos noteikumu, nevis katru lauku, ko pieteikuma iesniedzējs ierakstīja.

Izveidojiet atkārtojuma punktu vienā darbībā

Ja ieraksts submission-1042 tiek izvilkts divreiz, jo pirmais apstiprinājums tika pazaudēts, darbiniekam ir vajadzīgs noturīgs veids, kā atpazīt avota ierakstu un tā ierakstīto rezultātu. Grafiks, kas darbu izpilda vienreiz, nepierāda, ka katra rinda tika piemērota vienreiz. Dublēta piegāde ir normāla, tāpēc dizainam tā ir jāuzņem.

Izmantojiet iekšējās lietotnes pašas transakciju un dublikātu apstrādes mehānismu un turiet avota identifikatoru, iznākumu un apstiprinājumu vienā konsekventā secībā. Apstipriniet tikai pēc tam, kad paredzētā darbība ir ierakstīta vai noturīgi piešķirta, un nekad nedzēsiet saņemšanas rindu tikai tāpēc, ka baiti tika lejupielādēti.

Pēc tam pierādiet to ar trim fiksētiem datu kopām: derīgu rindu, nepareizi formatētu rindu un to pašu kontrolēto avota identifikatoru, kas piegādāts divreiz. Katra no tām iet caur to pašu galapunktu, ko izmanto darbinieks.

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

Pirmajām divām rindām jābeidzas dažādos iekšējos stāvokļos, un trešajai jāatgriež identifikators, kas jau ierakstīts šim avota ierakstam, nevis jārada otrs. Jebkas cits nozīmē, ka imports vēl nav atkārtojams.

Saistītie raksti