Michal Čihař - Posts tagged by phpmyadmin, page 13

Do phpMyAdmina chtějí protlačit podporu pro jeden autentizační token. Jak tato věc funguje na hardwarové úrovni nevím (má tam být nějaký autentizační kalkulátor, který na výzvu vygeneruje nějakou unikátní odpověď), ale docela mě pobavil přístup k bezpečnosti softwarového řešení okolo. Celá popisovaná věc se jmenuje Swekey a stojí za ním firma Musbe, založená jen kvůli tomuto zařízení ( to develop and market an innovative authentication technology ).

Token se strká do USB (v dnešní době to asi ani jinak nejde) a celou věc obsluhuje v Linuxu jakási binárka komunikující s tokenem přes libusb. No aspoň, že to bude hnít v userspace a ne v kernelu. Bohužel pokud to chcete použít na něčem jiném než i386, máte smůlu. Protože nám se jedná o autentizaci webové aplikace, máme ještě k dispozici další binárku a to plugin do prohlížeče Firefox (pro Windows případně ještě ActiveX pro MSIE).

Když už se uživateli poštěstí toto rozběhat (a nebude řešit takové nepodstatné otázky, jako třeba: proč binárka obsluhující ten token musí používat curl?), může vyzkoušet úžasné možnosti, které nám tato autentizace skýtá. A hlavně se podívat na kód, který se o autentizaci stará, protože ten již k dispozici máme. Kromě phpMyAdmina, kde je jakási meziverze už v SVN, ještě existuje plugin pro SquirrelMail a prý i patch pro RoundCube, modul pro PAM atd.

Jak vlastně celá věc funguje?

1. Načte se ID z USB tokenu
2. Ze serveru se stáhne náhodný token (platný dvě minuty)
3. Náhodný token se nacpe do USB tokenu a ten vygeneruje OTP (jednorázové heslo)
4. ID tokenu, náhodný token a OTP se pošle na server a ten je ověří

No vypadá to celkem jednoduše, tož pojďme se podívat jak to soudruzi naimplementovali. Podotýkám, že v patchi pro phpMyAdmin, už pomaly níže popsané problémy mizí, ale za cenu víceméně kompletního přepsání kódu, jak se (ne)budou vyvíjet patche/pluginy pro ostatní programy netuším, nicméně autoři pořád někde preferují původní řešení.

Komunikace

První věc, která kohokoliv musela praštit do očí bylo použití nešifrovaného HTTP spojení při komunikaci se serverem. Což ve spojení s jednoduchým až triviální protokolem, znamená, že kdokoliv, kdo je schopný na jakýkoliv HTTP požadavek odeslat odpověď "HTTP/1.0 200 OK\n\nOK" se může stát autentizačním serverem, který autentizuje cokoliv komukoliv. Soudruzi sice v patchi pro phpMyAdmina přešli na HTTPS s ověřováním certifikátu, ale z výkonnostních důvodů jinde zůstane nadále HTTP. Vskutku inovativní řešení.

Umístění souborů

Mapování tokenů na uživatele mělo být umístěno v kořenovém adresáři phpMyAdmina a tedy přístupné přes web. Což ve spojení s předhozí zranitelností znamená, že jediná informace, kterou by případný útočník potřeboval - ID klíče, který mu dovolí přístu, může bez problémů získat napsáním správného URL.

Dočasné soubory

Protože náhodný token je platný dvě minuty, rozhodli se autoři ušetřit námahu jejich serveru s generováním a tento token cachovat. Bohužel ukládat pevně pojmenovaný soubor do adresáře /tmp není zrovna nejlepší nápad a už vůbec není dobrý nápad tento soubor vytvářet s právy 777 . Co by se asi stalo, kdyby náhodný uživatel na serveru do tohoto souboru uložil třeba nějaký film a ten se následně začal odesílat na jejich server jako náhodný token při autentizaci?

No nechtějte to

