OpenVPN skripta auth-user-pass-verify: ispravan izlazni kôd

OpenVPN postupa po točno jednom izlazu iz skripte za prijavu: izlaznom statusu. Sve ostalo što skripta radi jest ukras. Hook može doći do pravog verifikatora, analizirati odgovor i ispisati prijateljski redak, a vratiti status koji znači suprotno od onoga što je autor namjeravao. Prvo pročitajte specifikaciju i napišite adapter oko nje i cijela ta klasa pogrešaka nestaje.

Specifikacija je kratka: identificirajte račun koji je poslan, pitajte odobreni verifikator namjeravano pitanje i prihvatite samo dokumentirani pozitivan rezultat tog verifikatora za taj zahtjev. Sve ostalo je infrastruktura.

Tri statusa koja hook može vratiti

Za auth-user-pass-verify, OpenVPN 2.6 priručnik definira izlazni kôd 0 kao prihvaćanje, 1 kao odbijanje i 2 kao odgođenu autentifikaciju. To su jedina tri odgovora koja poslužitelj razumije i svaki od njih ima drukčiju posljedicu za vezu. Skripta koja izađe sa statusom svoje posljednje naredbe zapravo je pustila poziv za zapisivanje ili korak čišćenja da glasuje. Zapišite status izričito u svakoj grani, uključujući grane koje nikada nisu stigle do verifikatora.

HTTP uspjeh i uspjeh autentifikacije odvojeni su slojevi i njihovo poistovjećivanje najčešći je način na koji ovaj hook pogriješi. Odgovor 202 znači da je zahtjev prihvaćen za obradu, a ne da je lozinka provjerena. Definirajte očekivani status, oblik odgovora i konačnu presudu iz API specifikacije koju ste dobili i nemojte izmišljati naziv polja zato što izgleda uvjerljivo.

Ako odgovor doista stigne kasnije, to je odgođeni put i tako ga treba i izgraditi. Odgođeni pokušaj koji se nikada ne dovrši drži resurse dok ne istekne vrijeme čekanja.

Čitajte datoteku vjerodajnica točno onako kako je zapisana

U dokumentiranoj metodi putem datoteke poslužitelj zapisuje korisničko ime i lozinku kao prva dva retka privremene datoteke, predaje tu putanju skripti i uklanja datoteku kad se skripta vrati. Čitajte ta dva retka kao podatke: nikada ne uključujte datoteku preko source, nikada je ne evaluirajte i nikada ne lijepite njezin sadržaj u naredbeni redak u kojem ga može vidjeti tablica procesa. Sačuvajte lozinku bajt po bajt jer normalizacija, kakvu biste primijenili na korisničko ime, tiho mijenja vjerodajnicu. Direktorij za tu privremenu datoteku odluka je o postavljanju, stoga potvrdite da postoji i da nije čitljiv svima na hostu.

Držite vlastite vjerodajnice verifikatora odvojeno od korisničkih: pripadaju integraciji s pristupnikom, žive u spremištu tajni platforme i trebaju samo dopuštenje za provjeru, pa nisu dokaz da se autentificirala određena osoba. Ne dopustite ni da hook postane drugi verifikator lozinki. Ručno ponovno pisanje usporedbe hasha ne postaje sigurno optimiziranjem petlje, a održavani verifikator već razumije zasoljenu i skuplju shemu spremišta računa.

Odlučite što znači odgovor koji se ne može klasificirati

Vremenska ograničenja, transportne pogreške, iskrivljeni odgovori i nedostupni backend dijele jedno svojstvo: nijedno od njih nije pozitivna provjera. Hook bi se za svako od njih trebao zatvoriti i zabilježiti razlog na koji operater može reagirati. Taj razlog pripada zaštićenom dnevniku, a ne poruci koja se vraća osobi koja se pokušava povezati.

Jednako pazite na putanje koje uopće ne stižu do verifikatora. Nedostajuća konfiguracijska vrijednost, nečitljiva tajna ili neinstalirana ovisnost trebaju proizvesti odbijanje s posebnom operativnom oznakom, a ne slučajno prihvaćanje. Testirajte te grane uklanjanjem ovisnosti u laboratoriju, umjesto da o njima razmišljate. Gdje neuspjeh zapisivanja može promijeniti izlazni status, zapisivanje je postalo dio odluke i mora se učiniti bezopasnim.

Konfiguracija poslužitelja i ovdje je važna: skripte koje definira korisnik poštuju se samo kad ih pokrenuta konfiguracija dopušta na potrebnoj razini sigurnosti, a ta je postavka svjestan izbor, a ne zadana vrijednost koju treba podizati.

Provjerite presudu, a ne ispisani redak

Izgradite test koji izravno pregledava izlazni status. Napišite oglednu datoteku vjerodajnica, pokrenite hook na njoj s poznato dobrim i poznato lošim računom i čitajte status koji prijavi ljuska, a ne tekst koji skripta ispiše. Ta jedna provjera hvata većinu pogrešaka u specifikaciji prije nego se klijent uopće poveže.

Zatim pustite iste slučajeve kroz stvarnog klijenta na neprodukcijski slušatelj i potvrdite što je poslužitelj zabilježio: prihvaćeno, odbijeno ili odgođeno. Pokrijte onemogućen račun, pogrešnu lozinku, iskrivljen odgovor verifikatora, vremensko ograničenje i nedostupan verifikator. Ako bilo koji slučaj završi u stanju koje ne možete imenovati, adapter nije dovršen.

Držite preslikavanje ishoda verifikatora u izlazni status uz skriptu u repozitoriju, kako bi sljedeći inženjer mogao pročitati specifikaciju bez obrnutog inženjeringa koda.