Nette, dibi, spatne escapovani - jak tomuto zamezit?

Zdravim,
pouzivam nette s dibi a mam takovej problem, kdyz pri hledani zada uzivatel znamenko: " tak web spadne na SQL, duvodem je, ze se vygeneruje SQL takto:
COLLATE utf8_general_ci LIKE '%'%' , 80, 0)+ IF(`c_producers.name` COLLATE utf8_general_ci LIKE '% ' %' ,240, 0)

zapis v kodu vypada takto:

$this->resultForPrices = \dibi::query('SELECT DISTINCT [c_products].price, [c_products].[id] %sql', $this->fields
, 'FROM %sql', $this->tables
, 'WHERE %and', $w
, 'GROUP BY [c_products].[id] '
, (!empty($this->having) ? 'HAVING %and' : '')
, (!empty($this->having) ? $this->having : '')
, ' ORDER BY [c_products].price DESC'
, ($this->limit > 0) ? ' LIMIT '.$this->limit : '');

Má někdo tip čím to může být a jak tomuto zamezit?

Díky

Môj tip je prestať používať DIBI :)

Původně odeslal Gavrilo ↪

Môj tip je prestať používať DIBI :)

+1, bohuzel se jedna o né zcela muj projekt, znate to... Kdyz uz jsme u toho, co poradite za abstraktni knihovnu k databazim? Osobne mam napsanou svoji vlastni, ale pro inspiraci nebo rozsireni by me zajimalo kdo pouziva :-)

Původně odeslal Tofa ↪

+1, bohuzel se jedna o né zcela muj projekt, znate to... Kdyz uz jsme u toho, co poradite za abstraktni knihovnu k databazim? Osobne mam napsanou svoji vlastni, ale pro inspiraci nebo rozsireni by me zajimalo kdo pouziva :-)

Jednoznačne https://nextras.org/ reálne nemá zmysel použivať niečo iné... Ak ide o menší projekt Nette Database

PS: Ani doctrine nie trust me :)

Původně odeslal Gavrilo ↪

Jednoznačne https://nextras.org/ reálne nemá zmysel použivať niečo iné... Ak ide o menší projekt Nette Database

PS: Ani doctrine nie trust me :)

Díky za tip, jedna se o vetsi projekt ale mrknu se na to s ohledem na jine projekty :)

Původně odeslal Tofa ↪

+1, bohuzel se jedna o né zcela muj projekt, znate to... Kdyz uz jsme u toho, co poradite za abstraktni knihovnu k databazim? Osobne mam napsanou svoji vlastni, ale pro inspiraci nebo rozsireni by me zajimalo kdo pouziva :-)

Nejlepší je klasické PDO.

Následně lze použit Illuminate DB (používá se v Laravelu) - https://github.com/illuminate/database

Co se týče Nette a jeho součásti (dibi atd) - ty věci tvoří pár lidí a zbytek se veze, takže výsledek je o ničem a celkový vývoj nette je spíše hobby než vývoj frameworku.

Původně odeslal ItSnowsInHellAgain ↪

Nejlepší je klasické PDO.

Následně lze použit Illuminate DB (používá se v Laravelu) - https://github.com/illuminate/database

Co se týče Nette a jeho součásti (dibi atd) - ty věci tvoří pár lidí a zbytek se veze, takže výsledek je o ničem a celkový vývoj nette je spíše hobby než vývoj frameworku.

Díky za info, na svych vecech nette nepouzivam, prave naopak doopravdy pracuji na vlastnim frameworku, ktery je spise inspirovany Zend frameworkem, ktery byl prvnim frameworkem se kterym jsem pracoval. Bohuzel vetsina cizich projektu ktere se mi dostanou pod ruku ze je potreba neco upravit je nette nebo dokonce wordpress...

Původně odeslal ItSnowsInHellAgain ↪

Nejlepší je klasické PDO.

Následně lze použit Illuminate DB (používá se v Laravelu) - https://github.com/illuminate/database

Co se týče Nette a jeho součásti (dibi atd) - ty věci tvoří pár lidí a zbytek se veze, takže výsledek je o ničem a celkový vývoj nette je spíše hobby než vývoj frameworku.

