Як імпартаваць публічныя формы ў прыватную сетку

Прасачыце адзін публічны адпраўленне формы ад запісу прыёму да прыватнага імпарцёра і пакіньце праверку, уліковыя даныя і паўторныя спробы на правільным баку.

Публічная форма, якая ніколі не звяртаецца да прыватнай сеткі, усё роўна стварае даныя, якія прыватная сетка павінна ацаніць. Тунель змяняе толькі тое, хто з кім злучаецца. Усё пасля загрузкі — гэта рашэнне аб імпарце, і яно належыць прыватнаму боку. Гэты агляд прасочвае адзін адпраўленне ад браўзера да зафіксаванага ўнутранага запісу.

Пачніце з таго, куды трапляе адпраўленне

Браўзер адпраўляе запыт на публічны пункт прыёму, які запісвае радок у кантраляванае сховішча прыёму і вяртае не больш за пацверджанне. Гэтае сховішча — пункт перадачы, і яно павінна быць адзіным, куды можа пісаць публічны ўзровень. Трымайце сырыя даныя там нязменнымі разам з часам іх прыходу і стабільным ідэнтыфікатарам запісу.

Затым прыватны працоўны працэс выцягвае чаканыя радкі праз тунель і вырашае, што рабіць з кожным. Ён працуе пад уласнай ідэнтычнасцю, і гэта тэма наступнага раздзела.

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

Першыя два радкі павінны скончыцца ў розных унутраных станах, а трэці павінен вярнуць ідэнтыфікатар, ужо зафіксаваны для гэтага зыходнага запісу, а не стварыць другі. Усё іншае азначае, што імпарт яшчэ не паўторны.

Падобныя артыкулы