Zápis a čtení z databáze pomocí UTF-8-unicode

Voláš i něco takového?

Martin Joneš:
Kódování databáze není až tak podstatné, důležité jsou tři věci:
1. V jakém kódování o sobě stránka říká, že je (hlavička Content-Type),
2. v jakém kódování je skutečně kód (tj. kódování PHP souboru) a
3. komunikační kódování s databází, které se nastavuje tím set_charset.

Všechno by mělo být stejné.

Pokud jsou špatně jen texty z databáze, jsou nejpravděpodobnější dvě možnosti:
1. Buď bylo špatně kódování na vstupu, tj. texty byly už vložené se špatným kódováním.
To se pozná tak, že ty texty budou špatně i při pohledu přímo na data např. v phpMyAdmin. Je to ta horší možnost, protože to pak znamená, že se musí všechno znovu vložit (popř. všechno projít a opravit).

2. Nebo je špatně nastavené komunikační kódování s databází. (Při pohledu např. v phpMyAdmin jsou texty v databázi vidět správně.)
To je lepší varianta, stačí nastavit správné kódování a mělo by to fungovat.

Martin Joneš:
A [#2] jsi četl? Protože github v tom tvém kódu žádné nastavení kódování pro komunikaci s databází nenašel!

Na konec config.php přidej

Martin Joneš:
„upravil jsem na mysqli_set_charset($db,"utf8");, což "funguje" (očividně to nemělo rádo mezeru)“
Očividně ta mezera to nebyla (můžete se přesvědčit sám). mysqli_set_charset($db, "utf8"); funguje korektně i třeba se dvěma mezerami mezi parametry. Spíše bych to tipoval na zapomenuté uvozovky nebo jinou syntaktickou chybu.

V souboru login.php máte BOM znaky,
Proč je každá tabulka v databázi s jiným porovnáním?
Problém s diakritikou nevidím žádný, smajlíky si musíte vyhodnotit převedením (pokud je chcete mít zobrazené jako obrázky).

BOM znaky umí i znefunkčnit php kód.
Můžete ještě nastavit interní kódování na mb_internal_encoding("UTF-8"); v souboru config.php

Soubor config.php načítáš v každém skriptu, index.php jen když jej zavoláš.

No z mého pohledu je to nastavení chování systému. Kde jinde by mělo být nastavení, když ne v konfiguračním souboru. Ale pokud to vyhovuje jinak a budeš se s tím v budoucnu dobře vyrovnávat, pak je to na tobě.

Martin Joneš:
github.com/jondycz/Illimis-Project/blob/master/template/default/articles.php
Přesto že pracuješ s multibytovým kódováním, nepoužíváš pro to určené funkce. Například místo strlen bys měl používat mb_strlen a další. Je možné, že tyto funkce ti rozbíjejí kódování. I když dle mých zkušeností, to nebývá až tak razantní, ale možné to je. Zkus v tom souboru zakomentovat na chvíli řádky 100-104 a vypisovat data tak, jak ti je dodala databáze. (Pokud jsi soubor lokálně měnil, tak si uprav podle toho čísla řádků.)

„Ostatní jsou příkladem špatného zápisu přes požadavek POST illimis-project.tk/articles“
Ostatními se prozatím nemusíš zabývat. Důležité je teď umět správně vypsat správně uložená data.

Keeehi:
Na stránce illimis-project.tk/article?emojis je přímý výpis obsahu databáze.

Jak je vidět, nejsou znaky převedeny správně. Spodní text je vložen přímo do zdrojového kódu tak jak je v databázi.

Martin Joneš:
Nevím, co našel Lonanek, ale ano, máš tam bezpečnostní díru, kvůli které může kdokoli i bez přihlášení přidávat články. Stačí jen poslat správný požadavek. Celý exploit může vypadat takto:

Problém, který jsem našel já je v souboru github.com/jondycz/Illimis-Project/blob/d21194b5fa22e370cefd3d8459419a1522a2ff4a/check.php. Za funkcí header na řádku 14 musí následovat volání exit();. Protože funkce header sice odešle prohlížeči hlavičku o přesměrování, běh scriptu ale neukončuje! Proto se script provede (vloží se článek) a pak se "provede" přesměrování.

Martin Joneš:
„Em.. celkem se bojím. Jak je možný, že se obsah stránky mění?“
Není se čeho bát, jen jsi na "správném" hostingu. Není to přes žádnou bezpečnostní chybu, nejsem ani hacker ani škodolíbek.

Problém je v kódování uložených (ukládaných) dat. Veškeré nastavení komunikace je správné => UTF-8.

Martin Joneš:
„Ale jak se mu povedlo editovat zdroják?“
To nevím, nejsem on. Buď uhodnul tvoje heslo, nebo se tam dostal jinak. Pokud neopravíš tu chybu co jsem popsal v [#22], tak věřím, že bych ti dokázal demonstrovat, že tam máš i nezabezpečený upload souborů => měl bych být schpen tam nahrát jakýkoli soubor. Když tam nahraji php script, můžu si už pak prakticky dělat co chci. Pomocí toho scriptu pak klidně mohu měnit zdrojové kódy jiných scriptů atd. :)
Ode mě se nemusíš bát žádných devastujících útoků (ono je to totiž nelegální) spíš chybu najdu, ověřím a jak sám vidíš, ještě ti napíšu řešení, jak ji opravit.

„Voláním exit se ten exploit, který jsi našel ty řeší?“
Ano. Exit ihned ukončí běh scriptu, a tak se už nevykonají ty následující příkazy pro přidání řádku do databáze. To co dělá Lonanek to samozřejmě neřeší.

Martin Joneš:
„Takže ty jsi taky na endoře“
Mám tam trošku jiná práva.

Keeehi:
„To co dělá Lonanek to samozřejmě neřeší.“
To není bezpečnostní chybou. Jak jsem naznačil výše.

Martin Joneš:
„Za co všechno mám tedy dávat exit();?“
Logicky přece tam, kam patří. Co jsi chtěl v té části udělat? Přesměrovat a ukončit provádění scriptu. Funkce header neukončuje provádění scriptu, proto to musíš udělat příkazem exit();


Když už jsem u toho, tak ti popíšu kde je probém u
github.com/jondycz/Illimis-Project/blob/d21194b5fa22e370cefd3d8459419a1522a2ff4a/administrator/pages/tplinstaller.php
1) řádek 21 - mimetype je informace, kterou posílá prohlížeč. Já jako útočník mohu tedy klidně poslat php soubor a k tomu přidat informaci, že to je zip soubor. V důsledku je tedy hodnota v $_FILES["zip_file"]["type"] úplně zbytečná. Jelikož ji může kdokoli jakkoli měnit, nedá se k ničemu rozumnému použít.
2) řádek 27 - tady je to úplně triviální svůj soubor pojmenuji exploit.zip.php. Přes tvojí podmínku to projde, jelikož "zip" je za první tečkou. Ovšem pořád to je PHP soubor končící .php, takže ho server klidně spustí.