WebToDate/Referenční/Bezpečnost

Autentifikace

Standardní způsob autentifikace

Standardní způsob autentifikace uživatelů do redakční části systému je autentifikace formulářem. To znamená, že na URL (daném zejména konfigurační konstantou ADMINPATH) se nachází přihlašovací formulář, kde se zadává jméno a heslo.

Seznam uživatelů v tomto případě spravuje administrátor WebToDate přes standardní funkce aplikace.

Všechna nastavení uživatele jsou uložena v databázi WebToDate. Pro ukládání hesel existuje konfigurační konstanta USEMD5PASSWORDS:

define( 'USEMD5PASSWORDS', true );

Nastavení na hodnotu true znamená, že se ukládají pouze hashe hesel pomocí algoritmu MD5, nastavení false znamená ukládání hesel jako čistý text (z bezpečnostních důvodů rozhodně není pro ostrý provoz doporučeno).

Zásuvné moduly pro autentizaci

Druhou možností je využít tzv. zásuvné moduly pro autentizaci. Jedná se o kódy, které jsou navázány na proces přihlašování a které lze s dodržením zásad pro tvorbu těchto kódů vytvářet.

Využití zásuvného modulu pro autentizaci se zapíná pomocí konfigurační konstanty

define('INTEGAUTHENT', true);

Tato konstanta vyřazuje standardní proces přihlašování a nastavuje volání zásuvného autentizačního modulu. Kde je vlastní kód tohoto modulu definuje konstanta AUTH_MODULE:

define( 'AUTH_MODULE', 'auth/_http_basic.php');

Konstanta obsahuje cestu k autentizačnímu modulu relativní vůči WebToDate adresáři classes.

Je-li tedy toto zapnuto, autentizační modul musí zjistit přihlašovací údaje a vrací je zpět do WebToDate. Konfigurační konstanta AUTH_AUTO_ADD_NEW_USER v tom případě určuje, zda úspěšně autentizované uživatele pouze vyhledávat v seznamu uživatelů WebToDate nebo automaticky přidat do seznamu uživatelů.

define('AUTH_AUTO_ADD_NEW_USER', true);

Pokud je automatické přidávání zapnuto, použijí se údaje vrácené autentizační funkcí k tomu, aby se v případě, že uživatel není v seznamu uživvatelů nalezen, založil nový účet s využitím údajů vrácených autentizačním modulem (uživatelské jméno, jméno a příjmení, e-mail apod.). Je-li nalezen existující uživatel, nic se automaticky v seznamu uživatelů WebToDate nemění a využije se jen uživatelské jméno k přihlášení.

Pokud je automaticky přidán nový uživatel, odesílá se volitelně e-mail uživatelům, kteří jsou členové týmu Administrátoři informující o tom, že byl přidán nový uživatel. Odesílání těchto e-mailů ovlivňuje nastavení

define('AUTH_AUTO_ADD_SEND_MAIL', true);

V distribuci WebToDate je dodáván výchozí autentizační modul _http_basic.php, který je použitelný v případě, že vlastní autentizaci provádí např. operační systém nebo web server (např. web server Apache pomocí souboru .htaccess, na MS Windows Active Directory). Tato volba je vhodná zejména pro použití WebToDate na správu intranetového serveru.

Další autentizační moduly (např. pro autentizaci vůči LDAP, zvolenému Identity Management serveru apod.) mohou být vytvořeny.

Interní bezpečnostní funkce

Pokud je pro redakční rozhraní nastavená integrovaná autentifikace, informace o neúspěšném pokusu o přihlášení se do skriptu vůbec nedostane a tuto variantu je možné ošetřit na úrovni operačního systému (např. zamknout účet ve Windows po x pokusech o přihlášení).

Pokud se jedná o autentifikaci formulářem a redakční rozhraní je přístupné přes Internet, mohou nastat tyto případy:

• Náhodné manuální pokusy – útočník vyplňuje náhodně přihlašovací formulář a zkouší uhodnout heslo. To lze sledovat v rámci jedné session, ale pouze v případě, že uživatel má povolené cookies.
• Slovníkový útok – útočník používá jednoduchou aplikaci – robota, která zasílá na přihlašovací skript požadavky obsahující vyplněná data formuláře, přičemž jméno uživatele a heslo se snaží uhodnout tato aplikace, zpravidla podle nějakého slovníku či podobných postupů. Tento útok se vyznačuje tím, že lze generovat mnoho pokusů v krátkém čase a že jej nelze registrovat v session (takové aplikace zpravidla vůbec žádná cookies nepodporují).

