[PHP] Automatisch inloggen op webmail

[Verwijderd]

Ik heb:

1. Website (eigen beheer)
2. Webmail programma (RoundCube: eigen beheer, maar andere server/domeinnaam)

Op de Website zou ik graag een button maken, waarmee ik door kan klikken naar het Webmail programma. Hierbij zou ik echter het inloggen over willen slaan.

Ik heb gezocht op:

• cURL
• Cookie cloning

cURL
Door gebruik te maken van cURL zou ik alles vervolgpagina's van het webmailprogramma ook via cURL moeten laten lopen. Simpelweg, omdat de sessie die PHP toebedeeld krijgt, niet doorgegeven kan worden aan de website gebruiker. (toch?) Dit zou imo wel een extreme opgave worden voor een relatief eenvoudige oplossing.

Cookie cloning
Vanaf domein A schijnt het niet mogelijk te zijn om succesvol een cookie te setten die domein B gebruikt.

Kortom: hoe kan ik het inloggen voor de gebruik automatiseren. De gebruikersnaam/wachtwoord voor de webmail is altijd hetzelfde, ongeacht de gebruiker op de website.

[ Voor 3% gewijzigd door Verwijderd op 16-07-2008 16:33 ]

[sky-]

Kan je dat niet via javascript doen? Gewoon een form submitten door die button met de gegevens van de form erin. (Wel dezelfde <input> namen houden en dan de target verwijzen naar login form van het webmail gedeelte)

Eventueel zou je de login gegevens zelfs op "hidden" kunnen zetten, tja.. Super veilig is het niet maar het is een begin.. Wel handig icm een login oid

[ Voor 26% gewijzigd door sky- op 16-07-2008 16:58 ]

[Niekk]

Of het kan weet ik niet.
Je zit met een aantal problemen als je cURL neemt:
Men logt in op je website,
browsed beetje rond
en klikt dan op de button "log in op webmail".
Als dit is wat je bedoelt zit je met het probleem dat je een heel onveilig systeem hebt als jij zomaar iemands wachtwoord weet en daarmee kan inloggen (Je gaat me nu niet vertellen dat het in een cookie staat ofzo, dit zie ook regelmatig. Al dan niet gehashed, zie plain-text.info )

Cookie sharing heb ik geen verstand van. Maar het zou wle moeten kunnen, maar dan moet je precies dezelfde cookies gebruiken als dat je gebruikt op je eigen website.

Hoe zou ik het oplossen ?
Een random hash genereren, die koppelen aan IP-adressen en gebruikersnamen (in een database). Een POST/GET/COOKIE meesturen naar het inlog app, en dan in de webmail app een extra check inbouwen:

PHP:

// Pseudocode
if(men_wil_met_knop_inloggen_en_niet_via_formulier) {
    if(check_hash_in_db()) { // dit kan ook in 1 if, met de && operator. Maar ik zou het zo doen, dan kan je de vershillende errors loggen.
        log_persoon_in();
    } else {
        die("hackert ?");
    }
} else {
    die("hackert ?");
}

Nogmaals zoiets heb ik nog nooit gedaan, en heb er dus ook niet erg lang overnagedacht. Het kan dus zijn dat ik iets over het hoofd zie.

Kortom: hoe kan ik het inloggen voor de gebruik automatiseren. De gebruikersnaam/wachtwoord voor de webmail is altijd hetzelfde, ongeacht de gebruiker op de website.

Daarmee bedoel je toch niet dat ik, "Niek" een account naam "Niek" heb en dus mijn wachtwoord "Niek" zou zijn ?
Edit: Ik hoop dat ik je probleem goed begrijp

[ Voor 15% gewijzigd door Niekk op 16-07-2008 18:19 ]

[pedorus]

Hoe je dit precies moet implementeren hangt nogal af van wat je webmail-server nodig heeft, en welk beveiligingsniveau je wilt. De oplossing hierboven met een willekeurige hash is redelijk ok lijkt me. Waarschijnlijk heb je op de webserver en de client al zo'n willekeurige hash tot je beschikking, namelijk de phpsessionid.

Een wat meer uitgewerkt voorbeeld van de pseudocode hierboven (evt moet het ip ook worden doorgegeven natuurlijk):

PHP:

