[megoldva] GET változók elrejtése

Web, mail, IRC, IM, hálózatok

Sziasztok,

Adott egy mail szerver, aminek van egy frankó webmail felület, az auto login is megoldott benne mégpedig valami ilyesmi formában: /Webmail/?username=user&password=user
A problémám az, hogy azt szeretnénk, ha userek a mail szerverre nem tudnák a jelszavukat, hanem egy másik program nyitná meg nekik a mailt a fenti formában. A gond csak az h. ezt a GET requestet valahogyan el kellene rejtenem a felhasználó elől. A frame az picit gagyi megoldás szerintem, php fopen meg nem igazán szereti megnyitni a célt.
Valaki valami ötlet?

Köszi,
Zoli

  • 2028 megtekintés

( _ventura_ v | 2010. 06. 23., sze – 18:14 )

mondjuk elsőnek GET helyett POST ?

Ubuntu 10.04, Thinkpad x60s

Leteszteltem, POST-al nem megy az autologin.
Én is Session-ben csinálnám, de az első tagmondatban már leírtam, hogy "adott a Webmail felület, aminek csak GET-el lehet átadni az username-t és a passwd-t is".
Én valami olyasmire gondoltam h. egy általam összepakolt php fogadja a dolgot valami ilyesmi formában: index.php?param=sajat_kodolas(username,password) és ezt valahogyan továbbpasszolja GET-el a mailszerveren csücsülő webmail felületnek. Ebben csak az a szépséghiba h. ez valami flash-es vacak és a scriptem fopennel nem igazán akar működni (allow_url_fopen=true).
Alternatív lehetőségként még pl. mod_proxy merült fel bennem, csak gőzöm sincsen hogyan kellene megoldani úgy egy get-et, hogy az ne kerüljön be a böngésző címsorába, se mondjuk egy frame src-jébe.

( lopci v | 2010. 06. 23., sze – 20:53 )

Lehet, hogy nem tökéletes, de url encode? Plusz még random zagyvaságok a get kérésbe, és szerintem az r=1 userek ellen jó az. A vérprofi felhasználó meg úgyis megnézi, hogy mit hova irányítasz át (pl. wireshark) és kikeresi a jelszót.

pl. a példáddal ilyen lenne: Webmail/?session=cba478ac468a4ba64a64bdabdf6ad468&hash=62396afb678eefb7bf67fbd6fadfd569fd&%75%73%65%72%3D%75%73%65%72%26%70%61%73%73%3D%75%73%65%72

Persze lehet még fokozni, csak nehogy a szerver visszadobja, hogy heló ez már sok.
Hash, session vagy ilyesmi változónevek megtévesztésre tökéletesek

( NPeete | 2010. 06. 23., sze – 21:26 )

vhogy ajax-al bebűvészkedni egy containerbe a webmail cuccát? akkor a címsorban nem látszanak a paraméterek :)

( foofighter | 2010. 06. 23., sze – 22:16 )

Ha a felhasználók nem tudják a jelszavukat, akkor mi alapján hitelesíted a felhasználókat, hogy csak a saját leveleiket nézzék meg? Más jelszavakkal?

A másik rendszerben(frontend) az adott felhasználóhoz társított, webmailhez tartozó felhasználó-jelszó párossal lekérném az adatokat és a "másik rendszert" közvetítőként(proxy) használva jeleníteném meg a webmailes felüleletet.

Ez adatbázisban két új attribútumot jelenthet a felhasználótörzsben(webmail_username, webmail_password) vagy egy hozzá kapcsolódó (webmail_users) táblát.

( sj | 2010. 06. 23., sze – 22:59 )

/Webmail/?username=user&password=user

Te jo eg....

Btw. single sign-on nem rulez? Mert akkor nem kellene ilyen szornyu modon atadni a cuccot. Arrol nem is beszelve, hogy a web (es proxy) logokban szepen ott lesz az osszes login nev es jelszo....

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

"Te jo eg...."
+sok

De, hogy érdemben is próbáljak hozzászólni:

A - az a rendszer amelyik a webmailt kiszolgálja
B - az a rendszer amelyik átirányít

A 2 rendszer között nincs semmilyen közös háttér szolgáltatás? Közös DB, fájlrendszer, LDAP szolgáltatás? Akkor ott egy bejegyzéssel amit a B rendszer létrehoz, a A rendszer töröl, tisztábban meg tudod oldani.

Viszont ha már mindenáron át kell adni a usernevet és a jelszót URL-ben akkor az egyetlen védhető megoldás ha PKI-val titkosítod.

B - titkosítja a usernevet/jelszót A publikus kulcsával
B - bepakolja az URL-be

A - rendszer kiolvassa és visszafejti.

Ekkor bárki aki hozzáfér az URL-hez, csak a PKI-val titkosított stringet látja, amivel elvileg nem tud mit kezdeni.

azert vedd le a segged, es irass ala valami papirt (de minimum legyen rola email, hogy te elore szoltal), hogy aki ezt megrendelte toled (fonok, whatever, ...) az erti a kockazatot az "autologin"-ban.

Nem is ertem, hogy egyaltalan mi ez az autologin nevu hulyeseg, holott ez a kozelebbrol meg nem nevezett rendszer nyilvanvaloan nem tamogatja...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

A minap már utaltunk rá, hogy az tolerálható, hogy a júzer hülye, ha egyébként profitot termel.
Innen szok jönni az a önellentmondásos igény, hogy a rendszer legyen biztonságos (mert olvastuk az újságban, hogy az fontos), de a júzer, akkor is tudja termelni a profitot, ha elfelejtette a jelszavát, vagy helyből alkalmatlan arra, hogy megjegyezze.
Innen szinten kötelező az autologin.