Kým sa niečo také opovážiš povedať refreshni si dáta prosím ťa ;)

Původně odeslal Gavrilo ↪

Kým sa niečo také opovážiš povedať refreshni si dáta prosím ťa ;)

Pracoval jsem s velkým množstvím frameworků a s různými systémy.

Mohu v klidu říct, že Nette je prostě hoby framework postaven pro programátory, kteří mají problém s angličtinou a hledají jednoduché řešení pro tvorbu php projektů.

Původně odeslal ItSnowsInHellAgain ↪

Pracoval jsem s velkým množstvím frameworků a s různými systémy.

Mohu v klidu říct, že Nette je prostě hoby framework postaven pro programátory, kteří mají problém s angličtinou a hledají jednoduché řešení pro tvorbu php projektů.

Ale použít se v pohodě dá... inspirací může být slevomat nebo csfd. ;-) Ale použít mezinárodní framework do sebe také něco má. ;-)

Nemyslím si, že chyba je v tom kódu co jste uvedl. Tam žádné LIKE přímo zadané není, musí se to plnit a ošetřovat ještě někde jinde.

Původně odeslal navay ↪

Nemyslím si, že chyba je v tom kódu co jste uvedl. Tam žádné LIKE přímo zadané není, musí se to plnit a ošetřovat ještě někde jinde.

Tak tak, souhlasím. A případně co nechcete eskejpovat můžete hodit do Dibi\Literal.

Původně odeslal ViPEr*CZ* ↪

Tak tak, souhlasím. A případně co nechcete eskejpovat můžete hodit do Dibi\Literal.

Píše, že to tam zadává přímo uživatel. Takže pokud má pud sebezáchovy, tak "chce" ošetřovat vstup.

Původně odeslal navay ↪

Píše, že to tam zadává přímo uživatel. Takže pokud má pud sebezáchovy, tak "chce" ošetřovat vstup.

Přesně tak, je to z vyhledávání na webu.

prochazí to funkci:

