NOVINKA - Online rekvalifikační kurz Java programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
NOVINKA – Víkendový online kurz Software tester, který tě posune dál. Zjisti, jak na to!

Diskuze: iframe - ochrana proti cizímu použití.

V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.

Aktivity
Avatar
katrincsak
Člen
Avatar
katrincsak:21.2.2016 23:00

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.2.2016 23:00
Avatar

Člen
Avatar
Odpovídá na katrincsak
:21.2.2016 23:05

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.2.2016 23:05
 
Nahoru Odpovědět
21.2.2016 23:05
Avatar
katrincsak
Člen
Avatar
Odpovídá na
katrincsak:21.2.2016 23:25

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.2.2016 23:25
Avatar
Odpovídá na katrincsak
Neaktivní uživatel:22.2.2016 0:36

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

Nahoru Odpovědět
22.2.2016 0:36
Neaktivní uživatelský účet
Avatar
katrincsak
Člen
Avatar
Odpovídá na Neaktivní uživatel
katrincsak:22.2.2016 8:49

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.2.2016 8:49
Avatar
Odpovídá na katrincsak
Neaktivní uživatel:22.2.2016 10:00

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
22.2.2016 10:00
Neaktivní uživatelský účet
Avatar
katrincsak
Člen
Avatar
Odpovídá na Neaktivní uživatel
katrincsak:22.2.2016 10:20

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.2.2016 10:20
Avatar
Odpovídá na katrincsak
Neaktivní uživatel:22.2.2016 19:06

Š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.2.2016 19:06
Neaktivní uživatelský účet
Avatar
Odpovídá na katrincsak
Neaktivní uživatel:22.2.2016 21:23

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í
+2,50 Kč
Řešení problému
Nahoru Odpovědět
22.2.2016 21:23
Neaktivní uživatelský účet
Avatar
Odpovídá na Neaktivní uživatel
Neaktivní uživatel:22.2.2016 21:35

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.2.2016 21:35
Neaktivní uživatelský účet
Avatar
katrincsak
Člen
Avatar
Odpovídá na Neaktivní uživatel
katrincsak:29.2.2016 4:12

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

 
Nahoru Odpovědět
29.2.2016 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.