SQL Injection - moje řešení - prolomíte jej? – PHP – Fórum – Programujte.com

Ahoj všem,

rád bych znal názor zkušenějších na následující problematiku:

1. Programuji webovou aplikaci větších rozměrů. Je zde kladen velký důraz na bezpečnost celé aplikace a nyní jsem ve fázi, kdy řeším SQL injection - tedy ošetření formulářů a URL adres.

2. Ze specifických důvodů (nebudu rozvádět) musím použít v několika případech celé části SQL dotazu v proměnných, které předávám přes URL - např. výsledná $_GET['page'] = "p1 ='0' OR p1 = '1' "; - tato proměnná se následně vkládá přímo do SQL dotazu. Nemohu tedy použít na obrazu před SQL injekcí klasické opatření nahrazením proměnných např. otazníkem a jejich vložení do dotazu až následně. Stejnětak nemohu použít escapování (a ani nechci, je to starý a děravý způsob). Vymyslel jsem následující bezpečnostní řešení a rád bych znal vaše názory na něj, popř. jak ho prolomit :D

a) Ošetření proměnných přes URL: Vycházím z faktu, že každá proměnná předávaná URL adrese, ve které je potřeba použít část SQL dotazu má předem známé hodnoty (to je fakt v této aplikaci). Tzn. buď A nebo B nebo C. Proto v rámci zabezpečení nebudu předávat do SQL dotazu přímo proměnnou $_GET['x'], ale nejprve ji proženu přes podmínku if $_['x'] = výraz A nebo výraz B nebo výraz C - jen pokud je splněna tato podmínka, tak definuji proměnnou A, B nebo C a až tuto použiji v samotném SQL dotazu. Tím předpokládám, že URL adresy budou zcela neprůstřelné a 100% bezpečné. 

b) Ošetření formulářů (např. přihlášení apod): Použít escapování se mi nezdá bezpečné, umím jej prolomit :). První věc - pro psaný text používám TinyMCE a zde vnímám současné zabezpečení TEXTAREA vstupu uživatele jako dobré. Zbývá ošetřit prvky typu INPUT a zde zcela striktně proženu nejprve každou hodnotu z formuláře přes kontrolu tzn. ze speciálních znaků povolím pouze ampersant (ten se někdy používá v názvech např. hotel & restaurant), zbytek ze vstupu zcela odstraním (tedy veškeré druhy uvozovek, rovnítka, apod. a také slova jako DELETE či TRUNCATE apod.) a až teprve potom vložím výsledek do druhé proměnné a tu následně použiji v SQL dotazu... Prolomíte?

Díky všem za odpovědi. 

#1 MartinB84
Použij prepared statements a máš klid. Je to dnes standardní způsob ošetření SQL.

#2 Kit
Jak můžu použít prepare statements, když tu jasně píšu, že do proměnné z URL musím bohužel nacpat celý kus SQL dotazu... A druhá věc - zajímá mě názor na mé řešení a ne jiné alternativy - ve standardní aplikaci bych samozřejmě prepared statements použil..

#3 MartinB84
Slušněji se to fakt říct nedá. Pokud ti jde o bezpečnost, tak nedělej pičoviny a udělej to pořádně. Tvůj přístup je amatérský a zcela nevhodný.

#4 ondrej39
Ale jo, všechno, co píšeš je naprostá pravda. Ale proč mi nikdo neodpovíte konkrétně? Jsem si vědom, že je to nestandardní, "amatérské" nebo říkejme tomu jak chceš, ale pojďme se chvíli bavit konkrétně:

1. Neprogramuji aplikaci pro další dynamické využití... Je to zcela unikátní a specifická záležitost.

2. V ČEM konkrétně může mé řešení aplikaci uškodit? Jedná se o problém výkonostní nebo to prolomíte nebo kde je ten problém tohoto řešení? Od diskuze jsem očekával diskuzi a ne strohé sdělení "je to amatérská pičovina". Sry.

