Nevzdáváme to - nová burza bitcoinů

[v.sp]

1) vsechny volani SQL by musely jit pres prepared statements. To je nutnost. A neexistuje zadny relevantni duvod proc prepared statements nepouzivat. To ze musite napsat o 2 radky navic neni zadny duvod. Vysledkem by bylo snizeni rizika SQL injection temer na nulu.

Osobní názor
 - jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)
 - v zásadě jen řeši obrovskou neschopnost programátorů ošetřit si apostrov (a mysql programátorů ten správný apostrof v tom textu najít)

Ale nemám s tím problém, používám vlastní API, které umí obojí.

Prepared statement pomalejší? Cože?? Jako DBA ženu dlouhým klackem každého, kdo mi do OLTP systému nebude proměnné bindovat.
Neschopnost ošetřit apostrofy... OMG. Takže budu řešit všechny možné kombinace, escapování, nový syntaxtický cukr co chodí s každou verzí... A nebo tu proměnnou prostě nabinduju jako řetězec, poběží mi to rychleji, nezaberu místo v shared poolu (či jak se to jmenuje zrovna v mysql), nemusím pokaždé hard parsovat... a jako bonus na 100% zabráním SQL injection?

Dodneška jsem nechápal, proč někdo může mít s SQL injection vůbec problémy. Už chápat začínám.

[Reklama]

[Filip Jirsák]

Co že to?

prepared statements jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)

Jaký ping-pong? Víte, co jsou prepared statements? Víte, jak komunikuje knihovna v PHP s MySQL serverem? Když máte dotaz s vloženými daty, ten se pošle na server, server se podívá do cache, zjistí, že tam dotaz ještě není. Rozparsuje ho, vytvoří exekuční plán, provede a vrátí výsledek. Při použití prepared statements se dotaz s balíčkem dat pošle na server, server se podívá do cache, vytáhne z ní už hotový exekuční plán pro daný příkaz, provede a vrátí výsledek. Síťová komunikace je pořád stejná, akorát pro opakované dotazy jste serveru ušetřil parsování dotazu a sestavování exekučního plánu.

prepared statements v zásadě jen řeši obrovskou neschopnost programátorů ošetřit si apostrov (a mysql programátorů ten správný apostrof v tom textu najít)

Nikoli, prepared statements jsou už dávno základní režim, data vložená přímo do SQL příkazu je jen pomůcka určená pro rychlé testování a prototypování. Pokud si myslíte, že jediným problematickým znakem je apostrof, pak ta aplikace musí vypadat… Jinak tipnul bych si, že spousta SQL injection vznikne tak, že programátor si ošetří „apostrof“, ale pak se ukáže, že se ošetřuje dvakrát, tak jedno ošetření odstraní – jenže pro jinou větev programu bylo to odstraněné ošetření jediným ošetřením, a SQL injection je otevřené.

[Ondřej Novák]

Co že to?

prepared statements jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)

RTFM

Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement.

[Makovec]

1) vsechny volani SQL by musely jit pres prepared statements. To je nutnost. A neexistuje zadny relevantni duvod proc prepared statements nepouzivat. To ze musite napsat o 2 radky navic neni zadny duvod. Vysledkem by bylo snizeni rizika SQL injection temer na nulu.

Osobní názor
 - jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)
 - v zásadě jen řeši obrovskou neschopnost programátorů ošetřit si apostrov (a mysql programátorů ten správný apostrof v tom textu najít)

Ale nemám s tím problém, používám vlastní API, které umí obojí.

Myslím že toto v kostce shrnuje váš problém. Vy neumíte vidět koncepty a souvislosti. Pro křovíčko jednotlivých nastavení a drobností syntaxe nevidíte les. Programování se vám rozpadá do jednotlivostí, stejně jako bezpečnost. Chcete výčty tohle, tohle, tohle, tohle, a nezajímá vás že to všechno tvoří jeden celek který je víc než seznam částí.

Je to bohužel něco k čemu celé PHP mocně svádí, a čemu snadno začínající programátoři podléhají. Představě toho že něco budovat je seznam znalostí konfigurací, metod a work-aroundů, izolovaných receptů.

Už vám to tu řeklo dost lidí různými způsoby, ale vy to nechcete chápat, připadá vám to že si děláme poťouchlou legraci. Neděláme.

[v.sp]

Takže nakonec svěříte ochranu serveru jednomu člověku do ruky. Super bezpečnost pane bezpečáku!

Jak jsem již napsal o příspěvek výše, ten klíč může chtít PIN/heslo. Dokonce, pokud z toho chcete mít extra vopruz s nočním vstáváním, tak každý může mít jen část toho PINu nebo hesla a můžete se tam sejít třeba ve třech a pak hodit švédskou trojku pod klimoškou.

Hele, Nováku. On to Rumajz vystih úplně přesně - tobě bych fakt nesvěřil ani tu žumpu. 

Tak si tak vzpomínám na jednoho nejmenového procesora platebních karet. Taky u něj neleží žádné peníze...
- serverovna vlastní, za fyzickou ostrahou
- dveře do servrovny: musí se sejít 2 ze 3
- klíč je uložený v HSM (a při pokusu o odmontování se zničí)
- pro boot se musí sejít 2 ze 3, jiní než ti od dveří

Chápu, že bitconiová burza bude mít menší počty transakcí. Ale zase je přístupná normálně z webu.
A pochopím, když se rozhodne v některých věcech zabezpečení snížit - ale poté, co o těch možnostech ví a to rozhodnutí je vědommé. Ne, že je napadlo 5 věcí, co se může stát a tvrdí, že těm zabránit umí.

Mimochodem - (zcela základní) požadavky PCI/DSS máte doufám nastudované a implementované, že?

[Reklama]

[v.sp]