public function getMaxPrice(){
$t = $this->getDibiResultForPrices()->fetchAll();
if(isset($t[0])){
return $t[0]->price;
}

protected function getDibiResultForPrices(){
if($this->resultForPrices === NULL){
$w = array();
foreach ($this->where as $key=>$t){

if (is_array($t) && array_key_exists(0, $t) && strpos($t[0],'variants')!==FALSE)
continue;
if (is_string($t) && strpos($t,'param')!==FALSE)
continue;
if (is_array($t) && array_key_exists(0, $t) && strpos($t[0],'price')!==FALSE)
continue;
if (is_array($t) && array_key_exists(0, $t) && strpos($t[0],'termin')!==FALSE)
continue;
// tento reset brani korektnimu vypoctu min a max price pri fulltextovem vyhledavani (v dotaze fulltextoveho vyhledavani je i vyrobce)
/*if (is_array($t) && strpos($t[0],'producer')!==FALSE)
continue;*/
if (is_array($t) && array_key_exists(0, $t) && strpos($t[0],'list')!==FALSE)
continue;
$w[$key] = $t;
}

$this->resultForPrices = \dibi::query('SELECT DISTINCT [c_products].price, [c_products].[id] %sql', $this->fields
, 'FROM %sql', $this->tables
, 'WHERE %and', $w
, 'GROUP BY [c_products].[id] '
, (!empty($this->having) ? 'HAVING %and' : '')
, (!empty($this->having) ? $this->having : '')
, ' ORDER BY [c_products].price DESC'
, ($this->limit > 0) ? ' LIMIT '.$this->limit : '');
}

return $this->resultForPrices;
}

Pak uz kod prochazi dibi:

query($args){$args=func_get_args();return$this->nativeQuery($this->translateArgs($args));}

function
nativeQuery($sql){$this->connected||$this->connect();dibi::$sql=$sql;$event=$this->onEvent?new
DibiEvent($this,DibiEvent::QUERY,$sql):NULL;try{$r es=$this->driver->query($sql);}catch(DibiException$e){$event&&$th is->onEvent($event->done($e));throw$e;}if($res){$res=$this->createResultSet($res);}else{$res=$this->driver->getAffectedRows();}$event&&$this->onEvent($event->done($res));return$res;}

Bohuzel ja v tom nic nevidim, co by mohlo mrvit dvojite uvozovky, jednoduche uvozovky query projdou.

// tento reset brani korektnimu vypoctu min a max price pri fulltextovem vyhledavani (v dotaze fulltextoveho vyhledavani je i vyrobce)
/*if (is_array($t) && strpos($t[0],'producer')!==FALSE)
continue;*/
Co se stane, když odkomentujete tuhle část a zkusíte to s těma dvojtýma uvozovkama?

Lepší by bylo, kdybyste poslal přesnou chybovou hlášku.

Obecně si nemyslím, že chyba je v Dibi samotné, ta by se s dvojitou uvozovkou na vstupu normálně vyrovnala. Tady bude problém v tom, jak se sestavuje a plní daty ten SQL dotaz, protože tam se dá napáchat dost škody. Tipuji, že to nemusí být vůbec špatným escapováním dvojitých uvozovek, jak se na první pohled zdá (ty dvojité uvozovky by se tam za normálních okolností prostě objevily jako eskejpované, to by žádnou škodu neudělalo), ale prostě jen tím, že v těch LIKE měl navazovat další SQL řetezec, který z nějakého důvodu nebyl přidán nebo bylo na vstupu něco neočekávaného (což předpokládám mají ošetřovat ty podmínky v getDibiResultForPrices).

Taky bych si zkusil vypsat, co přesně vychází po naplnění

PHP kód:

$w[$key] = $t; 


z pole $w.

Původně odeslal navay ↪

// tento reset brani korektnimu vypoctu min a max price pri fulltextovem vyhledavani (v dotaze fulltextoveho vyhledavani je i vyrobce)
/*if (is_array($t) && strpos($t[0],'producer')!==FALSE)
continue;*/
Co se stane, když odkomentujete tuhle část a zkusíte to s těma dvojtýma uvozovkama?

Lepší by bylo, kdybyste poslal přesnou chybovou hlášku.

Obecně si nemyslím, že chyba je v Dibi samotné, ta by se s dvojitou uvozovkou na vstupu normálně vyrovnala. Tady bude problém v tom, jak se sestavuje a plní daty ten SQL dotaz, protože tam se dá napáchat dost škody. Tipuji, že to nemusí být vůbec špatným escapováním dvojitých uvozovek, jak se na první pohled zdá (ty dvojité uvozovky by se tam za normálních okolností prostě objevily jako eskejpované, to by žádnou škodu neudělalo), ale prostě jen tím, že v těch LIKE měl navazovat další SQL řetezec, který z nějakého důvodu nebyl přidán nebo bylo na vstupu něco neočekávaného (což předpokládám mají ošetřovat ty podmínky v getDibiResultForPrices).

Taky bych si zkusil vypsat, co přesně vychází po naplnění

PHP kód:

$w[$key] = $t; 


z pole $w.

$w =

Array
(
[c_products.deleted] => 0
[c_categories.active] => 1
[0] => c_products.active = 1
)

Odkomentovano:

/*if (is_array($t) && strpos($t[0],'producer')!==FALSE)
continue;*/

Vyhledavany string: neco "

Chybova hlaska ke stazeni zde:
Webshare.cz - moderní úložiště pro Vaše data

1) Z té odkázané chybové stránky je vidět, že Dibi tam dvojité uvozovky normálně eskejpuje zpětným lomítkem.

2)

Kód:

Array
(
[c_products.deleted] => 0
[c_categories.active] => 1
[0] => c_products.active = 1
)

To vám nepříjde divné? Buď jsou špatně ty dvě první položky, nebo ta třetí. Další věc je, že ty první dva názvy sloupců (c_products.deleted a c_categories.active) se vůbec neobjevují v tom problematickém SQL dotazu.

3) Pořád jste nenapsal tu část kódu, která a) tvoří a b) plní tu část s LIKE dotazem, odkud je ten SQL dotaz poprvé rozbitý. Tedy něco s modifikátory %~like~, %like~, %~like.