Како увести пријаве са јавног обрасца у приватну мрежу

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

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

Почните тамо где пријава слеће

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

Затим приватни радник повлачи редове на чекању кроз тунел и одлучује шта ће са сваким. Ради под сопственим идентитетом, а то је тема следећег одељка.

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

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

Повезани чланци