Způsob obrany

Jediná možnost je zaznamenávat IP adresy, ze kterých jdou pokusy o přihlášení, a pokud v daném časovém intervalu je dosaženo x pokusů o přihlášení, další požadavky z této adresy ignorovat.

V globálních předvolbách v souboru global.php jsou tři konstanty:

• MAX_LOGIN_ATTEMPTS - počet možných pokusů (výchozí hodnota 5)
• CHECK_LOGIN_INTERVAL - časový interval v sekundách, ve kterém se pokusy hledají (výchozí hodnota 120)
• BLACKLIST_EXPIRATION - doba v sekundách po kterou je IP adresa držena v seznamu nežádoucích adres (výchozí hodnota 1800)

Výpis pokusů o přihlášení můžete zobrazit pomocí funkce Audit přihlášení.

Interní kontroly

Kontrolní mechanismus předchází problémům, které se mohou vyskytnout hlavně při aktualizaci instalací WTD – potenciální nekonzistence mezi strukturou databáze a uloženými daty a PHP skripty, které jsou instalovány.

Teoreticky může dojít např. k následujícím chybovým stavům:

• Chybí některá tabulka vyžadovaná pro funkci některé části
• Struktura tabulek neodpovídá instalované verzi skriptů
• Datové typy některých polí neodpovídají instalované verzi skriptů
• Data v "pomocných" tabulkách neodpovídají verzi skriptů nebo nejsou kompletní

Mechanismus řešení je následující:

Speciální skript umístěný do administrační části obsahuje kontroly na strukturu databáze a dalších uvedených potenciálních problémů. Kontrola vychází ze souboru dbcheck.xml, který obsahuje ve formátu XML popis struktury databáze WTD a všech aktuálně šířených modulů.

Tento skript se spouští při přihlašování do redakčního rozhraní v případě, že se přihlašuje administrátor WTD.

Pokud skript nalezne nějakou nekonzistenci, před zobrazením redakčního rozhraní se zobrazí údaj o tom, že byla nalezena nekonzistence, to se zároveň zapíše do logu WTD.

Tímto postupem se odhalí

• Chybějící tabulky
• Chybějící pole nebo naopak pole, která jsou navíc
• Chybějící povinné záznamy v tabulkách

V globálních předvolbách global.php je konstanta CHECK_WTD_VERSION, která určuje, zda se tato kontrola spouští při přihlašování, výchozí hodnota je true. Po instalaci a každé změně je doporučeno ponechat tuto hodnotu na true, v provozu, kdy se na serveru mění pouze data, je možné tuto konstantu změnit na false.

Po úspěšném přihlášení administrátora je uživatel přesměrován na kontrolní skript. Ten provádí kontrolu, pokud nenalezne žádnou chybu, přesměruje se dále na redakční rozhraní, pokud chybu nalezne, vypíše hlášení "Byly nalezeny nekonzistence v databázových strukturách, více informací v logu aplikace" a vedle toho odkaz pro vstup do redakčního rozhraní.

Některá doporučení pro zabezpečení

Pro instalaci jsou doporučena následující možná bezpečnostní opatření na úrovni systému (samozřejmě kromě standardní bezpečnostní údržby serveru zahrnující blokování portů nesouvisejících s provozem webu apod.):

• Nastavit pro přístup do administračního rozhraní (fyzicky application) přístup pouze z vybraných IP adres
• Nastavit virtuální adresář s administračním rozhraním (fyzicky application) případně na přístup pouze přes protokol https
• Filtrovat pro protokol https na firewallu provoz pro pouze zvolený rozsah IP adres
• Zvolit pro tento adresář takové virtuální jméno, které nelze snadno uhodnout (konfiguruje se jednak na úrovni www serveru, jednak v konfiguračním souboru global.php)

Po přechodu do ostrého provozu zvolit vhodnou úroveň chybových hlášení v PHP skriptech (v konfiguračním souboru PHP i v konfiguračním souboru WebToDate), která bude zabraňovat výpisu nežádoucích informací v případě chybových stavů (např. fyzické cesty k adresářům apod.).

Na úrovni konfigurace WebToDate pak v konfiguračním souboru global.php nastavit dle dokumentace automatickou správu blacklistu přihlašování dle IP adres, což je funkce bránící slovníkovým útokům na přihlašovací stránku (viz Interní bezpečnostní funkce).