Nem állítom, hogy itt ez a szitu, de állítom, hogy van ilyen, és még ilyenebb is...

Ott a pont.
A biztonsági kérdések mindig ott borulnak h. usernek termelnie kell a profitot. Nyilván ha fokozzuk a biztonságot, akkor valamit "elvesztünk" pl. be kell írni egy 10 karaktres jelszót, ami napi szinten 10 másodperc és hajjajj, akkor az a munkaidőből elfecsérelt 10 másodperc. Nekünk is van egy látásmódunk (informatika, it biztonság), de a főmanagereknek meg van egy másik látásmódja. A dolog azért dől az ő javukra, mert nem mi parancsolunk nekik általában :)

( cheeky v | 2010. 06. 24., cs – 07:49 )

Ez mekkora balfaszság... Amíg a böngésző tudja a jelszót, addig a user is tudja.
Az ilyesfajta mérhetetlen bugyuta szerencsétlenkedés az elrejtésre inkább szánalmas, mint hatékony.

Tanulj némi biztonságtudatosságot, mielőtt ilyesmivel dolgozol.

Aki meg az ajaxos 5letet mondta, hát annak gratulálok. Remélem, sok ilyen rendszer születik a közeljövőben, akkor mindig lesz munkám, és mindig sikeres is lesz... :-D

Nézd, nem azt kérdeztem h. mi a magán véleményed és nem is azt h. szerinted ez jó v. nem jó. Adott a rendszer amibe nem tudunk belenyúlni, adott a feladat h. be kéne lépni automatikusan bele egy másik programból.
Tessék oldd meg hihetetlennagyszekuritiguru, de ma délután 2-ig kész kell legyen... :)
Értem én az álláspontodat, ez így konkrétan bazi nagy szar, de nem ez az érdekes, hanem hogy a feladat készen legyen. Mivel csak local lan-on elérhető a megoldás és mivel ha a jelszó kikerül, az sem óriási baj, csak alapból nem akarják elárulni az illetékeseknek, mert szebb/jobb/egyszerűbb az autologin, így nem fogom halálraparázni magam ha csak r=1 user elől "eldugjuk" a jelszót.
Azt is értem h. erre alapozni nem lehet biztonságot, de nem is a biztonságot alapozzuk mi erre, pusztán az a célja a dolognak h. működjön az autologin, de azért az url-ben ne legyen már benne a passwd úgy h. csak le kelljen olvasni.
Az ajaxos ötlet nem hülyeség, mert arra amire nekem kell tökéletes.
Ezzel a hozzáállással nem is kéne user a hálózatodba, plusz mindent neked kéne fejleszteni, hiszen a linux is tele van ismert/ismeretlen biztonsági réssel, ott mi garantálja h. nincs valami hasonló "fasza" megoldás?

Ha mindenképp egy ilyen hulladékkal kell dolgoznod, akkor proxy-zd meg az alkalmazást, a célalkalmazást csak a proxy érhesse el, és a megfelelő proxy-hoz történő authentikáció után a proxy töltse ki az alkalmazás felé a kívánt jelszót. Így a user nem találkozik a jelszavával, sőt, a jelszó a szerver hálón belül marad, a kliens network-re ki sem kerül.

Innentől a proxy authentikációd lehet kerberos, ntlm, valami sso megoldás, whatever.

A probléma pontosan azzal a hozzáállással van, hogy "csak működjön a dolog", így gyakorlatilag fölösleges bármit is tenni az r=1 userek ellen.

A hozzáállás részét nem minősíteném, ahogy elnézem, nem az én hozzáállásommal van itt probléma.

Pontosan ez lett a megoldása a dolognak.
Én csak arra próbáltam felhívni a figyelmedet, hogy odáig oké, hogy Te úgy gondolod ahogy. Én is pontosan így gondolom, de egy már megvásárolt cuccban nem tudok fejleszteni, innentől teljesen felesleges azt szajkózni h. hahh, ez de szar, innen indultunk, tudjuk h. szar.
A workaroundra vonatkozott inkább a kérdés. Hozzáállásról meg annyit még zárójelben h. ezt a válaszodat látva, ez a helyesebb hozzáállás. Azért "akadtam" meg egy kicsit a poston, mert az a része a dolognak h. szar, az már részemről lerágott csont volt, megvizsgáltuk hogyan lehetne még megoldani, de ez az egyetlen megoldás maradt. Ha annyira szarul gondolkodnék, akkor még elrejteni sem próbálnám ezeket az infókat, nem hogy proxyt építsek elé és így próbáljam védeni a "szarból épített várat..."

"csak local lan-on elérhető a megoldás"
FAIL. Ilyen szempontbol nem szabad megbizni a local lan-ban sem. De ha mar mindenkepp meg kell csinalni, en minden dokumentacioba leirnam, hogy ez igy biztonsagi problemakat rejt magaban.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( mhmxs v | 2010. 06. 24., cs – 08:57 )

a másik felület egy iframbe töltse bele a webmail url-jét és akkor a böngésző címsorába nem látszik. Hátránya, ha a forrást megnézi kifigyelheti még mindig.

Nem, letezik autologin, ugy hivjak, hogy SSO, es tobbfele technologia van ra. A legegyszerubb a Kerberos, de weboldalak kozt inkabb az OpenSSO-szeru technologiak divnak. Egy helyen bejelentkezel, ott kapsz egy authentikacios token-t/ticket-et, es azzal lepsz be masutt - jelszo nelkul.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.