Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Palem 05. 11. 2014, 10:48:38
-
Ahoj,
v Jave sem si udelal jednoduchy program, ktery spolupracuje s DB. Program obsahuje pristupove udaje k MYSQL. Pomoci Build project v NetBeans jsem vytvoril .jar soubor a zajimalo by me jestli je mozne provest dekompilaci a precist prihlasovaci udaje k DB? Pripadne jak muzu ochranit program proti precteni kodu
-
Ahoj,
ano je to mozne. Dokonce mi to prijde jednodussi nez u jinych jazyku.
Radek
-
Jak tedy muzu aplikaci ochranit proti precteni kodu
-
jedina moznost je obfuskace, tedy zakryti
vetsinou se to dela tak ze udaje nemas ulozene jako text, ale "vyrabis" je nejakym silenym vypoctem. diky tomu se pak nedaji najit v kodu jako textova konstanta, ne li jako pribaleny soubor vedle
porad ale nezabranis nekomu aby tvoji aplikaci zapnul, a pak zastavil ve chvili kdy mas ty udaje poskladany v pameti, a tam si je v pohode precet
-
Proč by uživatel toho programu neměl mít možnost přečíst přihlašovací údaje do DB? Naopak tyto údaje bývají součástí konfiguračního souboru, aby byly snadno nastavitelné.
-
Nehci aby uzivatele zbytecne zkouseli hrabat na DB...
-
otazka je co je "jednoduchy program" a jak zdatnemu uzivateli se ma zabranit v ziskani hesla
jestli je to nejaky udelator, ktery do db leze pres jdbc, tak si v pripade neschudnosti dekompilace heslo odchytim cestou, v jdbc driveru pripadne wiresharkem
z meho pohledu robustni reseni je pro autentikaci do db pouzit ssl klientsky certifikat ulozeny na tokenu (ten lze fyzicky umistit i mimo serverovnu + logovat pristupy)
-
Tak to musis mezi ne a databazi dat nejakou aplikacni vrstvu, kterou mas pod palcem ty (aka software as a service). Coz asi zase neni to, co chce zakaznik.
-
Omezit danemu uzivateli pristup jen na nekolik stored procedures a zadne tabulky
-
V DB mam tabluku kde radek nese vsechno info u uzivateli ....
Coz pokud nejaky koumak program stahne a otevre dostane plne kredence a muze cokoliv ...
Takze asi nejlip udelat usera a specialni tabulku jenom s username a passwd v md5hash
-
Jar bez obfuskace jde dekompilovat zpetne vicemene do stejne podoby jako byl zdrojak.
Nicmene retezec je stejne vzdy citelny, i kdyby byl kod obfuskovan.
Jak bylo psano, muzes nejak prevest retezec na nejaky kodovany tvar, ten mit ulozeny v promene/ konfiguracnim souboru
a pri cteni ho rozkodovat. To je ale jenom zabrana pred ctenim pro nejvic nahodne vetrelce. Ten dekodovaci algoritmus je porad soucasti kodu klienta a i kdyby pouzival nejakou metodu komunikujici se servrem, vzdycky musi program to heslo k databazi nakonec znat a to heslo bude v pameti pocitace - pujde ziskat.
Spavny postup (smer) pro zabezpecene pripojeni do databaze (pro mysql asi tezko, pro pgsql jo) by byl (napriklad) nasledujici:
- klient ma uzivatele, ktery nema pravo cist tabulky, ale jen volat ulozene procedury
- klient se musi na databazi autentizovat uzivatelskym jmenem a heslem (ruzne od uctu k db pripojeni), databaze nastavi uzivatelskou session cookie na dane pripojeni
- klient vola ulozene procedury (na nic jineho nema pravo), ty nejprve zkontroluji prava pro daneho prihlaseneho uzivatele
-
soubor jar je normální zip a dá se rozbalit. Pokud máte proměné jako login a heslo v kódu jako text, pravděpodobně budou v nezměněné formě i .class souboru a nebude nutná ani dekompilace. Která je u javy snadná, takže není důvod ji neudělat tak jako tak.
-
Takze asi nejlip udelat usera a specialni tabulku jenom s username a passwd v md5hash
md5 urcite ne. Mozna scrypt?
-
Ahoj,
v Jave sem si udelal jednoduchy program, ktery spolupracuje s DB. Program obsahuje pristupove udaje k MYSQL. Pomoci Build project v NetBeans jsem vytvoril .jar soubor a zajimalo by me jestli je mozne provest dekompilaci a precist prihlasovaci udaje k DB? Pripadne jak muzu ochranit program proti precteni kodu
Čí .jar se snažíš rozlousknout?
Nehledáš náhodou v db nechtěně odeslanou url nějaké fotky?
;)
-
Ahoj,
problem je asi v navrhu aplikace. Pokud mam aplikaci s nativnim pristupem do DB, musim resit veskere zabezpeceni v databazi. To znamena ze kazdy uzivatel musi mit svuj login a pokud nema mit pravo cist urcita data tak se to musi osetrit pravama na tabulkach. Napriklad jeden ERP system mel primy login na MSSQL, a tak pro kazdeho uzivatele se musel zakladat ucet na serveru. Nasledne byly veskere operace kontrolovany trigery a nektere veci slo resit jen pres ulozene procedury. Proste autentizacni/autorizacni logika je na strane DB.
Naopak v <dosadte oblibenou serverovou technologii> je zvykem mit jedno prihlaseni do db a nasledne v palikaci si resit veskerout autentizaci. Proto staci v DB tabulka, jmeno a heslo(nejlepe nejaky hash primo na hesla). Uzivatel nema moznost se pripomo pripojit na datbazi a tak muze aplikace omezit veskery pristup a pripadne nektere akce povolit/zakazat.
Radek
-
wtf je to za architekturu... aha jednoducha aplikacia
staci postavit proxy jdbc driver (je ich asi stodesat) a uz vidiet dopyty a skoro urcite aj loginy / hesla
ak nie, tak ako radil predrecnik, bootne sa wireshark a obfuskacia je v zadeke
a v tomto rezime je radost s firewallmi a portami (mysql 3306) je bonusom
-
Tak tak, pokud je třeba zabránit přístupu do DB, tak buď je třeba přistupovat přes nějaký aplikační server, který bude jediný mít přístup DB (resp. ti klientské programy mít přístup nebudou) a klientské programy budou komunikovat jen s tím aplikačním serverem. Ten pak ověřuje veškeré přístupy a např. uživateli nedovolí vylistovat hesla všech uživatelů. Omezení bych rozhodně doporučoval dělat whitelistem, tedy povolit jen to, co je potřeba - neboli implementovat metody, které budou dělat to, co klient potřebuje. A nebo tuto aplikační logiku nacpat přímo DB (což bych osobně ve většině případů moc nedoporučoval - zvláště v případě, že nejde o nějakou vnitropodnikovou aplikaci, kde jsou uživatelé pod kontrolou).
V opačném případě je hacking hodně snadný. Pak samozřejmě záleží na tom:
- jaké náklady jsou potřeba pro rozumné zabezpečení (je nesmysl investovat milion Kč do zabezpečení, když hrozí max. škoda 100 Kč)
- jakou motivaci mají uživatelé něco hackovat (čím větší prospěch z toho bude mít, tím víc se bude snažit)
- co hrozí v případě, že to někdo hackne (když získá max. např. tajenku křížovky, tak se asi toho zase tak moc neděje)
Na znalostech uživatelů moc nezáleží, protože spousta lidí minimálně zná někoho, kdo to zvládne levou zadní a poradí, jak na to. Případně se poptá někde na webovém fóru.
Jediná výjimka by byla, pokud by uživatel neměl plný přístup k počítači, kde běží ta klientská aplikace. Tak by se hackingu dalo tak nějak bránit, ale stejně by to představovalo velké riziko.
-
Nehci aby uzivatele zbytecne zkouseli hrabat na DB...
Tak se zaměř na řešení skutečného problému, to jest "zabránit uživatelům v hrabání do DB", a ne na pseudoproblém, který stejně v Javě moc dobře vyřešit nejde. Mohl bys třeba zvážit to, že tvůj uživatel nemá v databázi žádná práva na tabulky, jen práva na uložené procedury, které uvnitř udělají skutečnou práci. Pak si může uživatel do DB hrabat jak chce, a přesto změny, které jsi mu neumožnil, neudělá.