Как да импортираме подавания от публични форми в частна мрежа

Проследете едно публично подаване от записа за приемане до частния импортер и запазете валидирането, идентификационните данни и повторните опити от правилната страна.

Публичната форма, която никога не разговаря с частната мрежа, все пак създава данни, които частната мрежа трябва да прецени. Тунелът променя само кой на кого се обажда. Всичко след изтеглянето е решение за импорт и принадлежи на частната страна. Този преглед проследява едно подаване от браузъра до записан вътрешен запис.

Започнете от мястото, където попада подаването

Браузърът изпраща заявка до публична крайна точка, която записва ред в контролирано хранилище за приемане и не връща нищо повече от потвърждение. Това хранилище е точката на предаване и трябва да бъде единственото, в което публичният слой може да пише. Пазете необработените данни там непроменени, заедно с времето на пристигане и стабилен идентификатор на записа.

След това частен работник изтегля чакащите редове през тунела и решава какво да прави с всеки от тях. Той работи под собствена идентичност, която е тема на следващия раздел.

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

Първите два реда трябва да завършат в различни вътрешни състояния, а третият трябва да върне идентификатора, вече записан за този изходен запис, вместо да създаде втори. Всичко друго означава, че импортът все още не е повторяем.

Подобни статии