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

[Jozef]

Tiez by ma to zaujimalo. Takze mesiac prace , to bude asi tiez bezpecne...

Takže když ty budeš programovat něco rok tak to bude bezpečnější než když to budu dělat měsíc? CRUDy jsou hotový, jestli vyrábíš nějakej portál roky, budiž, já si na tohle korporátní sračičkování nepotrpím. Naučil jsem se za dobu živnostničení prototypovat weby co nejefektivnějš, protože mi nikdo neplatí za čas. Ostatně koncept je postaven tak, že i když někde bude díra tak nikdo o peníze nepřijde - ale to mi věřit můžeš a nemusíš. Napíšu o tom víc časem...proto ty maily

CRUDy su sice pekna vec, ale to sa da nagenerovat a prototyp dat za den, lenze do kompletneho webu to ma este trocha daleko...
Ten mesiac by som si dal len na testy. Ale pokial nemas neake "eso v rukave" asi to nebude to "prave orechove", rad sa necham sa prekvapit

[Reklama]

[Mirek Prýmek]

Ale pokial nemas neake "eso v rukave"

Já bych udělal jednu statickou stránku, na které by byly instrukce, jak burzovní příkazy zadávat papírovou poštou. Tu byste valili bulvy, jak by to bylo bezpečný!

[Jozef]

Ale pokial nemas neake "eso v rukave"

Já bych udělal jednu statickou stránku, na které by byly instrukce, jak burzovní příkazy zadávat papírovou poštou. Tu byste valili bulvy, jak by to bylo bezpečný!

A hotovo. Vie este niekto o bezpecnejsiom rieseni? 

[Mirek Prýmek]

A hotovo. Vie este niekto o bezpecnejsiom rieseni? 

Ještě jsem zapomněl dodat, že port 443 by byl chráněněj port-knocking sekvencí, kterou bych znal jenom já. Fraud-rate 0%.

[Franta <xkucf03/>]

ROFL

Naštěstí nikam jsi nepronikl: Ten odkaz vypadal takto.
[...] To sice není nic moc, ale k narušení bezpečnostni nedošlo...

Vyzrazení vnitřní struktury dat není narušení bezpečnosti? U takhle citlivé věci?
Jestli jsi nám chtěl demonstrovat, že o bezpečnosti vůbec nic nevíte, tak se ti to podařilo )

Což o to, zveřejnění struktury nic není, hlavní je, zda uniknou či neuniknou data nebo zda se je dokonce podaří neoprávněně modifikovat či smazat. Konec konců, mohl by zveřejnit i zdrojáky a tím všem ukázat, jak je to bezpečné – dobrá aplikace ustojí, i když útočník bude mít kompletní zdrojové kódy.

[Reklama]

[Mr.C]

Panove z bitstock.cz,

bezpecnost neni snadna zalezitost a doporucuji abyste se obratili na professionaly v oboru. I kdyz si myslite, ze problematice rozumite (zcela mylne, ale to rozebirat nebudu), tak ve vlastnim zajmu to nebastlete bez dozoru odborniku.

Nebude to levne, ale pokud chcete rozjet projekt kde jde o skutecne penize, tak si to ani jinak nedovedu predstavit. A prosim uz nezminujte ze je to 100% bezpecne protoze to nema uschovnu bitcoinu - jen dokazujete jak obrovske nedostatky mate nejen v analyze rizik (pokud vubec), ale i ve vasem obchodnim planu.

Lide, kteri se zabyvaji bezpecnostni na profesionalni urovni vam to zadarmo testovat nebudou, coz vam jen doda pocit falesne jistoty, ze je to neprustrelne. A blackhat vam to otestuje az naostro - to ale bude jiz pozde.

Verte mi, je toho tolik o cem nemate ani poneti. Uz od prvniho pohledu aniz bych cokoliv testoval vidim tolik nedostatku, ze mohu pouze doporucit abyste odlozili sve ego a vyhledali pomoc.

Nejdrive najmete odborniky kteri vam poradi ohledne obrany. Tim myslim zamerit se na vse od SDLC a applikacni bezpecnosti; bezpecnost architektury jak applikacni, tak i infrastruktury, atd. Nekoho kdo vam napriklad trpelive vysvetli jak se spravne branit SQL injection (ne, to co jste predvedli je k smichu), jak navrhnout architekturu, jak spravne zabezpecit servery a sit, jak nakladat s logy, jak zajistit integritu, fyzickou bezpecnost, co a jak spravne sifovat, atd.

Az tohle vse zvladnete (a ze toho nebude malo), tak si objednejte profesionalni manualni penetracni test od jine firmy nez vam to pomahala zabezpecit. Pokud test vykaze pouze defekty nizke dulezitosti potom mate elespon nejakou sanci prezit dele nez jeden den.

