Cross-site scripting, označovaný obvykle zkratkou XSS, patří k nejznámějším útokům vůbec. Ačkoliv o něm již bylo napsáno mnoho, je XSS zranitelnost i nadále jednou z nejčastějších chyb současných webových aplikací. Není tedy od věci si jej připomenout i zde.
Při práci se sessions si mezi sebou server a klient neustále vyměňují SID. Jedná se o náhodně vygenerovaný token, podle kterého si server páruje dohromady jednotlivé požadavky konkrétního návštěvníka. Kdo zná SID, ten má přístup i k celé příslušné session.
Jedním z nejrozšířenějších omylů mezi pokročilejšími PHP programátory je představa, že model v MVC je vlastně jenom databáze plus nějaké ORM, které v ní umožňuje číst, zapisovat a mazat. To je ale velké nepochopení. Model není jen datový, ale zejména funkční základ celé aplikace.
Další ze základních konfiguračních direktiv je include_path.
Slouží k nastavení základních cest, ve kterých se mají hledat soubory
otevírané pomocí include a jemu podobných konstruktů a
funkcí. V článku popisuji svůj pohled na její vhodné využití, zejména
s ohledem na přenositelnost aplikace mezi různými servery.
V druhém díle přehledu základních konfiguračních direktiv a jejich vhodných hodnot se zastavím u těch, které ovlivňují includování skriptů či otevírání vzdálených souborů určených pomocí URL. Raději připomínám, že svá doporučená nastavení odvozuji zejména od požadavků na bezpečnost, přenositelnost aplikace mezi servery a budoucí vývoj PHP.
Dneska se mě ve škole na semináři tázal jeden student, jakou bych doporučoval optimální konfiguraci PHP. Na to samozřejmě neexistuje žádná jednoznačná správná odpověď. Hodně parametrů je závislých na konkrétní aplikaci. Co je někde klíčovou výhodou, může jinde škodit. U některých direktiv se ale myslím dá říci, které jejich nastavení je nejvhodnější.
Pokud máte hesla v aplikaci uložená v hashované podobě, útočník, který se dostane do databáze, nevidí jejich původní plaintextové verze. Může ale použít několik metod, jak toto opatření oslabit. Bezpečnost uložených hesel se pro takové případy dá zvýšit takzvaným solením.
Jednocestných hashovacích funkcí existuje celá řada. Které z nich jsou pro účely ukládání hesel do databáze vhodné? A které jsou naopak nevhodné či dokonce nebezpečné? Jak se vypořádat se změnou použitého algoritmu za běhu aplikace?
Přihlášení pomocí uživatelského jména a hesla je nejčastějším způsobem ověření identity uživatele. Hesla jsou kritickým prvkem aplikace a je nutné jim proto věnovat zvláštní péči. Základním pravidlem je ukládat hesla do databáze v hashované podobě.
Co vlastně očekáváme od knihoven týkajících se jak autentizace, tak i dalších úzce souvisejících věcí? Nadále budeme nejčastěji předpokládat klasický případ přihlášení pomocí uživatelského jména a hesla, uchovávání uživatelských dat v databázi, využití formulářové autentizace a vázání přihlášení na session. K jiným variantám se dostaneme později.