Většina zde zmíněných problémů existuje ve všech implementacích tohoto tokenu, do kterých jsem se koukal. Kromě toho každá implementace přidává spoustu unikátních programátorských chyb. Zájemcům o pobavení se doporučuji modul pro PAM, který je vlastně jen spouštěč skriptu v bashi, který volá curl a komunikuje se serverem.

Update

Při psaní tohoto článečku mě napadl ještě jeden problém, kterým to asi bude trpět, ale nechtěl jsem to psát dokud to neověřím, což se právě stalo. Přístup k tokenu z prohlížeče není pluginem nijak omezován, takže jakákoliv stránka může zjistit ID vašeho tokenu a vygenerovat si OTP heslo. No lepší podmínky pro krádež identity si už lze představit jen těžko :-).

I just commited to phpMyAdmin trunk (will be released once as 3.1) few small patches, but the change is quite important - phpMyAdmin will now default to cookie authentication method and it will not allow to login as root user without password (unless it is explicitly enabled in configuration).

Reasons for both changes are simple - most people change default authentication to cookie in production environment anyway, so why not to make it default and giving remote access to freshly installed MySQL server has been always considered a bit security issue. Well it was an user problem, but why not to prevent such issues?

Today I finally made something for phpMyAdmin :-). First I've updated Czech translation of 3.0, so it is not that behind as it used to be (only some PBXT strings are missing right now) and then I fixed some potential issues which Thijs has found (thanks to him for his great security work not only for Debian).

Later I focused a bit on demo server. As we already have new setup script from GSoC (made by Piotr Przybylski), links to setup script have been updated and I also reorganised links to all demo versions including direct login links for cookie based authentication. I hope it is now a bit easier to navigate and choose which demo version you want to test :-).

Na bezpečnostním mailing listu phpMyAdmina se objevil nějaký etický hacker a začal trochu šťourat do našeho kódu, což je jenom dobře :-). První výsledky tohoto šťourání už přinesla verze 2.11.7.1 , ale s většinou změn přijde až 2.11.8.

Kromě spousty určitě užitečných připomínek, ale přišel i s jedním kontroverzím nápadem a to znemožnit potenciálnímu útočníkovi zjistit o jakou verzi phpMyAdmina jde. Kromě toho, že samozřejmě pořád bude existovat dostatek starých verzí, které to o sobě řeknou, tak to stejně jenom zavání security by obscurity. Nicméně to ale může útočníkovi trochu zkomplikovat život. Na druhou stranu schování těchto informací je práce navíc a vynutilo by si odstranění textového ChangeLogu.

Co si o tom myslíte vy? Má smysl skrývat jakoukoliv zmínky o tom o jakou verzi se jedná (včetně například ChangeLogu) před nepřihlášeným návštěvníkem?

Objev týdne: Salamandra

phpMyAdmin si zatím drží třetí místo, které zajišťuje účast v programátorské soutěži Hackontest , která se koná koncem září v Curichu. Během 24 hodin budou tři vybrané týmy implementovat vlastnost, kterou si uživatelé budou nejvíce přát. Hlasujte tedy pro to, co vám v phpMyAdminovi nejvíce chybí. Více informací na http://www.hackontest.org .

Well I did not expect that much when MySQL offered us to piggyback on their participation in GSoC 2008, but at the end we have two projects. One is about blobstreaming which I absolutely don't know and is probably some amazing new technology :-). Marc will act as a sponsor on this together with some guys from http://www.blobstreaming.org.

The second project is setup rewrite where I will act as a mentor and Piotr Przybylski will implement it. Hopefully we will bring this to successful end and soon phpMyAdmin will bring you easier way to set up and configure it's options.

Když jsem dneska viděl anketu na rootu , na první pohled jsem si myslel, že se někdo zbláznil a dostaly se tam dva projekty na kterých dělám - Wammu a phpMyAdmin . Po bližším zkoumání se ukázalo, že tam mám jenom jeden a phpMinAdmin opravdu není phpMyAdmin, jak si zabudovaná oprava překlepů v mozku původně domyslela.