Rozhodne jsem se ctenim teto diskuze pobavil, ale dobry pocit z vaseho projektu a ani z vas nemam.

C.

[TTTTTTT]

Zaujala mě tu zmínka o rychlosti prepared statements - kde jste "vysmáli" argumentu, že bez nich je to rychlejší. Od pohledu mi přijde, že ve většině php aplikací to bez nich skutečně bude rychlejší. Myslím si, že

• typická php/mysql aplikace se připojuje k databázi při každém požadavku
• prepared statements jsou vázané na databázové spojení, tedy po odpojení zaniknou

Tedy prepared statement se využijí jen pokud se dotaz opakuje v rámci jednoho requestu. Pokud se dotazy neopakují, pak bude skutečně rychlejší provádění dotazů bez prepared statements. Zřejmě zanedbatelně.

Má PHP nějaký mechanismus, pomocí kterého sdílí zdroje i mezi požadavky a který se běžně používá? Ač PHP nepoužívám, budu rád, pokud mi někdo rozšíří obzory.

P.S. Nepoužívání prepared statements nechci obhajovat, ochranu proti SQL injection považuju za dostatečný důvod.

[Filip Jirsák]

To se ovšem týká jen PHP s MySQL a serverovými prepared statements, pokud se nepoolují databázová připojení (tedy asi vždy v režimu FastCGI). Pořád ještě ale záleží na tom, které API se použije a jak je zkonfigurované -- zda používá nebo nepoužívá server side prepared statements.

Ten roundtrip na lokální síti, který pan Novák uváděl, ale bude úplně stejný při každém navázání spojení, a tomu se bez poolu nevyhne. Takže nepoužívat z tohoto důvodu prepared statements je trochu mimo. Pokud už by bylo potřeba optimalizovat takovéhle věci, tak je potřeba v první řadě řešit poolování spojení do databáze, a pak vůbec zvážit, zda MySQL je vhodná databáze pro takovýhle případ. Protože třeba to kešování dotazů je v MySQL dost zvláštní.

Ale je pravda, že předpokládat, že MySQL dělá běžné optimalizace, bylo poněkud unáhlené. Takže běžné důvody, proč jsou prepared statements efektivnější, nemusí u MySQL platit.

[Mirek Prýmek]

a pak vůbec zvážit, zda MySQL je vhodná databáze pro takovýhle případ

...a jestli PHP je vhodný jazyk pro takový případ

[devnull]

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.

Ta diskuze je zabavna - tak se do ni taky zapojim ohledne prepared dotazu.

Nesouhlasim s citaci nahore - pri opakovanych dotazech nemusi prepared statements vest na cele care, dokonce muzou prohrat na cele care, zalezi na hodne vecech. Databaze si zpravidla dela plan SQL dotazu pri vytvareni prepared statementu, je-li volba planu zasadnim zpusobem zavisla na parametrech, muze DB udelat plan spatnej a pak dotazy trvaji dlouho - casto se to deje, napriklad pri nerovnomernem rozlozeni hodnot na indexovanem sloupci.

Priklad:
tabulka s milionem radku a sloupcem x nastavenym v 950000 radcich na 0 a v 1000 radsich na 1. Kdyz dam select WHERE x = 0 je mnohem vyhodnejsi delat fullscan, kdyz budu hledat WHERE x = 1, je jasnou volbou index lookup. Pokud bych stridal jeden prepared pro oba pripady, a pouzival se stale jeden plan, melo by to fatalni nasledky.
Dokonce to vzdy nemusi byt v ramci jednoho pripojeni - resil jsem kdysi problem na MSSQL, ktera, alespon tehdy s danym nastavenim, cachovala plany k jednotlivym dotazum a to napric vsema pripojenima do databaze - napsani prepared statementu pak mohlo mit neblahe nasledky na vykon.

Tim samozrejme nerikam ze prepared statementy jsou na nic. Maji sve opodstatneni, pouzivat je je ve vetsine pripadu lepsi, a samosebou odstranuji problemy s escapovanim. Ale nic neni cernobile ... a napsat "SELECT * FROM table WHERE x = ".(int)$x mi prijde uplne OK a nikoho bych za to nekamenoval.

[Filip Jirsák]

Nesouhlasim s citaci nahore - pri opakovanych dotazech nemusi prepared statements vest na cele care, dokonce muzou prohrat na cele care, zalezi na hodne vecech. Databaze si zpravidla dela plan SQL dotazu pri vytvareni prepared statementu, je-li volba planu zasadnim zpusobem zavisla na parametrech, muze DB udelat plan spatnej a pak dotazy trvaji dlouho - casto se to deje, napriklad pri nerovnomernem rozlozeni hodnot na indexovanem sloupci.