Co že to?

prepared statements jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)

RTFM

Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement.

A to vy ten příkaz budete pouštět only once? To nemyslíte vážně, že ne?

[Ondřej Novák]

A to vy ten příkaz budete pouštět only once? To nemyslíte vážně, že ne?

V PHP je většina příkazů pouštěna jednou za načtení stránky. Takže sekvence prepare, bind, execute, deallocate jsou 4 pingpongy

[Makovec]

A to vy ten příkaz budete pouštět only once? To nemyslíte vážně, že ne?

V PHP je většina příkazů pouštěna jednou za načtení stránky. Takže sekvence prepare, bind, execute, deallocate jsou 4 pingpongy

Chápete že je tam také nějaký SQL server na který ten SQL příkaz rozhodně nepůjde (pokud jste byl při navrhování té databáze při smyslech) "only once"?

[Mirek Prýmek]

Dík, věděl jsem, že to nikam nevede 

Dobře. Nepomohlo. Tak aspoň už máme všichni jasno, jak hluboko králičí nora vede.

Tak teda hodně štěstí.

---------------
Pro ostatní k pobavení:

"bitstock.cz - opravdová a zaručeně bezpečná burza bitcoinů (demo)"
"V podstate je to prvni 100% bezpecna BTC burza."

http://forum.lupa.cz/index.php?topic=3757.0

[Ondřej Novák]

Chápete že je tam také nějaký SQL server na který ten SQL příkaz rozhodně nepůjde (pokud jste byl při navrhování té databáze při smyslech) "only once"?

To já neřeším, já řeším latency. Tedy pokud neuvažuju stroj na localhostu komunikující po socketu. Tam je to jasné. Ale z hlediska bezpečnosti je to ted díra jak vrata. Když dam mastera na vzdálený stroj, už řeším latency. Tedy komunikace mezi klientem a serverem. A jestlize mi bězi apache v rezimu worker (jako ze muze bezet v rezimu MPM ale pak musim mít PHP jako CGI a budu si hrát s tuněním fastcgi), tak nevěřím tomu, že by tam byla nějaká optimalizace na úrovni sdílení připravených příkazů mezi workery. Prostě to bude tupě udělaný, Prepare -- ping pong --- bind -- ping ping -- execute --- ping ping  --- dealloate --- ping ping
a to by mě zajímalo,jestli třeba není ping pong mezi každou proměnnou.

Ale jak říkám, nemám s tím problém, není to těžké přehodit to z jednoho do druhého. Kdyžtak to ještě budu měřit a přijdu řict, jak jsem dopadl.

[Lol Phirae]

Tak si tak vzpomínám na jednoho nejmenového procesora platebních karet. Taky u něj neleží žádné peníze...
- serverovna vlastní, za fyzickou ostrahou
- dveře do servrovny: musí se sejít 2 ze 3
- klíč je uložený v HSM (a při pokusu o odmontování se zničí)
- pro boot se musí sejít 2 ze 3, jiní než ti od dveří

Takovej vopruz, co? Lepší je nic nešifrovat, kdo by v noci vstával. Radši pořešíme apostrovy.

Mimochodem - (zcela základní) požadavky PCI/DSS máte doufám nastudované a implementované, že?

Já se tedy přiznám, že moc ne. Ale na druhou stranu já nechci rozjíždět BTC burzu. 

[belzebub]

1) vsechny volani SQL by musely jit pres prepared statements. To je nutnost. A neexistuje zadny relevantni duvod proc prepared statements nepouzivat. To ze musite napsat o 2 radky navic neni zadny duvod. Vysledkem by bylo snizeni rizika SQL injection temer na nulu.

Osobní názor
 - jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)
 - v zásadě jen řeši obrovskou neschopnost programátorů ošetřit si apostrov (a mysql programátorů ten správný apostrof v tom textu najít)

Ale nemám s tím problém, používám vlastní API, které umí obojí.

Vsechny tyto "duvody" nejsou pravda. Nejsou pravda tak strasne moc, ze nejsem schopen pochopit, jak to muze napsat clovek, ktery pouziva SQL dele nez tyden. Pane Novak - PROSIM - sezente si nejakou knihu o SQL a PRECTETE si ji.

[belzebub]

Co že to?

prepared statements jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)

RTFM

Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement.

BOZE!!!!!!!! DOTED JSEM BYL SLUSNY, ALE PANE NOVAK, VY JSTE TOTALNI KRETEN!!!!!!

Prelozeno: pokud jeden SQL prikaz pouziji POUZE, A PRESNE JENOM JEDNOU, tak POUZE TEHDY je non-prepared rychlejsi. Uz pokud ten prikaz pouziji 2x, prepared statements vedou na cele care.
A protoze jste totalni amater a neumite anglicky - "pouzit vickrat" znamena pouzit vickrat prepared statement s LIBOVOLNYMI PARAMETRY.


AAAAAAAAAAAAAAAAAAAAAAAA!!!!!!!!!!!!!!!!! ME PRASKNE HLAVA!!!!!!!!!!!!!!!!! TO SNAD NENI MOZNE!!!!!!!!!!!!!!!

ZABIJTE HO NEKDO!!!!!!!!!!!!!!

[DK]

...

chlape, vy jste debil... jinak se to snad ani nazvat neda
bezte si bastlit cms pro stranky s vtipnyma obrazkama, nebo neco jineho, ale vykaslete se na financni systemy

(a to jsem se chtel nejdrive tehle diskuzi uplne vyhnout)

[Já]

Jelikož jsem znechucen amatérizmem místního joudy (a carlose, který k tomu přišel jak slepý k houslím), spustím v brzké době vlastní
burzu. Tentokráte snad funkční s nějakým bezpečnostním standardem. http://bitx.cz/