OpenVPN auth-user-pass-verify scenarijus: teisingas išėjimo kodas

OpenVPN veikia pagal lygiai vieną prisijungimo scenarijaus išvestį: išėjimo būseną. Visa kita, ką scenarijus daro, yra dekoracija. Kabliukas gali pasiekti tinkamą tikrintoją, išanalizuoti atsakymą ir atspausdinti draugišką eilutę, tačiau grąžinti būseną, reiškiučią priešingą autoriaus ketinimui. Pirmiausia perskaitykite sutartį ir parašykite adapterį aplink ją, ir visa ši klaidų klasė išnyks.

Sutartis maža: nustatykite pateiktą paskyrą, paklauskite patvirtinto tikrintojo numatyto klausimo ir priimkite tik to tikrintojo dokumentuotą teigiamą tos užklausos rezultatą. Visa kita yra infrastruktūra.

Trys būsenos, kurias kabliukas gali grąžinti

auth-user-pass-verify atveju OpenVPN 2.6 vadovas apibrėžia 0 išėjimo kodą kaip priėmimą, 1 kaip atmetimą ir 2 kaip atidėtą autentifikavimą. Tai vieninteliai trys atsakymai, kuriuos supranta serveris, ir kiekvienas turi skirtingą pasekmę ryšiui. Scenarijus, kuris baigiasi savo paskutinės komandos būsena, iš tikrųjų leido žurnalo iškvietimui ar valymo žingsniui balsuoti. Kiekvienoje šakoje aiškiai parašykite būseną, įskaitant šakas, kurios niekada nepasiekė tikrintojo.

HTTP sėkmė ir autentifikavimo sėkmė yra atskiri sluoksniai, ir jų sumaišymas yra dažniausia priežastis, kodėl šis kabliukas suklysta. 202 atsakymas reiškia, kad užklausa priimta apdoroti, o ne kad slaptažodis buvo patikrintas. Apibrėžkite laukiamą būseną, atsakymo formą ir galutinį verdiktą pagal jums duotą API sutartį, ir neišgalvokite lauko pavadinimo vien todėl, kad jis atrodo tikėtinas.

Jei atsakymas tikrai ateina vėliau, tai yra atidėtas kelias ir jį reikia taip ir sukurti. Niekada nebaigiamas atidėtas bandymas laiko išteklius, kol baigiasi laiko limitas.

Skaitykite kredencialų failą tiksliai taip, kaip jis parašytas

Naudojant dokumentuotą failo metodą, serveris įrašo vartotojo vardą ir slaptažodį kaip pirmas dvi laikino failo eilutes, perduoda tą kelią scenarijui ir pašalina failą, kai scenarijus grįžta. Skaitykite tas dvi eilutes kaip duomenis: niekada nevykdykite failo per source, niekada jo nevertinkite ir niekada neįklijuokite jo turinio į komandų eilutę, kurioje jį gali matyti procesų lentelė. Išsaugokite slaptažodį baitas po baito, nes normalizavimas, kaip darytumėte su vartotojo vardu, tyliai pakeičia kredencialus. Tos laikinos failo direktorija yra diegimo sprendimas, todėl patvirtinkite, kad ji egzistuoja ir nėra skaitoma visiems pagrindiniame kompiuteryje.

Laikykite tikrintojo kredencialus atskirai nuo vartotojo: jie priklauso tinklų vartų integracijai, gyvena platformos paslapčių saugykloje ir reikalinga tik patikrinimo teisė, todėl tai nėra įrodymas, kad konkretus asmuo autentifikavosi. Neleiskite kabliukui tapti ir antruoju slaptažodžių tikrintoju. Rankinis maišos palyginimo perrašymas netampa saugus optimizuojant ciklą, o prižiūrimas tikrintojas jau supranta paskyrų saugyklos pasūdytą ir brangią schemą.

Nuspręskite, ką reiškia nesuskirstomas atsakymas

Laiko limitai, transportavimo klaidos, sugadinti atsakymai ir nepasiekiama sistema dalijasi viena savybe: nė vienas iš jų nėra teigiamas patikrinimas. Kabliukas turėtų kiekvienu atveju nepavykdyti uždarai ir įrašyti priežastį, pagal kurią operatorius gali veikti. Ta priežastis priklauso apsaugotam žurnalui, o ne pranešimui, grąžinamam žmogui, kuris bando prisijungti.

Būkite vienodai atsargūs su keliais, kurie visiškai nepasiekia tikrintojo. Trūkstama konfigūracijos reikšmė, neperskaitoma paslaptis ar neįdiegta priklausomybė turėtų duoti atmetimą su ryškiu operaciniu žymekliu, o ne atsitiktinį priėmimą. Išbandykite tas šakas pašalindami priklausomybę laboratorijoje, o ne svarstydami apie jas. Ten, kur žurnalo klaida gali pakeisti išėjimo būseną, žurnalas tapo sprendimo dalimi ir turi būti padarytas nekenksmingas.

Serverio konfigūracija čia taip pat svarbi: vartotojo apibrėžti scenarijai gerbiami tik tada, kai veikianti konfigūracija leidžia juos reikiamame saugumo lygyje, ir tas nustatymas yra sąmoningas pasirinkimas, o ne numatytoji reikšmė, kurią reikia padidinti.

Tikrinkite verdiktą, o ne atspausdintą eilutę

Sukurkite testą, kuris tiesiogiai tikrina išėjimo būseną. Parašykite pavyzdinį kredencialų failą, paleiskite kabliuką su juo naudodami žinomai gerą ir žinomai blogą paskyrą, ir skaitykite būseną, kurią praneša apvalkalas, o ne tekstą, kurį spausdina scenarijus. Vienas šis patikrinimas pagauna daugumą sutarties klaidų, kol klientas dar neprisijungė.

Tada paleiskite tuos pačius atvejus per tikrą klientą prieš neprodukcinį klausytoją ir patvirtinkite, ką serveris įrašė: priimta, atmesta ar atidėta. Apimkite išjungtą paskyrą, neteisingą slaptažodį, sugadintą tikrintojo atsakymą, laiko limitą ir nepasiekiamą tikrintoją. Jei koks nors atvejis atsiduria būsenoje, kurios negalite pavadinti, adapteris nebaigtas.

Laikykite tikrintojo rezultato susiejimą su išėjimo būsena šalia scenarijaus saugykloje, kad kitas inžinierius galėtų perskaityti sutartį be atvirkštinės inžinerijos.