OpenVPN-skriptet auth-user-pass-verify: riktig utgangskode

OpenVPN handler på nøyaktig én utgang fra et innloggingsskript: utgangsstatusen. Alt annet skriptet gjør, er dekorasjon. En hook kan nå riktig verifiserer, parse svaret og skrive ut en vennlig linje, men returnere en status som betyr det motsatte av det forfatteren mente. Les kontrakten først og skriv adapteren rundt den, så forsvinner hele den feilklassen.

Kontrakten er liten: identifiser kontoen som ble sendt, still den godkjente verifisereren det tiltenkte spørsmålet, og godta bare den dokumenterte positive resultatet fra den verifisereren for den forespørselen. Alt annet er infrastruktur.

De tre statusene hooken kan returnere

For auth-user-pass-verify, OpenVPN 2.6-håndboken definerer utgangskode 0 som aksept, 1 som avvisning og 2 som utsatt autentisering. Det er de eneste tre svarene serveren forstår, og hvert av dem har en annen konsekvens for tilkoblingen. Et skript som avslutter med statusen fra sin siste kommando, har i praksis latt et loggkall eller et opprydningstrinn stemme. Skriv statusen eksplisitt i hver gren, også i grenene som aldri nådde verifisereren.

HTTP-suksess og autentiseringssuksess er atskilte lag, og å blande dem er den vanligste måten denne hooken går galt. Et 202-svar betyr at forespørselen er akseptert for behandling, ikke at et passord er verifisert. Definer forventet status, svarets form og den endelige dommen ut fra API-kontrakten du fikk, og ikke finn opp et feltnavn fordi det virker plausibelt.

Hvis svaret virkelig kommer senere, er det den utsatte veien, og den må bygges som sådan. Et utsatt forsøk som aldri fullføres, holder ressurser til tidsavbruddet utløper.

Les legitimasjonsfilen nøyaktig slik den er skrevet

Med den dokumenterte via-fil-metoden skriver serveren brukernavn og passord som de to første linjene i en midlertidig fil, sender stien til skriptet og fjerner filen når skriptet returnerer. Les de to linjene som data: kjør aldri filen gjennom source, evaluer den aldri, og lim aldri innholdet inn i en kommandolinje der prosesstabellen kan se det. Bevar passordet byte for byte, fordi normalisering, slik du ville normalisert et brukernavn, stille endrer legitimasjonen. Katalogen for den midlertidige filen er en driftsbeslutning, så bekreft at den finnes og ikke er lesbar for alle på verten.

Hold verifisererens egne legitimasjon adskilt fra brukerens: den tilhører gateway-integrasjonen, bor i plattformens hemmelighetslager og trenger bare tillatelsen til å verifisere, så den er ikke bevis på at en bestemt person er autentisert. Ikke la hooken bli en andre passordverifiserer heller. Håndskrevet hash-sammenligning blir ikke trygg av å optimalisere løkken, og en vedlikeholdt verifiserer forstår allerede kontoarkivets salte og kostbare ordning.

Bestem hva et uklassifiserbart svar betyr

Tidsavbrudd, transportfeil, ødelagte svar og en utilgjengelig backend deler én egenskap: ingen av dem er en positiv verifisering. Hooken bør svikte lukket for hver av dem og registrere en grunn som en operatør kan handle på. Den grunnen hører i en beskyttet logg, ikke i en melding som returneres til personen som prøver å koble til.

Vær like nøye med veiene som ikke når verifisereren i det hele tatt. En manglende konfigurasjonsverdi, en uleselig hemmelighet eller en avhengighet som ikke er installert bør gi en avvisning med en tydelig operativ markør i stedet for en utilsiktet aksept. Test de grenene ved å fjerne avhengigheten i et laboratorium i stedet for å resonnere om dem. Der en feil i loggingen kan endre utgangsstatusen, er loggingen blitt en del av beslutningen og må gjøres ufarlig.

Serverkonfigurasjon betyr noe her også: brukerdefinerte skript respekteres bare når den kjørende konfigurasjonen tillater dem på det påkrevde sikkerhetsnivået, og den innstillingen er et bevisst valg og ikke en standardverdi som skal heves.

Verifiser dommen, ikke den utskrevne linjen

Bygg en test som inspiserer utgangsstatusen direkte. Skriv en prøvelegitimasjonsfil, kjør hooken mot den med en kjent god og en kjent dårlig konto, og les statusen som skallet rapporterer i stedet for teksten skriptet skriver ut. Den ene kontrollen fanger de fleste kontraktfeil før en klient i det hele tatt kobler til.

Kjør deretter de samme tilfellene gjennom en ekte klient mot en ikke-produksjonslytter og bekreft hva serveren registrerte: akseptert, avvist eller utsatt. Dekk en deaktivert konto, feil passord, et ødelagt verifiserersvar, et tidsavbrudd og en utilgjengelig verifiserer. Hvis noe tilfelle havner i en tilstand du ikke kan navngi, er adapteren ikke ferdig.

Hold koblingen fra verifisererresultat til utgangsstatus ved siden av skriptet i repositoriet, slik at neste ingeniør kan lese kontrakten uten å reversere koden.