Když si vzpomenu, kolik open source projektů muselo změnit jméno kvůli podobností názvu s nějakým komerčním produktem, tak si říkám, jak by to dopadlo tady (ne že bych měl něco takového v plánu). Ale stejně by mě zajímalo kolik lidí si to splete a bude si myslet, že hlasují pro phpMyAdmina :-).

PS: Jinak samozřejmě hlasujte pro Wammu, ať taky něco vyhraju (i když vůbec netuším co že tam projekty mají vyhrát :-)).

While looking at poll about Czech open source for first time, I was surprised that two of my projects got in - phpMyAdmin and Wammu. After looking again at that page I noticed there is a typo in phpMyAdmins name, it was written as phpMinAdmin. Then I looked even more carefully and even URL it is pointing to is something different. In this time I realized that it is something completely different with just very similar name. phpMinAdmin is some minimalistic clone of phpMyAdmin, but why they could not choose a bit more different name?

PS: Anyway you can still vote for Wammu in Czech open source :-).

Well not directly, but MySQL is and they will also accept our projects. So if you are student interested in getting some money for improving free software, you're welcome to contact us. We have written down our ideas to wiki, but feel free to come with your own thought. But don't forget that deadline is this Monday!

While talking about this improving phpMyAdmin, phpMyAdmin team would also like to take part in Hackontest, so vote and suggest there features for us! If you have no idea for phpMyAdmin, Debian is also taking part there ;-).

Přestože phpMyAdmin nebyl vybrán mezi projekty účastnící se Google Summer of Code , díky kolegům z MySQL se projekty na vylepšení phpMyAdmina mohou této akce zúčastnit. Pokud tedy studujete a chcete si přes léto přivydělat peníze pomocí phpMyAdminovi, můžete inspiraci čerpat z  našich nápadů na vylepšení , nebo přijít z vlastním nápadem. Nabídka od MySQL přišla na poslední chvíli, tak se rozmýšlejte rychle, poslední šance na odeslání přihlášek do Googlu je 7. dubna.

Tým phpMyAdmina by se rád zúčastnil programátorské soutěže Hackontest , která se koná koncem září v Curichu. Během 24 hodin budou tři týmy vybrané komisí implementovat vlastnost, kterou si uživatelé budou nejvíce přát. Pokud chcete pomoci phpMyAdminovi se účastnit na této soutěži, navrhujte nebo hlasujte pro nové vlastnosti phpMyAdmina na http://www.hackontest.org .

Anglická kniha o phpMyAdminovi byla aktualizována pro současnou řadu phpMyAdmina – 2.11. Pokud vládnete angličtinou, tak pro vás může být ideálním zdrojem informací. Zakoupením této knihy přispíváte i přímo projektu phpMyAdmin! Více informací o novém vydání naleznete na stránkách vydavatelství .

Občas do databáze potřebujeme také nahrát data získaná v jiných programech. I pro tuto možnost phpMyAdmin nabízí podporu ve svém rozhraní, ale pokud budete potřebovat pracovat s většími objemy dat, je lepší použít některé nástroje pro příkazovou řádku.

Množství formátů pro import není ani zdaleka tak rozsáhlé jako u možností pro export  – phpMyAdmin podporuje import jen pro CSV, SQL a DocSQL soubory. Stejně tak jako u exportu ale máte možnost si napsat vlastní modul pro práci s vaším souborovým formátem, rozhraní pro moduly je podobné jako u  exportních modulů .

Omezení

Protože zpracování dat dochází na straně web serveru a data jsou přenášena přes HTTP, může u velkých objemů dat dojít k vypršení různých časových limitů. Limit běhu PHP (pokud to nastavení PHP umožňuje, například v safe mode to není možné) můžete nastavit pomocí proměnné $cfg['ExecTimeLimit'] . Nastavením na nulu omezení doby času běhu PHP odstraníme úplně. Nicméně pořád ještě může vypršet časový limit HTTP přenosu, který nemůžeme nijak ovlivnit.