$h=$_POST["h"];
if ((preg_match("/^[a-z0-9]{32}$/",$h) && 
    ($username=file_get_contents('https://webserver.nl/getusername.php?h='.$h))) {
    performlogin($username); //set cookie
} else {
    logerror(...);
}
redirecttobase();

Het keyword is hier "single sign-on" en er zijn natuurlijk ook veel professionelere oplossingen voor. Idealiter word bijvoorbeeld de authorisatie door aparte server(s) op een apart (sub)domein geregeld.

[Patriot]

Ik kan met enige zekerheid zeggen dat de laatste twee mensen voor mij niet begrepen wat de TS bedoelt.

@TS: Wat je moet doen is een formulier aanmaken met dezelfde velden die RoundCube nodig heeft. In plaats van gewoon textinput-velden, maak je de benodigde velden hidden. Je geeft die velden standaard de waarde die ze nodig hebben en je bent klaar. Ik denk dat je op deze manier aanzienlijk verder komt.

[pedorus]

Ja, natuurlijk kom je dan verder in termen van onveiligheid... De methode met een automatisch gepost formulier zorgt er oa voor dat:

• Op de server, of als een cookie op de client het echte wachtwoord bewaard moet worden. Gewoonlijk worden op de server alleen hashes opgeslagen, en op de client al helemaal niks. (Hier kun je nog een oplossing maken trouwens waarbij het wachtwoord gedeeld word opgeslagen in client en server, maar dat is ook ongebruikelijk en lastig.)
• Je iemands wachtwoord kan stelen als deze is ingelogd op de site en zijn PC onbeheerd laat, of via onveilig wireless verbinding maakt.
• Als op de webserver pagina's van derden worden gehost, of als er ergens een XSS-lek zit(bijna altijd het geval), je met javascript wachtwoorden geautomatiseerd kan stelen.

Dit is altijd een beetje een afweging. Het simpelweg gebruiken van sessionid's ipv een aparte random hash is dat ook. Dat zorgt ervoor dat als de webmailserver gekraakt wordt, sessies van de webserver ook gekraakt kunnen worden. (Aangezien beide toch al met hetzelfde wachtwoord werken, leek me dit niet heel erg hier.)

[ Voor 15% gewijzigd door pedorus op 17-07-2008 09:52 ]

[flashin]

De meeste php proxy's zijn op basis van cURL als ik me niet vergis, kijk daar eens naar, dan hoef je bijna niks zelf te doen (vervolglinks e.d. worden autoatmisch aangepast).

Wil je per se met roundcube werken trouwens? Want als je met IMAP werkt (lijkt me wel) kun je ook je eigen client schrijven natuurlijk of 1 of andere OS PHP client implenteren in je software.

[Patriot]

pedorus schreef op donderdag 17 juli 2008 @ 09:44:
Ja, natuurlijk kom je dan verder in termen van onveiligheid... De methode met een automatisch gepost formulier zorgt er oa voor dat:

• Op de server, of als een cookie op de client het echte wachtwoord bewaard moet worden. Gewoonlijk worden op de server alleen hashes opgeslagen, en op de client al helemaal niks. (Hier kun je nog een oplossing maken trouwens waarbij het wachtwoord gedeeld word opgeslagen in client en server, maar dat is ook ongebruikelijk en lastig.)
• Je iemands wachtwoord kan stelen als deze is ingelogd op de site en zijn PC onbeheerd laat, of via onveilig wireless verbinding maakt.
• Als op de webserver pagina's van derden worden gehost, of als er ergens een XSS-lek zit(bijna altijd het geval), je met javascript wachtwoorden geautomatiseerd kan stelen.

Dit is altijd een beetje een afweging. Het simpelweg gebruiken van sessionid's ipv een aparte random hash is dat ook. Dat zorgt ervoor dat als de webmailserver gekraakt wordt, sessies van de webserver ook gekraakt kunnen worden. (Aangezien beide toch al met hetzelfde wachtwoord werken, leek me dit niet heel erg hier.)

Zo, wat een gedurfde opmerking! Volgens jou zit in elk systeem een XSS-lek!?

De username/wachtwoord combinatie voor de webmail staat op een plek die sowieso pas bereikbaar is op het moment dat je ingelogd bent. De combinatie (zoals te lezen staat in de OP) is voor iedere gebruiker hetzelfde. Op het moment dat iemand het eerste gebruikerssysteem heeft gekraakt, heb je sowieso wel een probleem. Met het kraken van dat systeem kunnen ze hoogstwaarschijnlijk meer dan met de webmail-login die ze dan krijgen.

[Niekk]

Nu begrijp ik nog niet wat de topic starter wil ... Wat is nu precies de bedoeling ? Ik heb een voorbeeld uitgewerkt in pseudo-code, en kreeg later van iemand anders te horen dat je toch iets anders bedoeld ? Graag wat uitgebreidere / beterbegrijpbare taal dan

@ Patriot: ik ben het wel een beetje met hem eens, op heel veel websites zie je dat ze vatbaar zijn voor XSS. Dan hebben we het lang niet altijd over beginners (beginnende programmeurs). Ik ken zelfs een php site die zo lek is als een mandje, en dan echt heel lek:

• De mogelijkheid om in het admin forum te kijken met een beetje kennis van zaken (php, ik geef een hint: hidden formfields)
• Het editten van berichten die niet van jou zijn (ook hidden formfields)
• Het posten van topics in het admin forum (ook hidden formfields)
• Wachtwoorden als simpele md5 opgeslagen in cookies (beetje php kenner, dus genoeg op die website, weet het bestaan van plain-text
• XSS vatbaar

Dus: Er zijn inderdaad heel veel sites die daar vatbaar voor zijn Het probleem van XSS is meestal dat als je er achter komt dat je er vatbaar voor bent, iedereens cookie is gejat oid.

[ Voor 9% gewijzigd door Niekk op 19-07-2008 18:12 ]