Avatar
katrincsak
Člen
Avatar
katrincsak:

Zdravím,

potřeboval bych poradit, nebo říci vaše způsoby jak chráníte iframe proti cizímu použití. Z jistých důvodů je zcela nezbytné, aby appka běžela na jiném serveru a rád bych to zabezpečil. Zatím stále přemýšlím, ale nic extra mě nenapadá.

Zatím jediná věc mě napadá generovat klíče, jenže ten klíč se samozřejmě musí přeposlat s dotazem. Takže lze to odchytat a zneužívat.

Je možné třeba nějak vynutit používání iframe pouze z dané IP/domain ?

 
Odpovědět 21. února 23:00
Avatar
Michal Vašíček
Tým ITnetwork
Avatar
Odpovídá na katrincsak
Michal Vašíček:

Možná by tvůj problém mohl vyřešit header Access-Control-Allow-Origin s hodnotou nastavenou na doménu, na které bude iframe. Nevím to ale jistě. Každopádně je hovadina, aby appka běžela na jiném serveru, vždy se to dá nějak vyřešit.

Editováno 21. února 23:05
Nahoru Odpovědět 21. února 23:05
Příspěvek může obsahovat stopy arašídů, sarkasmu a sóji.
Avatar
katrincsak
Člen
Avatar
Odpovídá na Michal Vašíček
katrincsak:

Z bezpečnostních důvodů to bohužel není možné, na víc lze appku tímto způsobem nabízet třetí straně. Kouknu se na to, děkuju.

 
Nahoru Odpovědět 21. února 23:25
Avatar
Jiří Gracík
Redaktor
Avatar
Odpovídá na katrincsak
Jiří Gracík:

Co se snažíš udělat? Btw, neřešilo by to šifrování?

Nahoru Odpovědět 22. února 0:36
Creating websites is awesome till you see the result in another browser ...
Avatar
katrincsak
Člen
Avatar
Odpovídá na Jiří Gracík
katrincsak:

Snažím se udělat to, že daný iframe bude moct použít jen ten kdo bude moct. To šifrování je docela široký pojem, nějak nevím co přesně máš na mysli ?

Ještě jsem se nedostal k tomu co psal Michal Vašíček.

Každopádně zatím mám 2 řešení za pomocí generování klíčů. A to buď v různých intervalech a nebo po každém vyžádaném procesu. Respektive "Server A" vytvoří klíč, pošle se metodou GET v URL a "Server B" zkontroluje předaný klíč zda je skutečně v DB :) A buď se teda v případě generování klíče u každého procesu ihned i smaže a nebo by se klíče postupně jen mazali v případě intervalu.

 
Nahoru Odpovědět 22. února 8:49
Avatar
Taskkill
Redaktor
Avatar
Odpovídá na katrincsak
Taskkill:

Pouzij radsi POST, ne ze by to bez dalsich bezpecnostnich opatreni melo velkej vyznam, ale pokud skutecne bezpecnost, tak se vsim vsudy, GET na klice, hesla, tokeny nepouzivej.

 
Nahoru Odpovědět  +2 22. února 10:00
Avatar
katrincsak
Člen
Avatar
Odpovídá na Taskkill
katrincsak:

Obávám se že to možné není, když potřebuji některé parametry přenést z jednoho serveru na druhý. Možná mám jen nedostatek znalostí v přenášení dat za pomocí POST. Samozřejmě se nepřenáší žádná tajná data, spíše je potřeba jen ověřit zdroj. Což samozřejmě, když si ho ověřím já parametrem přes GET, tak to pak kdokoliv.

Problém je, že v tom iframe jaksi nějak nefiguruje adresa webu, ale uživatele, který to zrovna vidí :/ . Takže není možné ani dát fixně IP v htaccess/apache

 
Nahoru Odpovědět 22. února 10:20
Avatar
Jiří Gracík
Redaktor
Avatar
Odpovídá na katrincsak
Jiří Gracík:

Šifrováním u webů se většinou rozumí použití ssl. Nebývá to složité na nastavení ani zařízení a má to mnoho výhod. Takhle ti kdokoliv může sniffovat citlivé informace a třeba ukrást ten tvůj klíč.

