OpenVPN скрипта auth-user-pass-verify: исправан излазни код

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

Уговор је мали: идентификујте налог који је послат, питајте одобрени верификатор намеравано питање и прихватите само документовани позитиван резултат тог верификатора за тај захтев. Све остало је инфраструктура.

Три статуса која кука може да врати

За auth-user-pass-verify приручник OpenVPN 2.6 дефинише излазни код 0 као прихватање, 1 као одбијање и 2 као одложену аутентификацију. То су једина три одговора која сервер разуме, и сваки има другачију последицу за везу. Скрипта која изађе са статусом своје последње наредбе заправо је пустила позив за дневник или корак чишћења да гласа. Запишите статус експлицитно у свакој грани, укључујући гране које никада нису стигле до верификатора.

Успех HTTP-а и успех аутентификације су одвојени слојеви, и њихово мешање је најчешћи начин да ова кука погреши. Одговор 202 значи да је захтев прихваћен за обраду, а не да је лозинка проверена. Дефинишите очекивани статус, облик одговора и коначну пресуду из API уговора који сте добили, и не измишљајте име поља зато што изгледа уверљиво.

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

Читајте датотеку акредитива тачно онако како је записана

У документованом методу преко датотеке сервер записује корисничко име и лозинку као прва два реда привремене датотеке, прослеђује ту путању скрипти и уклања датотеку када се скрипта врати. Читајте та два реда као податке: никада не извршавајте датотеку преко source, никада је не процењујте и никада не лепите њен садржај у командну линију где га може видети табела процеса. Сачувајте лозинку бајт по бајт, јер нормализација, какву бисте применили на корисничко име, тихо мења акредитив. Директоријум за ту привремену датотеку је одлука о распоређивању, зато потврдите да постоји и да није читљив свима на хосту.

Држите сопствене акредитиве верификатора одвојено од корисничких: припадају интеграцији са прелазом, живе у складишту тајни платформе и потребна им је само дозвола за проверу, па нису доказ да се аутентификовала одређена особа. Не дозволите ни да кука постане други верификатор лозинки. Ручно преписивање поређења хеша не постаје безбедно оптимизацијом петље, а одржавани верификатор већ разуме солену и скупу шему складишта налога.

Одлучите шта значи одговор који се не може класификовати

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

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

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

Проверите пресуду, а не одштампан ред

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

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

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