Další omezení je velikost nahraného souboru. Toto upravují parametry upload_max_filesize a post_max_size v nastaveních PHP (soubor php.ini nebo případně .htaccess s lokálním nastavením pro některé adresáře). Oba tyto parametry omezují maximální velikost souboru, který lze na server nahrát. Vše výše zmíněné předpokládá povolení nahrávání souborů pomocí direktivy file_uploads .

Poslední omezení na které můžeme narazit je velikosti použité paměti. To je možné opět nastavit v phpMyAdminovi pomocí proměnné $cfg['MemoryLimit'] .

Jak zpracovat velké soubory

Pokud přes phpMyAdmina potřebujeme pracovat s velkými soubory, máme přes popsaná omezení několik možností.

Nejpohodlnější je nahrát soubor na server jinou cestou a v phpMyAdminovi povolit načítání souborů pro import ze serveru:

 
  $cfg['UploadDir'] = './upload';
 

Nyní nám phpMyAdmin nabídne na stránce pro import i soubory uložené v tomto adresáři a tímto se vyhneme problémům s HTTP přenosem. Ale pořád zůstávají omezení na spotřebovanou paměť a dobu běhu PHP.

Tyto omezení můžeme obejít částečným importováním souboru dokud ho nezpracujeme celý. Pokud je povolen částečný import phpMyAdmin se snaží předem detekovat situaci kdy by došlo k dosažení těchto limitů a pokud toto hrozí import se přeruší. Opětovným odesláním formuláře bude import pokračovat od poslední zpracované pozice. V případě že jsme soubor nahrávali přes HTTP musíme však soubor nahrát znovu.

Formáty dat

Pro všechny formáty je možné vybrat znakovou sadu, ve které je soubor a phpMyAdmin automaticky rozezná případnou kompresi souborů (gzip, bzip2 a zip, ale záleží na tom co vaše PHP podporuje).

SQL

SQL export asi není třeba rozebírat, jen je možné nastavit režim kompatibility, v jakém se bude dotaz provávět.

CSV

Do jednotlivých tabulek je možné nahrávat data z CSV souborů (tento import tedy funguje jen pro jednotlivé tabulky a ne pro celou databázi). U CSV importu je možné nastavit řadu parametrů určující jak je soubor formátován (oddělovače sloupců, řádků a podobně). Pokud to MySQL server povoluje, je možné také kromě parseru v phpMyAdminovi použít příkaz MySQL LOAD DATA . Tato volba je obvykle rychlejší, ale nenabízí tolik možností ovlivnění běhu a v některých konfiguracích MySQL serveru ji nelze použít.

DocSQL

Toto je dnes již poměrně historický formát pro popis tabulek a phpMyAdmin umí podle tohoto popisu tabulky vytvořit. Protože se jedná o vytváření tabulek, tento import je dostupný jen pro databázi.

Před týdnem jsme se podívali na stránku zobrazující stav serveru, ale to zdaleka není jediná možnost jak se podívat co se na serveru děje.

Probíhající SQL dotazy a jejich historie

Pokud je MySQL server hodně zatížen, může být snadné identifikovat viníka ze seznamu běžících dotazů . Pro každý dotaz zde vidíme jak dlouho běží, který uživatel ho spustil a můžeme ho také ukončit.

MySQL server uchovává historii dotazů, které nějak měnily (nebo mohly změnit) data na serveru. Tento log si můžete prohlédnout na stránce s  binárními logy . Prohledávání tohoto seznamu však může být poměrně časově náročné.

Podporovaná úložiště a jejich stav

Další zajímavou stránkou může být seznam podporovaných úložišť . Kromě jejich přehledu se zde po kliknutí na ně dozvíme i informace o jejich stavu a případně o proměnných ovlivňujících jejich chování. Nejvíce informací je v současné době dostupné pro InnoDB.

Znakové sady a porovnání

