Názor k článku Na podceňovanou hrozbu SQL injection doplácí i řada českých webů od Karel - Teď se ztrácím. 1. Každý uživatel se musí přihlásit...

Teď se ztrácím.

1. Každý uživatel se musí přihlásit k databázi. Buďto pomocí SQL klienta (jen hypotetická možnost, DB server si povídá jen s několika málo IP adresami) nebo prostřednictvím webové aplikace. V každém případě zadané přihlašovací údaje slouží k přihlášení k DB serveru. Tedy ne že by se webová aplikace přihlásila sama jako superuser a pak ověřovala údaje.

2. Jakmile jste přihlášení pomoci SQL klienta, můžete si spustit co chcete. Nastavení práv v DB ohlídá na co přístup máte a na co nikoliv. Stejně tak jakmile se přihlásíte přes webovou aplikaci, můžete pomocí SQL injection (nedělám si iluze, že by naše webová aplikace byla 100% bullet proof) spoštět taky prakticky jakékoliv SQL příkazy. Ale opět vás ohlídá nastavení práv v DB serveru.

Jak to tak po sobě čtu, možná už vím kde je zakopán pes. Výrazem "dělat si tam co chce a číst co chce" jsem mínil "pokusit se dělat si tam co chce a číst co chce, ale DB server mu dovolí jen to, na co má práva". Jinak řečeno, propašování SQL příkazu až na server nepředstavuje žádné vážné bezpečnostní riziko, protože vás vždy bude kontrolovat samotný DB server, který to umí mnohem lépe než webová aplikace.

Každopádně se vzdalujeme od toho, co jsem napadal - tvrdím (v rozporu s autorem článku), že prolomení webového rozhraní skrze SQL injection nemusí znamenat prolomení bezpečnosti celé aplikace.

Nepochybuji o tom, že SQL injection je praktický problém s dopadem na každého z nás. Kdybych měl však připodobnit tento článek k něčemu, co bude možná více srozumitelné, přirovnal bych webovou aplikaci k shellu, pomocí kterého uživatelé spouští své příkazy. Tento shell běží obvykle pod rootem. Článek tvrdí, že proto by autoři shellu měli ošetřovat jaké příkazy dovolí spustit a bránili se vynalézavosti uživatelů. A já mu oponuji tím, že dalším řešením je, aby ten shell vůbec neběžel s rootovskými právy.