WebToDate/Referenční/Bezpečnost

Autentifikace

Publikační systém umožňuje v konfiguračním souboru nastavit jeden ze tří způsobů přihlašování uživatelů (a způsob autentifikace) do redakční části systému:

• Autentifikace formulářem, hesla se ukládají do databáze v textové podobě
• Autentifikace formulářem, hesla se ukládají do databáze zakódované pomocí MD5
• Ukládání hesel ve formátu MD5 se zapíná v konfiguračním souboru global.php pomocí konstanty 'USEMD5PASSWORDS':

define( 'USEMD5PASSWORDS', true );

• http autentifikace

Třetí možnost znamená, že v databázi se hesla neukládají, vlastní autentifikaci provádí operační systém nebo web server (např. web server Apache pomocí souboru .htaccess). Ve verzi pro Windows je navíc implementována možnost vyhledání uživatele podle loginu v NT doméně/Active Directory – viz následující obrázek.

Tato volba je vhodná zejména pro použití WebToDate na správu intranetového serveru.

Http autentifikace se zapíná v konfiguračním souboru pomocí konstanty

	define('INTEGAUTHENT', true);

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)
• MIN_LOGIN_LENGTH - časový interval v sekundách, ve kterém se pokusy hledají (výchozí hodnota 120)
• CHECK_LOGIN_INTERVAL - 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).