SQL Injection - moje řešení - prolomíte jej? – PHP – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

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

 

MartinB84
~ Anonymní uživatel
3 příspěvky
28. 2. 2016   #1
-
0
-

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. 

Nahlásit jako SPAM
IP: 78.102.116.–
Kit+15
Guru
28. 2. 2016   #2
-
0
-

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

Nahlásit jako SPAM
IP: 194.228.13.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
MartinB84
~ Anonymní uživatel
3 příspěvky
28. 2. 2016   #3
-
-2
-
Mimo téma

#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..

Nahlásit jako SPAM
IP: 78.102.116.–
ondrej39+1
Věrný člen
28. 2. 2016   #4
-
+1
-
Zajímavé

#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ý.

Nahlásit jako SPAM
IP: 79.141.243.–
Inject all the dependencies!
MartinB84
~ Anonymní uživatel
3 příspěvky
28. 2. 2016   #5
-
0
-

#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.

Nahlásit jako SPAM
IP: 78.102.116.–
peter
~ Anonymní uživatel
4014 příspěvků
29. 2. 2016   #6
-
0
-

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.

Nahlásit jako SPAM
IP: 2001:718:2601:26c:d1d3:8c...–
ondrej39+1
Věrný člen
29. 2. 2016   #7
-
0
-

#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.

Nahlásit jako SPAM
IP: 78.156.159.–
Inject all the dependencies!
Zjistit počet nových příspěvků

Přidej příspěvek

Toto téma je starší jak čtvrt roku – přidej svůj příspěvek jen tehdy, máš-li k tématu opravdu co říct!

Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 5 hostů

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032024 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý