OpenVPN auth-user-pass-verify skripts: pareizais izejas kods

OpenVPN darbojas, balstoties uz tieši vienu pieteikšanās skripta izvadi: izejas statusu. Viss pārējais, ko skripts dara, ir dekorācija. Āķis var sasniegt pareizo pārbaudītāju, analizēt atbildi un izdrukāt draudzīgu rindu, bet atgriezt statusu, kas nozīmē pretējo autorības nolūkam. Vispirms izlasiet līgumu un rakstiet adapteri ap to, un visa šī kļūdu klase pazūd.

Līgums ir mazs: identificējiet iesniegto kontu, pajautājiet apstiprinātajam pārbaudītājam paredzēto jautājumu un pieņemiet tikai šī pārbaudītāja dokumentēto pozitīvo rezultātu šim pieprasījumam. Viss pārējais ir infrastruktūra.

Trīs statusi, ko āķis var atgriezt

auth-user-pass-verify gadījumā OpenVPN 2.6 rokasgrāmata definē izejas kodu 0 kā pieņemšanu, 1 kā noraidīšanu un 2 kā atliktu autentifikāciju. Šīs ir vienīgās trīs atbildes, ko serveris saprot, un katrai ir atšķirīgas sekas savienojumam. Skripts, kas beidzas ar savas pēdējās komandas statusu, faktiski ir ļāvis žurnāla izsaukumam vai tīrīšanas solim nobalsot. Rakstiet statusu skaidri katrā zarā, tostarp zaros, kas nekad nesasniedza pārbaudītāju.

HTTP panākumi un autentifikācijas panākumi ir atsevišķi slāņi, un to sajaukšana ir visbiežākais iemesls, kāpēc šis āķis kļūdās. Atbilde 202 nozīmē, ka pieprasījums ir pieņemts apstrādei, nevis ka parole ir pārbaudīta. Definējiet gaidīto statusu, atbildes formu un galīgo spriedumu no jums dotā API līguma, un neizgudrojiet lauka nosaukumu tāpēc, ka tas šķiet ticams.

Ja atbilde patiešām pienāk vēlāk, tas ir atliktais ceļš, un tas tā arī jābūvē. Atlikts mēģinājums, kas nekad netiek pabeigts, tur resursus, līdz beidzas laika limits.

Lasiet akreditācijas failu tieši tā, kā tas ir rakstīts

Dokumentētajā faila metodē serveris ieraksta lietotājvārdu un paroli kā pirmās divas pagaidu faila rindas, nodod šo ceļu skriptam un noņem failu, kad skripts atgriežas. Lasiet šīs divas rindas kā datus: nekad neizpildiet failu ar source, nekad to neizvērtējiet un nekad neielīmējiet tā saturu komandrindā, kur to var redzēt procesu tabula. Saglabājiet paroli baitu pa baitam, jo normalizēšana, kā jūs normalizētu lietotājvārdu, klusi maina akreditācijas datus. Šī pagaidu faila direktorija ir izvietošanas lēmums, tāpēc pārliecinieties, ka tā pastāv un nav lasāma visiem uz resursdatora.

Turiet pārbaudītāja paša akreditācijas datus atsevišķi no lietotāja datiem: tie pieder pie vārtejas integrācijas, dzīvo platformas noslēpumu glabātavā un prasa tikai atļauju pārbaudīt, tāpēc tie nav pierādījums, ka kāda konkrēta persona ir autentificējusies. Neļaujiet āķim kļūt arī par otru paroļu pārbaudītāju. Jaucējvērtības salīdzināšanas pārrakstīšana ar roku nekļūst droša, optimizējot cilpu, un uzturēts pārbaudītājs jau saprot kontu krātuves sāļoto un dārgo shēmu.

Izlemiet, ko nozīmē neklasificējama atbilde

Taimauti, transporta kļūdas, bojātas atbildes un nepieejams aizmugursistēma kopīgo vienu īpašību: neviens no tiem nav pozitīva pārbaude. Āķim katrā no tiem jāizdodas slēgti un jāreģistrē iemesls, pēc kura operators var rīkoties. Šis iemesls pieder aizsargātam žurnālam, nevis ziņojumam, kas tiek atgriezts personai, kura mēģina pieslēgties.

Esiet tikpat rūpīgi ar ceļiem, kas pārbaudītāju nesasniedz vispār. Trūkstoša konfigurācijas vērtība, neizlasāms noslēpums vai neinstalēta atkarība rada noraidījumu ar atšķirīgu operatīvo marķieri, nevis nejaušu pieņemšanu. Pārbaudiet šos zarus, laboratorijā noņemot atkarību, nevis spriežot par tiem. Tur, kur žurnāla kļūme var mainīt izejas statusu, žurnālēšana ir kļuvusi par lēmuma daļu un tā ir jāpadara nekaitīga.

Servera konfigurācija šeit arī ir svarīga: lietotāja definētie skripti tiek ievēroti tikai tad, kad darbojošā konfigurācija tos atļauj vajadzīgajā drošības līmenī, un šis iestatījums ir apzināta izvēle, nevis noklusējums, kas jāpaceļ.

Pārbaudiet spriedumu, nevis izdrukāto rindu

Izveidojiet testu, kas tieši pārbauda izejas statusu. Ierakstiet parauga akreditācijas failu, palaidiet āķi pret to ar zināmu labu un zināmu sliktu kontu un lasiet statusu, ko ziņo čaula, nevis tekstu, ko izdrukā skripts. Šī vienīgā pārbaude pārtver lielāko daļu līguma kļūdu, pirms klients vispār pieslēdzas.

Pēc tam palaidiet tos pašus gadījumus caur īstu klientu pret neprodukcijas klausītāju un apstipriniet, ko serveris ierakstīja: pieņemts, noraidīts vai atlikts. Aptveriet atspējotu kontu, nepareizu paroli, bojātu pārbaudītāja atbildi, taimautu un nesasniedzamu pārbaudītāju. Ja kāds gadījums nonāk stāvoklī, kuru nevarat nosaukt, adapteris nav pabeigts.

Turiet pārbaudītāja rezultāta kartējumu uz izejas statusu blakus skriptam repozitorijā, lai nākamais inženieris varētu izlasīt līgumu, neveicot koda reverso inženieriju.