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.
Člen
Zobrazeno 11 zpráv z 11.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
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.
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.
Co se snažíš udělat? Btw, neřešilo by to šifrování?
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.
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.
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
Š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íč.
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?
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.
Zobrazeno 11 zpráv z 11.