Како да се импортираат поднесоци од јавна форма во приватна мрежа

Следете еден поднесок од јавна форма од записот за прием до приватниот увозник и задржете ја валидацијата, акредитивите и ракувањето со повторувања на правилната страна.

Јавната форма што никогаш не разговара со приватната мрежа сѐ уште произведува податоци што приватната мрежа мора да ги процени. Тунелот само менува кој кого повикува. Сѐ по преземањето е одлука за импорт и таа ѝ припаѓа на приватната страна. Овој преглед следи еден поднесок од прелистувачот до запишан внатрешен запис.

Започнете таму каде што слетува поднесокот

Прелистувачот испраќа барање до јавна крајна точка, која запишува ред во контролирано складиште за прием и враќа ништо повеќе од потврда. Тоа складиште е точката на предавање и треба да биде единственото нешто во кое јавниот слој може да пишува. Чувајте ги необработените податоци таму непроменети, заедно со времето кога пристигнале и стабилен идентификатор на записот.

Потоа приватен работник ги влече редачите што чекаат низ тунелот и одлучува што да прави со секој. Тој работи под сопствен идентитет, што е тема на следниот дел.

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

Дајте му на увозникот само овластувањата што му се потребни

Јавниот веб-процес и идентитетот што пишува во внатрешната апликација треба да бидат два различни субјекти. На јавен сервер не му е потребна внатрешна администрација само затоа што треба да достави податоци од форма, а една заедничка сметка за двете страни ја претвора секоја веб-грешка во внатрешно пишување. Издадете му на работникот сопствени акредитиви, ограничете ги на една операција за импорт и запишете кој субјект го извршил секој импорт. Токму тоа раздвојување ја прави границата на тунелот значајна, а не декоративна.

Ограничете и од кој извор работникот може да чита. Ако имплементацијата користи ред или услуга за пренос, таа услуга ги задржува сопствената автентикација и политиката за пристап, бидејќи VPN не автентикува ништо внатре во податоците.

Краткотрајната функција не е изземена од истиот преглед. Додека работи, нејзината мрежна позиција и нејзините акредитиви сѐ уште даваат овластување, а пократкиот живот само го стеснува прозорецот. Животниот век не е замена за одлуката кои операции може да ги изврши идентитетот.

Валидирајте пред да се промени нешто внатрешно

Полињата на јавната форма се текст контролиран од напаѓачот додека не се докаже спротивното, и упатството на OWASP за валидација на влез токму поради тоа ги смета задните текови за недоверливи извори. Шифрираниот пренос вели дека бајтите пристигнале недопрени, а не дека опишуваат дозволено барање. Парсирајте и валидирајте пред кој било привилегиран чекор, така што лошиот ред никогаш нема да стигне до кодна патека што може да дејствува.

Дефинирајте ги дозволените полиња, нивните формати, нивните големини и деловните правила што мора да важат. Датумот може да биде правилно форматиран, а сепак погрешен за бараната операција, а податоците што именуваат внатрешна сметка или статус на одобрување не смеат сами да си доделат ниту едно од двете.

Испратете ги одбиените редови до резултат од преглед, наместо да погодувате исправка или да ги проследите до школка или суров интерфејс на база на податоци. Запишете го идентификаторот на записот и правилото што не поминало, а не секое поле што го внел барателот.

Направете точка за повторување кај една операција

Ако записот submission-1042 се влече двапати бидејќи првата потврда е изгубена, на работникот му треба трајен начин да го препознае изворниот запис и неговиот запишан резултат. Распоред што ја извршува задачата еднаш не докажува дека секој ред е применет еднаш. Двојната достава е нормална, затоа дизајнот мора да ја апсорбира.

Користете ја сопствената трансакција и механизам за справување со дупликати на внатрешната апликација и чувајте ги изворниот идентификатор, резултатот и потврдата во една кожерентна низа. Потврдете само откако предвидената операција е запишана или трајно доделена и никогаш не го бришете редот за прием само затоа што бајтите се преземени.

Потоа докажете го тоа со три фиксни примероци: валиден ред, погрешно форматиран ред и истиот контролиран изворен идентификатор доставен двапати. Секој од нив поминува низ истата крајна точка што ја користи работникот.

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

Првите два реда мора да завршат во различни внатрешни состојби, а третиот мора да го врати идентификаторот веќе запишан за тој изворен запис, наместо да создаде втор. Сѐ друго значи дека импортот сѐ уште не е повторлив.

Поврзани статии