OpenVPN auth-user-pass-verify szkript: a helyes kilépési kód
A hook kilépési állapota a döntés, nem a naplósora. Rendelje a verifier eredményeit 0-hoz, 1-hez vagy halasztotthoz, olvassa adatként a hitelesítő fájlt, és hibánál zárjon elutasítva.
OpenVPN pontosan egy kimenetre épül egy bejelentkezési szkriptnél: a kilépési állapotra. Minden más, amit a szkript tesz, díszítés. A hook elérheti a megfelelő verifiert, elemezheti a választ és kedves sort írhat ki, miközben olyan állapotot ad vissza, amely a szerző szándékával ellentétes jelentésű. Először olvassa el a szerződést, és írja meg köré az adaptert, és az egész hibacsoport eltűnik.
A szerződés kicsi: azonosítsa a beküldött fiókot, tegye fel az engedélyezett verifiernek a szándékolt kérdést, és csak annak a verifiernek az adott kérésre vonatkozó, dokumentált pozitív eredményét fogadja el. Minden más infrastruktúra.
A három állapot, amelyet a hook visszaadhat
A auth-user-pass-verify esetében az OpenVPN 2.6 kézikönyv a 0 kilépési kódot elfogadásként, az 1-et elutasításként, a 2-t halasztott hitelesítésként definiálja. Csak ez a három válasz létezik, amelyet a kiszolgáló ért, és mindegyiknek más a következménye a kapcsolatra. Az a szkript, amely az utolsó parancsa állapotával lép ki, gyakorlatilag szavazni engedett egy naplóhívásnak vagy egy takarítási lépésnek. Minden ágban írja le kifejezetten az állapotot, azokban is, amelyek soha nem érték el a verifiert.
A HTTP-siker és a hitelesítési siker külön rétegek, és ezek összekeverése a leggyakoribb módja annak, hogy ez a hook elrontsa. A 202-es válasz azt jelenti, hogy a kérést feldolgozásra elfogadták, nem azt, hogy egy jelszót ellenőriztek. A várt állapotot, a válasz formáját és a végső ítéletet a kapott API-szerződésből határozza meg, és ne találjon ki mezőnevet csak azért, mert hihetőnek tűnik.
Ha a válasz valóban később érkezik, az a halasztott útvonal, és úgy is kell felépíteni. A soha be nem fejeződő halasztott kísérlet erőforrásokat tart, amíg az időkorlát le nem jár.
Olvassa a hitelesítő fájlt pontosan úgy, ahogy megírták
A dokumentált fájlon keresztüli módszernél a kiszolgáló a felhasználónevet és a jelszót egy ideiglenes fájl első két soraként írja, átadja az útvonalat a szkriptnek, és eltávolítja a fájlt, amikor a szkript visszatér. Ezt a két sort adatként olvassa: soha ne futtassa a fájlt source-ként, soha ne értékelje ki, és soha ne illessze a tartalmát olyan parancssorba, ahol a folyamattábla láthatja. Őrizze meg a jelszót bájtról bájtra, mert a normalizálás, ahogy egy felhasználónevet normalizálna, csendben megváltoztatja a hitelesítő adatot. Az ideiglenes fájl könyvtára telepítési döntés, ezért ellenőrizze, hogy létezik, és hogy a gazdagépen nem olvasható mindenki számára.
Tartsa a verifier saját hitelesítő adatát külön a felhasználétól: az az átjáró-integrációhoz tartozik, a platform titkos tárolójában él, és csak ellenőrzési engedélyre van szüksége, így nem bizonyíték arra, hogy egy adott személy hitelesítette magát. Ne engedje, hogy a hook második jelszóellenőrzővé váljon. A hash-összehasonlítás kézi újraírása nem lesz biztonságos a ciklus optimalizálásától, és egy karbantartott verifier már érti a fióktár sózott és költséges sémáját.
Döntse el, mit jelent a besorolhatatlan válasz
Az időtúllépések, az átviteli hibák, a hibás formátumú válaszok és az elérhetetlen backend egy tulajdonságot osztanak: egyik sem pozitív ellenőrzés. A hooknak mindegyiknél zártan kell meghibásodnia, és olyan okot kell rögzítenie, amelyre az üzemeltető cselekedhet. Ez az ok védett naplóba tartozik, nem a csatlakozni próbáló személynek visszaküldött üzenetbe.
Legyen ugyanilyen óvatos azokkal az útvonalakkal, amelyek egyáltalán nem érik el a verifiert. A hiányzó konfigurációs érték, az olvashatatlan titok vagy a nem telepített függőség megkülönböztetett üzemeltetési jelöléssel járó elutasítást eredményezzen, ne véletlen elfogadást. Ezeket az ágakat a függőség laboratóriumi eltávolításával tesztelje, ne pedig elmélkedjen róluk. Ahol a naplózás hibája megváltoztathatja a kilépési állapotot, ott a naplózás a döntés részévé vált, és ártalmatlanná kell tenni.
A kiszolgáló konfigurációja itt is számít: a felhasználó által meghatározott szkripteket csak akkor veszik figyelembe, ha a futó konfiguráció a szükséges biztonsági szinten engedélyezi őket, és ez a beállítás szándékos választás, nem pedig emelendő alapértelmezés.
Az ítéletet ellenőrizze, ne a kinyomtatott sort
Építsen tesztet, amely közvetlenül vizsgálja a kilépési állapotot. Írjon mintahitelesítő fájlt, futtassa rajta a hookot egy ismerten jó és egy ismerten rossz fiókkal, és a szkript által kiírt szöveg helyett a héj által jelentett állapotot olvassa. Ez az egyetlen ellenőrzés a szerződéshibák többségét elkapja, mielőtt egy ügyfél egyáltalán csatlakozna.
Ezután futtassa ugyanezeket az eseteket valódi ügyfélen keresztül egy nem éles figyelő ellen, és erősítse meg, mit rögzített a kiszolgáló: elfogadva, elutasítva vagy halasztva. Fedje le a letiltott fiókot, a rossz jelszót, a hibás formátumú verifier-választ, az időtúllépést és az elérhetetlen verifiert. Ha bármely eset olyan állapotba kerül, amelyet nem tud megnevezni, az adapter nincs készen.
Tartsa a verifier eredményének kilépési állapotra való leképezését a szkript mellett a tárolóban, hogy a következő mérnök a kód visszafejtése nélkül olvashassa a szerződést.