Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ddaniel 17. 04. 2017, 11:12:43
-
Zdravím,
prošel jsem stovky fór, kde se lidí ptají na podobné problémy jako řeším nyní, jak skrýt heslo k MySQL a AES šif. klíče v PHP, aby se nedalo dostat k osobní údajům klienta. Výsledek po přečtení fór, dokumentací apod. je nultý a to i u uživatelů. Veškeré kompilátory Zend Guard apod. jdou dešifrovat vč. i toho, když to dáte do php.ini. Jakékoliv skrytí ve funkci je zbytečné, protože tuto funkci lze volat a útočník má data jednoduše na stole. A to jsem zkoušel i od profi firem komerční řešení a během sekundy jsem měl zpět jejich kódy, takže k čemu to je?
Bohužel v magazínech čte člověk (a bohužel i osobní zkušenost), jak si vzali hackeři údaje z různých hostingů vč. PHP skriptů, jak nic. Díval jsem se i na jiné prog. jazyky a dost po nich pokukuji, protože ASP.NET nebo Java na tyto problémy mají dalekosáhlejší řešení. Nemusíte přímo dávat do configů, skritpů hesla.
Dost jsem se díval i nařešení na straně klienta než-li serveru, ale to dost komplikuje mnohé věci, i když je to nejefektivnější řešení.
Máte nápad, jak v databasi šifrovat data tak, aby v PHP skriptech nenašli útočníci, tak rychle řešení? :) Díky za info, rád se poučím .....
Je to i kvůli řešeí nyní zákona GDPR od EU.
-
Základem bude asi nenechat si ukrást ty PHP skripty a nenechat si nahrát na hosting cizí skripty.
-
Pokud se útočník dostane ke zdrojákům a heslo tam někde je, vždycky se k němu dostane relativně snadno. Pokud tomu chcete zabránit, jediné řešení je dodávat heslo z venku – pak ale zase musíte umět ověřit, že ho dáváte té správné aplikaci.
Já bych se ale pro základní zabezpečení vydal jinou cestou, a to aby se útočník na váš server vůbec nedostal. Protože pokud už je na vašem serveru a může manipulovat s aplikací, může už tak napáchat dost škod a získat spoustu osobních údajů – získat přístup do databáze už by byla spíš jen taková třešnička na dortu.
-
Nepouzivaj zdielany hosting a ked uz musis, tak nie od garazovych poskytovatelov. Ked moze utocnik lubovolne manipulovat PHP/SQL na serveri tak ziadna ochrana neexistuje.
Ked tym nemoze manipulovat, tak uz mozes presunut cast zabezpecenia na klienta. Kazdy klient ma v DB kluc zasifrovany jeho heslom. Heslo pri kazdom pristupe desifruje kluc a tym sa potom sifruju a desifruju dalsie data. Treba to poriadne navrhnut, inak sa zmeny robia zle.
Ked ti staci nizsia uroven ochrany, tak moze mat kazdy uzivatel svoj pristup do DB, ktory mu neumozni spravit nic viac ako aplikacia. Hacker ma potom komplikovanejsi pristup.
-
Díval jsem se i na jiné prog. jazyky a dost po nich pokukuji, protože ASP.NET nebo Java na tyto problémy mají dalekosáhlejší řešení.
Ne, nemají. Holt místo deobfuskace dekompiluješ bytecode (což vlastně Zend má myslím pro PHP taky).
Nemusíte přímo dávat do configů, skritpů hesla.
Musíte, resp. pokud ne, tak by to úplně stejně šlo i v PHP.
Máte nápad, jak v databasi šifrovat data tak, aby v PHP skriptech nenašli útočníci, tak rychle řešení? :) Díky za info, rád se poučím .....
Tak si rozmysli, co vlastně chceš - aby program uměl dešifrovat data, když ho používáš ty, a současně neuměl dešifrovat data, když si ho zkopíruje útočník? Jak chceš z pohledu programu takovou věc odlišit?
Chtělo by to popsat, co vlastně se snažíš chránit.
-
Ne, nemají. Holt místo deobfuskace dekompiluješ bytecode (což vlastně Zend má myslím pro PHP taky).
A když ten klíč nebude v dekompilovaném kódu vidět na první pohled, stačí aplikaci podstrčit vlastní ovladač databáze (který nemusí dělat nic jiného, než že jenom zaloguje heslo), nebo často stačí jen odposlechnout komunikaci mezi aplikací a databází.
-
běžně se využívá služba (daemon, lokální či vzdálený), která ti klíče poskytuje, primitivní implementace je přes socket na daném stroji. Pro hosting je vhodné podobnou službu umístit na jiný dedikovaný stroj, nad kterým máš kontrolu.
Na server se dá na tohle poměrně dobře použít TMP čip či HSM modul. Ve větším nasazení existují speciální servery, který udržují klíče, každý větší výrobce HW takovéhle 1U krabičky dodává a používáme je třeba pro držení klíčů k jednotlivým uživatelům.
Bez monitoring a alertingu přístupu ke klíčům se ale neobejdeš a sebelepší systém záleží na tom jak důkladně ho pozoruješ, bezpečnostní chyby jsou a budou.
Pokud manipuluješ se symetrickými klíči, určitě se mrkni na PBKDF2 a nesnaž se vymýšlet svoje chujoviny. Na obyčejném php hosting to nejsi schopný zabezpečit a klidně měj heslo v php.ini. Levně je možné službu do hesla umístit na dedikovaný server, který máš pod kontrolou.
Pokud máš jedno statické heslo pro celou databázi, uložení v konfigu je přípustné a pokud se někdo dostane ke klíči, máš smůlu, na tom nic nezměníš. Řešením je mít pro každého uživatele vlastní klíč a jejich vydávání povolovat další aplikací (možná pro tebe vhodné řešení k nastudování je https://www.hashicorp.com/products/vault/). Daná služba musí být chráněna proti vytěžování a mít určitý rate limiting.
Průmyslovější řešení je použití HSM modulu, který má klíče u sebe a nikdy je nevydává, naopak mu posíláš šifrovaný obsah a on ti vrací dešifrovaný, v řešení v pci-e karty to dává 1GiB/s jak nic.
Kvůli GDPR nic takového nepotřebuješ, tam stačí šifrovat a poté mít jasně dokumentované postupy kde je klíč a kdo k němu má přístup. Každopádně tohle ti musí určit zmocněnec, kterého musíš určit. Ne všechny "eshopy" budou muset šifrovat a za mě v tom nařízení jsou daleko důležitější a problematičtější věci.
-
běžně se využívá služba (daemon, lokální či vzdálený), která ti klíče poskytuje, primitivní implementace je přes socket na daném stroji. Pro hosting je vhodné podobnou službu umístit na jiný dedikovaný stroj, nad kterým máš kontrolu
Co třeba LDAP?
-
Jako že máš heslo přímo v kódu? To si ho rovnou vyvěs na tlamoknihu!
-
Smysluplné jsou pouze dva způsoby:
1) uložení v environment proměnných
2) uložení v externí secrets storage (samozřejmě patřičně zabezpečené)
Pro normální potřeby je 1 ideální.
-
1) uložení v environment proměnných
Tazatel řešil, že útočník může číst php.ini, a volat funkce z jeho programu. Čekal bych, že v tom případě bude schopný číst i environment.
-
1) uložení v environment proměnných
Tazatel řešil, že útočník může číst php.ini, a volat funkce z jeho programu. Čekal bych, že v tom případě bude schopný číst i environment.
Environment jde pouzit jen pro prvotni nacteni a pak se muze zrusit - tzn heslo tam bude jen kratkou chvilku po startu aplikace nez se zinicializuji spojeni - nevim ale jestli v php existuji nejake implementace data sources, ktere takovyto pristup umozni.
-
1) uložení v environment proměnných
Tazatel řešil, že útočník může číst php.ini, a volat funkce z jeho programu. Čekal bych, že v tom případě bude schopný číst i environment.
Možná bude lepší nemít v aplikace žádné vlastní funkce.
-
Díky za odpovědi. Jde jen o to, co je v tu chvíli nejlepší, když útočník je až na serveru (třeba i pouze na ftp), protože v případě PHP jde velice málo udělat po přečtení mnoha diskusí (v případě pokud nejsem správce serveru). V asp.net jsem našel možnosti viz. např. http://www.4guysfromrolla.com/articles/021506-1.aspx. Přesně podobný případ řeším - je to jen zatím paraonia i zadavatele - mnohdy bohužel odůvodněná. Na server častokrát člověk nemá přístup, musí být u různých hosting. společností, takže i řeším tento problém. Ale u PHP jsem nemusel doposavaď po mnoha letech nic moc podobného řešit, ale zadání je nyní takové, aby se ochránila data i případě neoprávněného přístupu na serveru/ftp, i když není pod mou správou. Takže se ptám na možnosti a děkuji všem za informace a trpělivost. Zatím mi to mnoho dalo.
-
Ještě můžeš použít Kerberos.
-
LDAP je adresářová struktura, není určený k uchovávání hesel, řada jeho implementací nemá ani šifrované uložiště. Kerberos řeší pouze propojení služeb napříč stanicemi, nikoliv co a jak si vyměňují, na ochování hesel je vyloženě neefektivní a nepoužitelný.
PHP se pro každý request spouští znovu (teda pokud se nepoužije fpm nebo hiphop) a tak potřebuje mít čitelný env pořád a nelze mu ho po čase vzít.
Na serveru, který není pod tvou správu data ochráníš velice složitě, to je boj s větrnými mlýny. Do php.ini není běžně přístup ani z ftp, v konfiguračních souborech by heslo mělo být bezpečné.
Můžeš více rozepsat problém? Proti komu děláš obranu nebo jen chceš vyhovět zadavateli? Ono pokud někdo můžeš upravit php soubory, není nic jednoduššího než si dané heslo nechat k sobě poslat a neřešit, že ho máš 4x šifrovaný v zipu, když si prostě upraví třídu na jejich dešifrování a jede. Jakmile někdo můžeš přistupovat a měnit zdrojové soubory, heslo bez HSM neuchráníš.
-
V asp.net jsem našel možnosti viz. např. http://www.4guysfromrolla.com/articles/021506-1.aspx.
Furt jsi neřekl, proti čemu se bráníš. Tohle, jestli jsem pochopil, pomůže proti možnosti ze serveru pouze číst. Z prvního příspěvku mi přišlo, že řešíš případ, když útočník kompromitoval multihosting a tak si typicky může spouštět na serveru vlastní kód.
Odkazovaný článek jsem jen proletěl, ale přišlo mi, že tohoto by šlo na Linuxu dosáhnout prostřednictvím binárky, ke které nebudeš mít R práva, ale jenom X práva, a heslo při spuštění vypíše na stdout. A nebo třeba tu telnet službu na localhostu/soketu, jak už tu někdo navrhoval.
-
Ano, jde o vyhovění zadavateli.
Stručně řečeno: chce na hostingu (který nespravujeme), v případě kompromitace, aby útočník (pokud se dostane buď k FTP nebo vůbec souborovému systému) se nemohl dostat k MySQL databasi přes PHP (přes např. configy) a nebo také i v případě klíčům, které šifrují obsah database nebo jej dekriptují jako např. "SELECT AES_DECRYPT(name, 'sifrovaci_klic'), AES_DECRYPT(address, 'sifrovaci_klic') from db_user; ". Jde o šifrování jednoduše textových dat k jednotlivým uživatelům, aby v případě kompromitace nešli, tak jednoduše přečíst.
Proto hledám řešení, kde v PHP trochu tápu a o ostatních prog. jazycích jsem našel i další zajímavé řešení, ale myslím si i to, co tady psali všichni, že by bylo dobré si nechat to heslo jednoduše v tom PHP zaslat.
-
V asp.net jsem našel možnosti viz. např. http://www.4guysfromrolla.com/articles/021506-1.aspx.
Furt jsi neřekl, proti čemu se bráníš. Tohle, jestli jsem pochopil, pomůže proti možnosti ze serveru pouze číst. Z prvního příspěvku mi přišlo, že řešíš případ, když útočník kompromitoval multihosting a tak si typicky může spouštět na serveru vlastní kód.
Odkazovaný článek jsem jen proletěl, ale přišlo mi, že tohoto by šlo na Linuxu dosáhnout prostřednictvím binárky, ke které nebudeš mít R práva, ale jenom X práva, a heslo při spuštění vypíše na stdout. A nebo třeba tu telnet službu na localhostu/soketu, jak už tu někdo navrhoval.
Podle toho odkazu bych to tipoval na trolla, který nám chce ukázat, jak je PHP děravé a jak to ASP řeší.
Nezaslouží si ta aplikace vlastní (třeba i virtuální) server? Bez FTP, mailů a podobných blbostí?
-
v případě kompromitace, aby útočník (pokud se dostane buď k FTP nebo vůbec souborovému systému) se nemohl dostat k MySQL databasi přes PHP
Pokud se útočník dostane jenom pro čtení k souborovému systému, bude mu k ničemu, když získá heslo k databázi – musel by ještě získat (síťový) přístup k té databázi. Není dobrý nápad, aby databázový uživatel, pod kterým přistupuje webová aplikace, měl do databáze přístup odjinud, než z webového serveru.
-
pokud se dostane buď k FTP nebo vůbec souborovému systému
Aha, takže opravdu read-write.
Proto hledám řešení, kde v PHP trochu tápu a o ostatních prog. jazycích jsem našel i další zajímavé řešení, ale myslím si i to, co tady psali všichni, že by bylo dobré si nechat to heslo jednoduše v tom PHP zaslat.
Tak si zkus opravdu upřímně odpovědět na otázku, kterou jsem ti už dával - kdybys byl to vysněné bezpečnostní řešení, jak poznáš, jestli se k tobě právě připojuje originální program, nebo program, který ovládá útočník?
// když se pohybuješ v oblasti, kde o bezpečnost zjevně jde, fakt by sis na to neměl najít někoho, kdo tomu rozumí?
-
Kit: To se omlouvám, že to tak zní, ale bohužel já to potřebuji vyřešit v PHP a ne v jiném program. jazyku. Potřebuji jen podobné řešení a abych přiblížil problematiku jsem použil příklady odjinud. Nevím, jak to lépe jinak přiblížit než-li, aby lidé viděli podobné věci.
Ale jinak samozřejmě děkuji za radu.
Jenda: Máš zcela pravdu, poradím se ještě s lidma v této oblasti.
Každopádně všem děkuji za ochotu a nápady. Téma bych uzavřel......
-
A proc tedy neudelate alespon to, ze kazdy uzivatel bude mit vlastni user/pass do sql db a to se po prihlaseni do aplikace pouzite nasledne ve funcki "mysql_connect", jasne, neni to nejake super reseni, jde to odchytit snad pred hned u te funkce sql connect, ale pokud jde zakaznikovi jen o tom aby nemel na serveru v config file heslo k db tak by to mohlo stacit.
V situaci kdy jedete na nejakem sdilenem hostingu a nemate pristup k serveru si nemuzete moc vyskakovat zvlaste pokud nekdo ma kontrolo na zdrojovym kodem.
Pak me jeste napada implementace one time password reseni, ale stejne kdyz nemate server tak to neni asi moc sance. Mark5
-
A proc tedy neudelate alespon to, ze kazdy uzivatel bude mit vlastni user/pass do sql db a to se po prihlaseni do aplikace pouzite nasledne ve funcki "mysql_connect", jasne, neni to nejake super reseni, jde to odchytit snad pred hned u te funkce sql connect, ale pokud jde zakaznikovi jen o tom aby nemel na serveru v config file heslo k db tak by to mohlo stacit.
Mezi PHP a MySQL se dá vpašovat SSL, v tom bych problém neviděl.
Od používání vlastních hesel k MySQL se kdysi z nějakého důvodu upustilo. Webhostingy obvykle nabízí k databázi jen 1-2 účty, takže tudy cesta asi nepovede. Jedině ve virtuálu, ale tam se dá najít výhodnější řešení.
-
A proc tedy neudelate alespon to, ze kazdy uzivatel bude mit vlastni user/pass do sql db a to se po prihlaseni do aplikace pouzite nasledne ve funcki "mysql_connect",
na nejakym takovym beznym hostingu jo? tak urcite...
Proc nekdo proboha resi nejaky AES sifrovovani a podobny vylomeniny kdyz ma hosting s FTPkem(tipuju wedos za petku mesicne co si neumi pohlidat ani vyprseni DNSSEC)? Minimalne polovina problemu by zmizela pri pouziti VPS a nejakyho uplne obycejnyho CI nastroje.
-
Od používání vlastních hesel k MySQL se kdysi z nějakého důvodu upustilo.
Důvodem je, že je to nepoužitelné pro model, jakým se dnes aplikace navrhují. Vlastní uživatelské účty do databáze mají význam tehdy, když se bezpečnost řídí na úrovni databáze.
Představte si běžný e-shop, kde se uživatelé mohou registrovat. Za prvé by nepřihlášený uživatel musel běžet pod účtem, který by měl právo zakládat uživatele a přidělovat mu oprávnění – a to už je jakékoli další zabezpečení k ničemu, může to klidně běžet pod tímhle účtem celé. A dál, i kdybyste se rozhodl jít touhle cestou, aby to mělo význam, potřebujete oprávnění na úrovni řádků. A do třetice, jméno a heslo by musel mít server k dispozici v otevřeném tvaru pro každý požadavek – takže buď uložené v session na serveru (kde ho zase může někdo ukrást), nebo ho přenášet s každým požadavkem. No a také by se neustále otvírala a zavírala spojení do databáze, místo dnešního sdílení připojení.
Každý uživatel = vlastní účet v databázi – to mohlo mít smysl maximálně u klient-server aplikací, kdy celá aplikace běžela u klienta a pouze se přes SQL připojovala do databáze.
-
Od používání vlastních hesel k MySQL se kdysi z nějakého důvodu upustilo.
Důvodem je, že je to nepoužitelné pro model, jakým se dnes aplikace navrhují. Vlastní uživatelské účty do databáze mají význam tehdy, když se bezpečnost řídí na úrovni databáze.
Představte si běžný e-shop, kde se uživatelé mohou registrovat. Za prvé by nepřihlášený uživatel musel běžet pod účtem, který by měl právo zakládat uživatele a přidělovat mu oprávnění – a to už je jakékoli další zabezpečení k ničemu, může to klidně běžet pod tímhle účtem celé.
Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.
A dál, i kdybyste se rozhodl jít touhle cestou, aby to mělo význam, potřebujete oprávnění na úrovni řádků.
Stacia SQL procedury a pohlady.
A do třetice, jméno a heslo by musel mít server k dispozici v otevřeném tvaru pro každý požadavek – takže buď uložené v session na serveru (kde ho zase může někdo ukrást), nebo ho přenášet s každým požadavkem. No a také by se neustále otvírala a zavírala spojení do databáze, místo dnešního sdílení připojení.
Aj pri prenose kazdy krat sa to da ukradnut.
Každý uživatel = vlastní účet v databázi – to mohlo mít smysl maximálně u klient-server aplikací, kdy celá aplikace běžela u klienta a pouze se přes SQL připojovala do databáze.
Alebo u aplikacii, kde zalezi na bezpecnosti. Mnozstvo bugov je priamo umerne mnozstvu kodu. SQL definicia u eshopu vyjde na stovky az male tisice riadkov.
Cela aplikacia ma o dva rady viac kodu a tam sa lahsie skryje aj bug, ktory umozni citat alebo modifikovat o nieco viac, ako si predstavujeme.
-
Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.
Pokud může přidělovat další práva, má držitel takového účtu efektivně ta práva, která daný účet můře přidělit. Přinejhorším si prostě pro sebe založí druhý účet, který následně použije.
-
Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.
Pokud může přidělovat další práva, má držitel takového účtu efektivně ta práva, která daný účet můře přidělit. Přinejhorším si prostě pro sebe založí druhý účet, který následně použije.
Sice to není pravda, ale stejně by to nevadilo.
-
Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.
Pokud může přidělovat další práva, má držitel takového účtu efektivně ta práva, která daný účet můře přidělit.
Nema. Kazdy ma pravo vytvorit uzivatela na forum.root.cz a tym dostane pri poskytnuti hesla pravo na editaciu vytvoreneho uctu. Toto neposkytuje pravo editovat nahodny existujuci ucet.
Přinejhorším si prostě pro sebe založí druhý účet, který následně použije.
Ano, ja si mozem zalozit druhy ucet "PJ" a ten si mozem pouzivat, ale nebudem mat pravo citat detaily o ucte Filipa Jirsaka, jeho sukromne spravy a ani mu nebudem moct zmenit heslo.
-
Nema. Kazdy ma pravo vytvorit uzivatela na forum.root.cz a tym dostane pri poskytnuti hesla pravo na editaciu vytvoreneho uctu. Toto neposkytuje pravo editovat nahodny existujuci ucet.
Jistě. Protože běžný uživatelský účet nemá práva editovat náhodný existující účet. O tom ale nebyla řeč. Řeč byla o tom, že když má anonym právo vytvořit účet, má efektivně veškerá práva, která má nově vytvořený účet.