Podle toho, jak jsem rychle prolétl popis kešování MySQL, kešuje dotazy i s hodnotami. Což podle mne odbourává jednu docela zásadní výhodu prepared statements, na druhou stranu, výše uvedený problém pro MySQL neplatí. Druhá věc je, že výše uvedená věc je docela speciální případ a nemá smysl kvůli tomu měnit zpracování všech SQL příkazů. Pokud nastane, je potřeba ho ošetřit v tom jednom případě. Ono asi stejně bude nutné přidat v takovém případě další podmínku nebo něco takového, protože s uvedeným problémem se rozumně nevyrovná ani aplikace. Pokud se v jednom pohledu uživateli běžně vrací deset záznamů, a najednou se mu jich tam vrátí milion, co s nimi bude dělat, bude po jednom je procházet?
Další věc je, že prepared statements je také jiný způsob zápisu SQL příkazu na klientovi, ale to ještě neznamená, že se musí použít prepared statement na serveru. Je možné je přeložit na příkaz s vloženými hodnotami na klientovi (tedy to, o co se snaží real_escape, ale bezpečně), je možné serveru napovědět, že nemá prováděcí plán kešovat. Záleží jen na možnostech klientské knihovny a serveru.

napsat "SELECT * FROM table WHERE x = ".(int)$x mi prijde uplne OK a nikoho bych za to nekamenoval

Ale k čemu je dobré to takhle zapisovat, má to nějakou výhodu? Já vidím hlavně nevýhody. Nesmíte nikde zapomenout na to přetypování; řetězce musíte řešit jinak; jakmile ten příkaz bude delší, bude to nepřehledné; SQL dotaz se sestavuje až při prvním použití, takže prakticky nemůžete udělat statickou kontrolu dotazů...

[Juro]

Myslim, ze dost vela ludi tu ukazalo, ako bezpecnost nerobit. A nemyslim tym autora povodneho prispevku, ale aj roznych mudrlantov.  Poprve, ziadne "bezpecnostne poziadavky" neexistuju. Existuju biznis poziadavky a biznis ciele. Toto je jedna zo zakladnych veci. Druha vec je, ze bezpecnost sa nerobi podla ziadnych "industry best practices". Robia sa konkretne opatrenia, aby podporovali tie biznis ciele. Koniec skolenia. Konkretne priklady:
1. Na kieho certa by mal niekto nasadzovat zalozny server pre vysoku dostupnost, pokial business owner povie, ze 1 dnovy vypadok  je pre neho OK a zasadne neohrozuje jeho ciele (on tom rozhoduje business owner, nie niekto zvonku)
2. Na kieho certa bude niekto niekam strkat alebo pripajat HSM, pokial je cena takychto opatreni vyssia ako cena chranenych assetov. Ak viem, ze dam za 1 HSM napr. 11.000 EUR (pri vysokej dostupnosti x 2), tak naozaj zvazim, ci mi hrozi takyto fraud. Ci si radsej nenecham 22.000 EUR na ucte a ked ta situacia nastane, tak z nich kompenzujem skodu a ked nenastane, prepijem ich.
3. Na kieho certa budem odomykat miestost a bootovat server K ludmi z N, pokial to, ze to spravuje 1 admin neprekracuje moj risk apetit
A tak dalej.

Povodnemu prispievatelovi ste dali uzasne skolenie ako by mal komunikovat. Pani, ja si neviem predstavit, ze by ste niekde robili konzultantov (napr. bezpecnostnych) profesionalne a nechali sa vytocit takymi drobnostami ako to, ze vas adresat nepocuva alebo mu nieco nedopina.

Pytal sa vas, co si myslite o jeho biznis modeli, podmienkach sluzby, na pravne rady a pod? Nepytal. Ak si o tom chcete pokecat, zalozte si na to thread. Chcel aby ste mu pomohli z testovanim a ukazali konkretne zranitelnosti. Ked o to nemate zaujem, nerobte to a nematurujte nad tym, "aki su ludia vychcani a chcu nieco zadarmo".

[Pavel 'TIGER' Růžička]