Nahoru Odpovědět 22. února 19:06
Creating websites is awesome till you see the result in another browser ...
Avatar
Taskkill
Redaktor
Avatar
Odpovídá na katrincsak
Taskkill:

Hele: pokud mas povoleny GET na serveru hodne bych se divil, kdyby neumel POST je to naprosto superuzivana vec, pouziva se na vsecko, posles tim cokoliv a implementacne se prilis od toho GETu IMO nelisi, takze zapatrej jestli to opravdu neni mozne, pripadne osvetli situaci - proc ne.

Jak rika Jirka, kdyz nasadis ssl dost si pomuzes.

Nepotrebujes nikde nic napevno davat, ja to chapu tak, ze mas ty na SVEM serveru appku, webovou, budiz, nechces ji dat z ruky, nechces dovolit aby si ji zakaznik nasadil na svuj server, pak by videl tvoje zdrojaky. Rozumim, tak to udelas tak, ze klientovi zalozis trebas databazi u sebe na serveru, jemu na server nasadis jen client appku, a v prohlizeci bude mit velkej iFrame (pres cely okno myslim)... okey ..co ted.. jednak to zasifrujes pres to sslko, at je sranda, pak udelas to, ze bude mit u tebe uzivatelske jmeno a heslo, prihlasovaci udaje budou na serveru u nich, peclive zasifrovany a schovany, kdyz spusti appku, nejdriv se po nem bude JEHO server dozadovat prihlaseni, uspesne se prihlasi a tim ziska pristup na SVUJ server, (tohle se hodi, kdyz budes chtit ukazat, ze jejich data jsou v bezpeci) pak JEHO server vygeneruje token (klic) podle tebou urceneho algoritmu, prida k nemu prihlasovaci udaje co jsou na serveru zasifrovany a posle je na TVUJ server, ten zkontroluje ze user existuje, ze ma record v DB atd... zkontroluje vygenerovanej token (klic) vsechno posilas pres https takze je vsechno secure .. okey jdeme dal, reknes okey .. je to nas uzivatel, ma platnej token, vygenerujes SVUJ vlastni token, posles ho JEMU spolu s adresou na iFrame ... server na JEHO strane to obdrzi, posle klientovi adresu na iFrame a token, ten si bud drzi JEHO server nebo ho posle klientovi, nebo nedejboze to zabezpecis jeste tak, ze JEHO server kazdymu klientovi vystavi vlastni bezpecnosti token a bude se o nej starat sam, no to je fuk, to si pores, ale zpet k story, takze uzivatel obdrzel do browseru iFrame je spokojenej a vesele si klika, patla a kdovico jeste, ty tokeny muzou mit ruznou zivotnost, ale pokud to tak bude, tak bych to resil s tim serverem, jakoze, TVUJ server se kazdou hodinu, kterou bude user aktivni dozada JEHO serveru na novej token, znova si ho zkontroluje atd atd... hele, realne sem to takle nikdy nenasazoval, jen rikam, ze by me to takhle napadlo ... co ty na to?

Akceptované řešení
+20 Zkušeností
+1 bodů
Řešení problému
 
Nahoru Odpovědět 22. února 21:23
Avatar
Taskkill
Redaktor
Avatar
Odpovídá na Taskkill
Taskkill:

EDIT:
Doplnim, ze jsem pravdepodobne vubec nepoukazal na fakt, ze url do toho iFramu muze byt prave dynamicky generovane, tedy, kdyz vyprsi cas a nedojde k autentizaci, tak to url uz nebude pouzitelne a server (TVUJ) zahlasi chybu, nebo naopak, pokud se na to url pokusi pripojit nekdo navic, taky mu to nepujde atd... tohle by teda mohla byt dost dobra ochrana samo o sobe, pokud ti nejde o enterprise level bezpecnosti tak vlastne jenom tohle a ssl pro klidny spani by pravdepodobne udelalo dobre svoji praci.

 
Nahoru Odpovědět 22. února 21:35
Avatar
katrincsak
Člen
Avatar
Odpovídá na Taskkill
katrincsak:

Budu se muset podívat na to SSL ;-)

 
Nahoru Odpovědět 29. února 4:12
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 11 zpráv z 11.