MySQL server v současné době podporuje mnoho znakových sad a pro většinu z nich i více možností porovnávání. Podrobnější informace na toto téma již přinesl článek o  problémech s češtinou . Seznam znakových sad, které podporuje váš MySQL server, naleznete na samostatné stránce . Zvýrazněná porovnání jsou výchozí pro danou znakovou sadu.

Proměnné a nastavení serveru

Proměnné a nastavení serveru je poslední část kterou si dnes projdeme. Jsou na ní vypsány všechny proměnné MySQL serveru a jejich hodnoty. Pokud se nastavení aktuálního připojení liší od globálního nastavení, je tato proměnná zvýrazněna a jsou vypsány obě hodnoty.

A nyní již můžete pomocí phpMyAdmina zjistit vše co se na vašem MySQL serveru děje a jaké možnosti má zakompilovány.

Kromě správy MySQL serveru vám phpMyAdmin nabízí i možnosti jak se dozvědět zajímavé informace o jeho stavu. Sledováním těchto informací můžete optimalizovat běh vašeho MySQL serveru.

Než se pustím do rozebírání jednotlivých informací, musím upozornit, že v MySQL u vašeho provozovatele nemusíte mít oprávnění vidět všechny tyto stránky. Veškeré tyto informace jsou obvykle dostupné jen správci serveru.

Stav serveru

Pokud chceme zjistit stav serveru, celkem logicky se podíváme na záložku nazvanou stav serveru a phpMyAdmin nás zahltí informacemi, které získal od MySQL serveru. Jak se v nich ale vyznat?

V následujících několika odstavcích si popíšeme jednotlivé položky, ale nejdříve několik obecných informací. phpMyAdmin se snaží poznat, které hodnoty jsou vyloženě špatné nebo dobré a ty barevně zvýraznit. Červené hodnoty tedy stojí za prozkoumání a ze zelených můžete mít radost, jak dobře máte MySQL server nastavený. Toto hodnocení ale vychází z průměrného používání MySQL serveru a nemusí přesně odpovídat vašemu nastavení, takže není potřeba se děsit červených čísel. Na ukázkovém serveru například najdete mnoho takových položek a to převážně z důvodu minimalizace paměťové náročnosti MySQL serveru, který tak nemůže udržovat v paměti dostatečné množství dat.

V horní části jsou souhrnné informace – celkový přenos dat a počty připojení. Tyto čísla může být zajímavé vidět, ale obvykle se zde nic zásadnějšího nedozvíme.

Hned dále je zobrazena statistika dotazů. Z té již můžeme vysledovat například převážné používání serveru. Na produkčním serveru obvykle převažují dotazy typu select , ale pravděpodobně zde najdete i vysoká čísla pro vkládání nových záznamů ( insert ), protože mnoho publikačních systémů si ukládá nějaké statistiky o přístupu uživatelů. Větší četnost jiných typů dotazů může stát za prozkoumání, jestli některá aplikace není špatně nakonfigurována.

Další tabulka obsahuje některé souhrnné statistiky SQL dotazů a pokud máme vysokou hodnotu u Slow_queries , pravděpodobně některá aplikace příliš zatěžuje MySQL server neoptimálními dotazy. O jaké dotazy se jednalo můžete zjistit zapnutím logování pomalých dotazů v konfiguraci MySQL ( log_slow_queries ).

V dalších částech najdete vypsaný stav jednotlivých subsystémů MySQL serveru a pokud najdete červená čísla, můžete si ve vedlejším sloupci přečíst doporučení, jak tuto hodnotu vylepšit. Kromě přehledu naleznete na konci některých tabulek i akce, které je možné se souvisejícím subsystémem provést, například vyprázdnit vyrovnávací paměť dotazů nebo zobrazit podřízené servery.

Při zkoumání vlivu jednotlivých aplikací na statistiky může být užitečné tyto statistiky občas vynulovat, k tomu vám pomůže odkaz v horní části stránky nebo případně odkazy pod jednotlivými sekcemi.