Vsechny ty moznosti bys musel ukazat testovacim spustitelnym kodem.

a) to vypada nadejne, cisla resim cislo*1

b) nesmyslne prisne
Sql dotaz obvykle lze narusit dvema zpusoby
- zmena podminky
WHERE x=5 -- $get = "5"
WHERE x=5 OR 1=1 -- $get = "5 OR 1=1" zobrazi celou tabulku
WHERE x='5' OR '1'='1' -- $get = "5' OR '1'='1"
- ukoncenim/doplnenim dotazu a pridanim vlastniho
WHERE x=0; SELECT * FROM users -- a podobne
Cili, mimo znaky ' " ; a par dalsich je zbytecne neco zakazovat.

c) Vynechal jsi to treti zasadni cast. Zobrazovani stranky pres htmlspecialchars().

d) Vynechal jsi, jak resis UTF

e) Co htaccess a zablokovani citlivych casti php kodu?

Mimochodem, predpokladej, ze ti muze hacker zmenit cast kodu nebo session. Takze bys mel pred operaci, kterou dela admin nebo uzivatel vzdy otestovat, zda ma  tomu opravneni a zda ti nekdo nezmenil hodnotu uzivatele v session za jinou, neplatnou. Nebo tez jedno s opatreni je, po kazde sql pripojeni ukoncit, aby nemohl nic vytahovat z db. Nebo mit mit dva ruzne db uzivatele, jednoho pro overovani existence uzivatelu, pouze pristup do tabulky uzivatele a druheho, ktery muze tahat data.
A takovych vychytavek je cela rada.

"Je zde kladen velký důraz na bezpečnost celé aplikace"
"Je to zcela unikátní a specifická záležitost."
V tom pripade to udelej poradne a nezahravej si s posilanim casti sql dotazu pres $_GET.

#5 MartinB84
Amatérské řešení je to hned z několika důvodů:

Dáváš uživateli přímo možnost upravovat SQL dotazy, které následně pokládáš proti své databázi, která možná obsahuje citlivé informace

Uživateli bych umožnil vykonání ručně napsaných SQL dotazů pouze v případě, kdy bych dělal aplikaci, která slouží jako testovátko pro SQL, aplikaci, kde by se uživatel SQL učil, a napsané SQL by se prováděly na nějaké dummy databázi.

V reálném prostředí je to blbost a pokud ti přijde, že se to nedá ošetřit nijak jinak, tak se to naštěstí udělat dá. Například si zmíněné tři varianty SQL vložíš do databáze a uživatelu bude na vstupu pouze zasílat ID konkrétního záznamu, 1, 2, 3, podle něhož se sáhne do určité tabulky a vytáhne se patřičný SQL dotaz. Dotazy si tam vložíš sám, takže budeš mít 100% jistotu, že jsou správné.

Pokud někde v uživatelském rozhraní navíc budeš vypisovat například foreachem možnosti doplnění SQL například do Dropdown boxu, tak v případě, kdy do databáze přes administraci doplníš další variantu, nemusíš nikde jinde upravovat pravděpodobně nic, protože se to automaticky aktualizuje.

Vlastní ošetřování vstupů

To je v dnešní době prostě nesmysl. Buď potřebuješ ošetřit vstupy a pak použij předpřipravené SQL dotazy, které kromě toho, že SQL injection zamezí, jsou rychlejší, než kdyby sis ošetřování napsal sám, protože ty knihovny jsou napsané v C/C++ a zkompilované, php je používá pouze jako nádstavby,

Pokud problém vyřešíš navrhovaným způsobem výše, nemusíš počítat s tím, že někde budeš muset mí nějaké částečné escapování, protože buď vyescapuješ vše anebo správnou hodnotu vytáhneš z databáze na základě hodnoty z Dropdown boxu.

Pokud ti jde o bezpečnost tak, jak píšeš, zaměř se primárně na architekturu své aplikace, protože jestli řešíš věci, které řešíš, jsem si skoro jistý, že problém bude na spoustě dalších míst.