Myslim, ze dost vela ludi tu ukazalo, ako bezpecnost nerobit. A nemyslim tym autora povodneho prispevku, ale aj roznych mudrlantov.  Poprve, ziadne "bezpecnostne poziadavky" neexistuju. Existuju biznis poziadavky a biznis ciele. Toto je jedna zo zakladnych veci. Druha vec je, ze bezpecnost sa nerobi podla ziadnych "industry best practices". Robia sa konkretne opatrenia, aby podporovali tie biznis ciele. Koniec skolenia. Konkretne priklady:
1. Na kieho certa by mal niekto nasadzovat zalozny server pre vysoku dostupnost, pokial business owner povie, ze 1 dnovy vypadok  je pre neho OK a zasadne neohrozuje jeho ciele (on tom rozhoduje business owner, nie niekto zvonku)
2. Na kieho certa bude niekto niekam strkat alebo pripajat HSM, pokial je cena takychto opatreni vyssia ako cena chranenych assetov. Ak viem, ze dam za 1 HSM napr. 11.000 EUR (pri vysokej dostupnosti x 2), tak naozaj zvazim, ci mi hrozi takyto fraud. Ci si radsej nenecham 22.000 EUR na ucte a ked ta situacia nastane, tak z nich kompenzujem skodu a ked nenastane, prepijem ich.
3. Na kieho certa budem odomykat miestost a bootovat server K ludmi z N, pokial to, ze to spravuje 1 admin neprekracuje moj risk apetit
A tak dalej.

Povodnemu prispievatelovi ste dali uzasne skolenie ako by mal komunikovat. Pani, ja si neviem predstavit, ze by ste niekde robili konzultantov (napr. bezpecnostnych) profesionalne a nechali sa vytocit takymi drobnostami ako to, ze vas adresat nepocuva alebo mu nieco nedopina.

Pytal sa vas, co si myslite o jeho biznis modeli, podmienkach sluzby, na pravne rady a pod? Nepytal. Ak si o tom chcete pokecat, zalozte si na to thread. Chcel aby ste mu pomohli z testovanim a ukazali konkretne zranitelnosti. Ked o to nemate zaujem, nerobte to a nematurujte nad tym, "aki su ludia vychcani a chcu nieco zadarmo".

Tak existují různé bezpečnostní standardy, které se běžně aplikují do byznys plánů a to podle jejich zaměření. Na provozovateli je, jestli ony bezpečnostní prvky chce vylepšit, nebo půjde tím všeobecním standardem.

Co se čertů 1 - 3 týče, radil bych počkat na Mikuláše, přeci jen je to už jen pár dní ...

Nevidím vůbec nic špatného na tom, když se celý problém vzal koplexně, vlastně je to podle mého názoru i dobře, protože díky tomu se někteří lidé mohli dočíst i to, v čem nejsou tolik zběhlí. I mne jeden, nebo dva příspěvky zaujali a nesouviseli přímo s dotazem. Takže, proč se něco nedozvědět?

Když bych někde dělal nějakého konzultanta (což není mým cílem), bral bych za to peníze, které by byly dostatečnou inspirací pro trpělivost s klientem. Ale pokud by někdo se mnou jako s konzultantem jednal jako tady Ondřej (mimochodem všechno nejlepší k svátku), tak bych mu vysvětlil, že já nejsem ten pravý, ať si na to najme někoho jiného. Peníze vem čert, slušnost je základ jakékoliv komunikace.

[Mirek Prýmek]

Druha vec je, ze bezpecnost sa nerobi podla ziadnych "industry best practices". Robia sa konkretne opatrenia, aby podporovali tie biznis ciele.

Tím jsi neřekl nic jiného než že konkrétní technické řešení musí vycházet z analýzy rizik. Těžko říct, proti čemu tím protestuješ, nezaznamenal jsem, že by tady někdo psal něco jiného.

A nejsem si úplně jistý, jestli se náhodou analýzy rizik občas nedělají podle "industry best practices [for risk assessment]"

[Inkvizitor]

Povodnemu prispievatelovi ste dali uzasne skolenie ako by mal komunikovat. Pani, ja si neviem predstavit, ze by ste niekde robili konzultantov (napr. bezpecnostnych) profesionalne a nechali sa vytocit takymi drobnostami ako to, ze vas adresat nepocuva alebo mu nieco nedopina.

Zatímco v první části příspěvku jste to vystihnul hezky, tady bych si dovolil podotknout, že nechat programátora, aby prezentoval komerční produkt byla dost zásadní chyba, ale ještě větší chyba byla v následné panice zkoušet jeden přes druhého napravovat způsobené škody (přičemž každý říká něco jiného). A vůbec nejhorší chyba byla nechat ho tady vykecávat dál a ještě víc to rozmazávat. Tolik k té komunikaci. Na jednu stranu rozumně píšete o byznysu, ale jako by Vám unikalo, že ta diskuse se dosud netočila jenom kolem SQL injection apod., ale z velké části i kolem toho, že se tady pánům povedlo dost závažně nabourat důvěru v příčetné vedení celého projektu, což je podle mě podstatně horší.