[JS] [AJAX] [SSL] Inloggen met AJAX in modal beveiligen

[TheNephilim]

Een project waar ik op dit moment aan werk; een webshop in Wordpress, heb ik een login modal. Deze modal komt in beeld bij het inloggen op de website. Dat inloggen verloopt nu gewoon doormiddel van Ajax en dat werkt prima. Echter worden de gebruikersnaam en wachtwoord gewoon in plain-text verstuurd. Een gewone loginpagina maken en die voorzien van https is een idee, maar misschien zijn er andere oplossingen.

De website maakt gebruik van jQuery en de jQuery.ajax verteld mij:

Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.

Dat zou dus betekenen dat de pagina waarop de Ajax request gedaan word, ook https moet zijn om in de request zelf https te kunnen gebruiken. Op Google kan ik niks vinden waarmee het op te lossen zou zijn, in ieder geval niet op 'standaard' consumenten hosting.

Wat zijn nu goede alternatieven? Zelf gaan encrypten of zijn dat tegenwoordig geen goede oplossingen meer? Of moet ik echt naar een 'dedicated' loginpagina toe waar ik gebruik maak van https?

--- Encrypted AJAX wrapper ---
Een oplossing als deze ziet er bijvoorbeeld wel netjes uit, maar de key... Die kun je niet veilig houden aan de client side.

--- jCryption ---
Een complete library, voor jQuery. Ziet er erg goed uit, maar ik moet nog even uitzoeken wat ik nu aan de serverkant allemaal kan doen.

http://www.jcryption.org/

Een mooie oplossing als je zelf host, maar aangezien proc_open nodig is voor deze oplossing, gaat het niks worden.

Misschien kunnen we om het proc_open probleem heen werken door gebruik te maken van de php functies voor openssl. Op de server waar het project straks live gaat, is openssl aanwezig in php, dus dat moet toch lukken!

[ Voor 26% gewijzigd door TheNephilim op 04-12-2013 11:39 ]

[RobIII]

TheNephilim schreef op woensdag 04 december 2013 @ 11:06:
een webshop in Wordpress
[...]
Een gewone loginpagina maken en die voorzien van https is een idee

Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).

[ Voor 4% gewijzigd door RobIII op 04-12-2013 11:42 ]

[TheNephilim]

RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).

De hele webshop op https? Nou misschien de grote jongens zoals Amazon, maar veel webshops die alleen maar https gebruiken zie ik niet vaak. Bij bol.com bijvoorbeeld, als je daar naar de loginpagina gaat, kom je pas in het https protocol terecht.

[azerty]

RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).

StartSSL durft af en toe wel eens problemen geven. Er zijn genoeg andere (Comodo PositiveSSL bijv.) die ook al een enkel domein voor een tientje per jaar (zelfs iets minder) van een certificaat voorzien...

[jopitan]

RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).

StartSSL wil wel nog eens als een niet gecertificeerde certificaat op Firefox weergegeven worden. Dat heb ik helaas meerdere keren meegemaakt. Uiteindelijk kost een certificaat nog maar 10 euro per jaar voor een single subdomain certificaat. Alles rewriten in de htaccess naar https://www. en het is klaar.
Daarnaast kosten wildcard certificaten ook geen drol (rond de 70 euro, kan vast nog wel ergens goedkoper worden gevonden)

TheNephilim schreef op woensdag 04 december 2013 @ 11:47:
[...]


De hele webshop op https? Nou misschien de grote jongens zoals Amazon, maar veel webshops die alleen maar https gebruiken zie ik niet vaak. Bij bol.com bijvoorbeeld, als je daar naar de loginpagina gaat, kom je pas in het https protocol terecht.

Dan zijn die webshops die jij bezoekt allemaal kak. Daarnaast is het naar mijn inziens een schande als je als webshop geen certificaat hebt die ervan verzekerd dat je gegevens niet zomaar door een ander persoon even worden bekeken door een MiTM.
Wie een webshop start en te gierig is om 10 euro te investeren is een webshop niet waard.

[ Voor 31% gewijzigd door jopitan op 04-12-2013 11:58 ]

[TheNephilim]

wsitedesign schreef op woensdag 04 december 2013 @ 11:51:
[...]


StartSSL durft af en toe wel eens problemen geven. Er zijn genoeg andere (Comodo PositiveSSL bijv.) die ook al een enkel domein voor een tientje per jaar (zelfs iets minder) van een certificaat voorzien...

Dat is ook geen probleem, de certificaten zijn inderdaad niet duur meer. Zou dat moeten, dan is dan geen probleem.

Ik vraag me alleen af of er geen andere oplossingen zijn die eenzelfde resultaat geven. Als het teveel werk is, of niet veilig genoeg; prima dan gewoon een loginpagina met https evenals natuurlijk de pagina waarop je registreert en accountgegevens bekijkt. Het lijkt me alleen nodig om alle requests, ook het bekijken van producten, helemaal onder https uit te voeren.

[RobIII]

TheNephilim schreef op woensdag 04 december 2013 @ 11:56:
Als het teveel werk is

Certificaatje aanvragen + installeren: totaal: 0.5 uur.
Devwerk om allerlei vage constructies te bouwen: veel meer dan 0.5u en dan reken ik het onderhouden van die code door de jaren heen etc. nog niet eens mee.

TheNephilim schreef op woensdag 04 december 2013 @ 11:56:
of niet veilig genoeg

Als je zelf gaat knutselen moet je iig. verdomd goed weten wat je aan 't doen bent...

TheNephilim schreef op woensdag 04 december 2013 @ 11:56:
Het lijkt me alleen nodig om alle requests, ook het bekijken van producten, helemaal onder https uit te voeren.

Wat kost het je als je alles over HTTPS trekt? Tenzij je nu al last hebt van een server die op z'n tenen loopt of als je een enorm serverpark a-la FB, Twitter, Google, BOL.com etc. hebt: boeie. Voor de gemiddelde webshop van de bakker op de hoek is de "extra load" compleet verwaarloosbaar.

[ Voor 8% gewijzigd door RobIII op 04-12-2013 12:00 ]

[TheNephilim]

RobIII schreef op woensdag 04 december 2013 @ 11:59:
[...]

Certificaatje aanvragen + installeren: totaal: 0.5 uur.
Devwerk om allerlei vage constructies te bouwen: veel meer dan 0.5u en dan reken ik het onderhouden van die code door de jaren heen etc. nog niet eens mee.


[...]

Als je zelf gaat knutselen moet je iig. verdomd goed weten wat je aan 't doen bent...

Dat is ook zo, ik ga eens vragen of de hoster een certificaat kan regelen en hoeveel dat moet kosten. De hosting overigens is verder niet in mijn beheer, dat heeft de klant allemaal.

[...]

Wat kost het je als je alles over HTTPS trekt? Tenzij je nu al last hebt van een server die op z'n tenen loopt of als je een enorm serverpark a-la FB, Twitter, Google, BOL.com etc. hebt: boeie. Voor de gemiddelde webshop van de bakker op de hoek is de "extra load" compleet verwaarloosbaar.

Ga dat nog even bekijken dan, als het goed is zijn er niet veel aanpassingen nodig. Dus dat zou geen probleem moeten zijn.

[Barryvdh]

Je moet alleen nog wel vaak een extra IP hebben, wat ook weer extra kosten met zich mee kan brengen.

[RobIII]

Barryvdh schreef op woensdag 04 december 2013 @ 13:42:
Je moet alleen nog wel vaak een extra IP hebben, wat ook weer extra kosten met zich mee kan brengen.

True; ik heb geen idee wat de prijzen tegenwoordig zijn (we draaien al jaren op eigen bakken in colo) maar laat zo'n IP ≈ € 2,- per maand kosten (gebaseerd de eerste drie hits van een simpele google query)... En een beetje ontwikkelwerk van een junior €75,- p/u. Voor de prijs van 1 uur devwerk (en daar ga je geheid (veel) meer overheen) kun je 3 jaar dat extra IP betalen.

[ Voor 4% gewijzigd door RobIII op 04-12-2013 14:57 ]

[TheNephilim]

RobIII schreef op woensdag 04 december 2013 @ 14:42:
[...]

True; ik heb geen idee wat de prijzen tegenwoordig zijn (we draaien al jaren op eigen bakken in colo) maar laat zo'n IP ≈ € 2,- per maand kosten (gebaseerd de eerste drie hits van een simpele google query)... En een beetje ontwikkelwerk van een junior €75,- p/u. Voor de prijs van 1 uur devwerk (en daar ga je geheid (veel) meer overheen) kun je 3 jaar dat extra IP betalen.

Ik heb (via de klant) gevraagd wat de kosten zijn voor zo'n certificaat. Hij komt op 6 euro (excl. btw) per maand, waar ik uitga van de complete oplossing. Er nog maar even een mailtje achteraan gedaan om te vragen welk type certificaat het is, maar dat moet allemaal wel goed komen.

Overigens, € 75,00/u voor een (junior) Wordpress developer lijkt me best veel Maar goed, je hebt wel gelijk; je krijgt het met https allemaal sneller en efficiënter voor elkaar.

De pagina's waarvoor ik in ieder geval https wil gebruiken zijn; inloggen, registreren, mijn account en afrekenen.

[Barryvdh]

Bij mijn hoster vragen ze 30 euro per jaar voor een extra IP en 42.50 per jaar voor een SSL certificaat (+installatie), dus dat is ongeveer hetzelfde. Ligt er natuurlijk ook aan wat voor certificaat je wil, via https://www.sslcertificaten.nl/ heb je zelf al vanaf 10 euro een certificaat van Comodo, inclusief extra subdomein (www. + zonder ww).

[RobIII]

TheNephilim schreef op woensdag 04 december 2013 @ 15:06:
De pagina's waarvoor ik in ieder geval https wil gebruiken zijn; inloggen, registreren, mijn account en afrekenen.

Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan ".

TheNephilim schreef op woensdag 04 december 2013 @ 15:06:
Overigens, € 75,00/u voor een (junior) Wordpress developer lijkt me best veel

Laat 't € 50 of € 60 zijn dan. God, weet ik veel waar een junior tegenwoordig voor over de balie gaat...

[ Voor 28% gewijzigd door RobIII op 04-12-2013 15:46 ]

[TheNephilim]

Barryvdh schreef op woensdag 04 december 2013 @ 15:43:
Bij mijn hoster vragen ze 30 euro per jaar voor een extra IP en 42.50 per jaar voor een SSL certificaat (+installatie), dus dat is ongeveer hetzelfde. Ligt er natuurlijk ook aan wat voor certificaat je wil, via https://www.sslcertificaten.nl/ heb je zelf al vanaf 10 euro een certificaat van Comodo, inclusief extra subdomein (www. + zonder ww).

Hier krijg ik als optie deze voorgeschoteld: http://www.thawte.nl/nl/producten/ssl123+certificaten/. Dat lijkt me een certificaat zonder groen label.

Op dezelfde website tref ik ook http://www.thawte.nl/nl/producten/web+server+certificaten/ aan, dat is er wel een met groen label als ik me niet vergis.

-- Edit ---

Ik vergis me, http://www.thawte.nl/nl/p...b+server+ev+certificaten/ biedt wel een groen label. De hiervoor genoemde niet.

Nouja, dat laat ik dan verder aan de klant over. Dat groene label is wel mooi en professioneel, maar niet per se nodig.

RobIII schreef op woensdag 04 december 2013 @ 15:43:
[...]

Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan ".

Duidelijk! Als het https gebeuren eenmaal is opgeleverd ga ik wel eens kijken wat het doet, als ik alles op https zet. Als dat werkt en er geen problemen optreden laat ik het zo, uitzetten en alleen op bepaalde pagina's kan altijd.

[...]

Laat 't € 50 of € 60 zijn dan. God, weet ik veel waar een junior tegenwoordig voor over de balie gaat...

Hahaha, nou wij gooien onze websites hier meestal op projectbasis over de schutting, het uurtarief was heel lang € 45, maar dat gaan we vanaf 1 januari 2014 maar eens naar € 50 tillen

[ Voor 3% gewijzigd door TheNephilim op 04-12-2013 16:11 ]

[RobIII]

TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Hier krijg ik als optie deze voorgeschoteld: http://www.thawte.nl/nl/producten/ssl123+certificaten/. Dat lijkt me een certificaat zonder groen label.

Op dezelfde website tref ik ook http://www.thawte.nl/nl/producten/web+server+certificaten/ aan, dat is er wel een met groen label als ik me niet vergis.

Ik weet niet wat je met "groen label" bedoelt (ik neem aan dat je 't niet hebt over 't milieu) maar ik ga er van uit dat je EV certificaten (Extended Validation) bedoelt. Voor je probleem ('t versleuteld versturen van je login gegevens) is wel/geen EV niet heel erg spannend en in je code merk je d'r geen fluit van dus dat is, los van de prijs, weinig relevant.

TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Nouja, dat laat ik dan verder aan de klant over. Dat groene label is wel mooi en professioneel, maar niet per se nodig.

Juist.

TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Duidelijk! Als het https gebeuren eenmaal is opgeleverd ga ik wel eens kijken wat het doet

Je kunt gewoon met een self-signed (-of gratis startssl-) certificaatje ontwikkelen/testen; als je 't maar niet uitrolt naar productie

TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Als dat werkt en er geen problemen optreden laat ik het zo, uitzetten en alleen op bepaalde pagina's kan altijd.

Tipje dan nog: The Protocol-relative URL voor je (externe) resources gebruiken (waar mogelijk)

TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Hahaha, nou wij gooien onze websites hier meestal op projectbasis over de schutting, het uurtarief was heel lang € 45, maar dat gaan we vanaf 1 januari 2014 maar eens naar € 50 tillen

Again: geen idee wat 'n devver tegenwoordig extern kost; ik werk al jaaaaren voornamelijk (lees: 99.5%) intern en dus "niet facturabel". De tijd die ik wél facturabel ben heb ik geen idee wat ze voor me rekenen (en don't care either ).

[ Voor 12% gewijzigd door RobIII op 04-12-2013 16:26 ]

[TheNephilim]

RobIII schreef op woensdag 04 december 2013 @ 16:15:
[...]

Ik weet niet wat je met "groen label" bedoelt (ik neem aan dat je 't niet hebt over 't milieu) maar ik ga er van uit dat je EV certificaten (Extended Validation) bedoelt. Voor je probleem ('t versleuteld versturen van je login gegevens) is wel/geen EV niet heel erg spannend en in je code merk je d'r geen fluit van dus dat is, los van de prijs, weinig relevant.

Met een 'groen label' bedoel ik dit:



Dat is inderdaad een EV certificaat

[...]

Tipje dan nog: The Protocol-relative URL voor je (externe) resources gebruiken (waar mogelijk)

Yup, die gebruik ik al voor de JS libs van Google's CDN, maar handig inderdaad!

[...]

Again: geen idee wat 'n devver tegenwoordig extern kost; ik werk al jaaaaren voornamelijk (lees: 99.5%) intern en dus "niet facturabel". De tijd die ik wél facturabel ben heb ik geen idee wat ze voor me rekenen (en don't care either ).

Haha ja zolang je elke maand een riant bedrag op je bankrekening krijgt bijgeschreven, zou ik me er ook niet druk om maken

[RobIII]

TheNephilim schreef op woensdag 04 december 2013 @ 16:43:
Haha ja zolang je elke maand een riant bedrag op je bankrekening krijgt bijgeschreven, zou ik me er ook niet druk om maken

Hence de "don't care"

[ Voor 5% gewijzigd door RobIII op 04-12-2013 16:47 ]

[iH8]

TheNephilim schreef op woensdag 04 december 2013 @ 11:06:
Dat zou dus betekenen dat de pagina waarop de Ajax request gedaan word, ook https moet zijn om in de request zelf https te kunnen gebruiken. Op Google kan ik niks vinden waarmee het op te lossen zou zijn, in ieder geval niet op 'standaard' consumenten hosting.

"Pak maar een certificaat" is geen oplossing van de foutmelding die je post maar gewoon een simpele workaround. Je krijgt die melding omdat je content van een ander domein probeert te laden en of je dat nu via HTTP óf HTTPS maakt geen fluit uit. Je probeert een crossdomain request uit te voeren en dat mag nu eenmaal niet van je browser zonder de juiste headers meegeeft en terugkrijgt.

Request-headers:

code:

Origin:http://example.org

Response-headers:

code:

Access-Control-Allow-Origin:http://www.example.org

Zolang als je controle over je backend hebt en dus de request goed beantwoordt met de juiste headers dan heb je van die bovenstaande melding geen last. Je moet alleen wel opletten met mixed content https://developer.mozilla...ocs/Security/MixedContent maar dat is net zoals certificaten hier momenteel niet on topic.

Je had wat meer op google kunnen vinden als je gezocht had op: crossdomain request, dan was je uitgekomen bij CORS (cross origin resource sharing) http://www.w3.org/TR/cors/

[RobIII]

iH8 schreef op woensdag 04 december 2013 @ 20:10:
"Pak maar een certificaat" is geen oplossing van de foutmelding die je post

Euh, dat is 't wél:

TheNephilim schreef op woensdag 04 december 2013 @ 11:06:
Dat inloggen verloopt nu gewoon doormiddel van Ajax en dat werkt prima. Echter worden de gebruikersnaam en wachtwoord gewoon in plain-text verstuurd.

Zoals 'ie het nu heeft werkt 't prima, maar hij wil de gebruikersnaam/wachtwoord niet in plain text versturen.

iH8 schreef op woensdag 04 december 2013 @ 20:10:
Een gewone loginpagina maken en die voorzien van https is een idee

Die foutmelding krijgt 'ie omdat 'ie de login naar https probeert te versturen vanaf een http pagina:

Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.

iH8 schreef op woensdag 04 december 2013 @ 20:10:
Dat zou dus betekenen dat de pagina waarop de Ajax request gedaan word, ook https moet zijn om in de request zelf https te kunnen gebruiken.

TheNephilim schreef op woensdag 04 december 2013 @ 11:47:
De hele webshop op https?

Precies de vinger op de zere plek. En de makkelijkste, goedkoopste en beste oplossing is gewoon simpelweg die pagina waarvandaan de Ajax request komt ook vanaf HTTPS serveren. Voila.

Waar jij "content van een ander domein probeert te laden" vandaan haalt zie ik niet

[ Voor 6% gewijzigd door RobIII op 04-12-2013 23:05 ]

[iH8]

RobIII schreef op woensdag 04 december 2013 @ 23:04:
[...]

Ik kan geen touw aan die quotesessie vastknoppen, ik weet niet wat je probeert te zeggen maar quote me wel goed en anders niet. Ik doe nog wel een poging:

Gaan we weer. Bottomline. Hij was er zelf al achter dat de simpelste oplossing met HTTPS te gaan werken. Daardoor krijgt hij een foutmelding. De oorzaak daarvan is dat de cross origin policy dat blockt. Of hij nu een ander protocol, subdomein of domein aanspreekt mag gewoon niet.

Jullie workaround: complete site op HTTPS zetten. (plus certificaat erbij verkopen)
Echte oplossing: CORS headers goed zetten.

Zo verdienen er jammer genoeg teveel hun geld, ik niet gelukkig. Ik dacht dat er hier gehamerd werd op mensen echt dingen leren en op het goede pad zetten. De eerst volgende keer als die jongen via ajax met een api oid op een ander sub/domein contact maakt krijgt ie dezelfde foutmelding en weet ie nog niets. Alles op HTTPS zetten en certificaatje kopen is het opgelost denkt ie dan. Catching.

[pedorus]

Een wachtwoord invullen op een site die deels uit http:// is opgebouwd is veelal te onveilig, dat maakt een man-in-the-middle attack namelijk wel erg eenvoudig... Hoe kun je weten dat er niet een stukje javascript je wachtwoord steelt dan?

Ik heb startssl ergens draaien, en zie geen problemen ermee, ook niet met enige normale versie van Firefox, dus een certificaat kost echt 0 euro, wat een verkopers hier..

[Hydra]

In HTTP2 worden alle verbindingen versleuteld. Lijkt me dat dat een vrij goeie hint is in wat de juiste oplossingsrichting is.

[samo]

RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).

Ben ik het niet helemaal mee eens. Transacties en persoonsgegevens wil je via SSL aanbieden, maar productaanbod hoeft helemaal niet over SSL.
Oplossing is dus wel inderdaad SSL...

[RobIII]

samo schreef op donderdag 05 december 2013 @ 09:16:
[...]

Ben ik het niet helemaal mee eens. Transacties en persoonsgegevens wil je via SSL aanbieden, maar productaanbod hoeft helemaal niet over SSL.

Het hoeft niet inderdaad:

RobIII schreef op woensdag 04 december 2013 @ 15:43:
Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan ".

Gewoon de weg van de minste weerstand, snelste/goedkoopste oplossing; "tenzij je een goede reden hebt om 't niet te doen".

iH8 schreef op woensdag 04 december 2013 @ 23:44:
Echte oplossing: CORS headers goed zetten.

Dat is geen echte oplossing maar een workaround voor een situatie waarin je je in de nesten werkt met een same origin policy. Als je de pagina serveert van HTTPS en de Ajax request ook over HTTPS stuurt heb je geen drol te maken met een same origin policy en dus geen probleem en geen gedoe met CORS. Makkelijker dan dat kun je 't niet maken. Dat CORS bestaat is allemaal heel leuk enzo maar is hier, in deze situatie, gewoon een lapmiddel voor iets dat helemaal niet gelapt hoeft te worden als je 't goed doet.

iH8 schreef op woensdag 04 december 2013 @ 23:44:
Zo verdienen er jammer genoeg teveel hun geld, ik niet gelukkig.

Schei uit zeg... De laatste keer dat ik wat verdiende aan dit geneuzel... toen waren de mensen nog zwart-wit

iH8 schreef op woensdag 04 december 2013 @ 23:44:
Ik dacht dat er hier gehamerd werd op mensen echt dingen leren en op het goede pad zetten. De eerst volgende keer als die jongen via ajax met een api oid op een ander sub/domein contact maakt krijgt ie dezelfde foutmelding en weet ie nog niets. Alles op HTTPS zetten en certificaatje kopen is het opgelost denkt ie dan. Catching.

Als CORS de oplossing was geweest had ik 't heus wel aangedragen. Maar dat is het niet. Schijnbaar vind jij van wel; prima. Even goeie vrienden. De tijd zal leren wat de beste les is geweest

[ Voor 105% gewijzigd door RobIII op 05-12-2013 11:10 ]

[Hydra]

iH8 schreef op woensdag 04 december 2013 @ 23:44:
Echte oplossing: CORS headers goed zetten.

Welke headers zorgen er dan voor dat een HTTP Origin een HTTPS API mag bevragen dan?

RobIII schreef op donderdag 05 december 2013 @ 09:35:
Gewoon de weg van de minste weerstand, snelste/goedkoopste oplossing; "tenzij je een goede reden hebt om 't niet te doen".

"Jamaar, NIH!"

[ Voor 36% gewijzigd door Hydra op 05-12-2013 10:08 ]

[Barryvdh]

Welke headers zorgen er dan voor dat een HTTP Origin een HTTPS API mag bevragen dan?

Zie dit diagram: http://www.html5rocks.com...cors_server_flowchart.png

[ Voor 5% gewijzigd door Barryvdh op 05-12-2013 10:32 ]

[Hydra]

Dat beantwoord mijn vraag niet. Ik weet prima welke headers er zijn (heb deze week nog een API geimplementeerd), ik vraag welke toestaat dat een HTTP origin een HTTPS api bevraagt.

[Barryvdh]

Hydra schreef op donderdag 05 december 2013 @ 10:21:
Dat beantwoord mijn vraag niet. Ik weet prima welke headers er zijn (heb deze week nog een API geimplementeerd), ik vraag welke toestaat dat een HTTP origin een HTTPS api bevraagt.

Ah sorry.
Maar is dat niet gewoon de Access-Control-Allow-Origin dan? Als je https domein als een unieke 'origin' gezien wordt, moet je het http domein toch toestaan in die header?

[Hydra]

Barryvdh schreef op donderdag 05 december 2013 @ 10:25:
Ah sorry.
Maar is dat niet gewoon de Access-Control-Allow-Origin dan? Als je https domein als een unieke 'origin' gezien wordt, moet je het http domein toch toestaan in die header?

Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.

Ik begrijp dus dat dat niet mogelijk is.

[Barryvdh]

Hydra schreef op donderdag 05 december 2013 @ 10:38:
[...]
[...]

Ik begrijp dus dat dat niet mogelijk is.

Ja tenzij je dus CORS correct toepast, zoals iH8 al aangaf.

[Hydra]

Barryvdh schreef op donderdag 05 december 2013 @ 10:46:
Ja tenzij je dus CORS correct toepast, zoals iH8 al aangaf.

@@%$@. Ik vraag toch specifiek HOE je dat dan doet?

[Barryvdh]

Hydra schreef op donderdag 05 december 2013 @ 11:16:
[...]
@@%$@. Ik vraag toch specifiek HOE je dat dan doet?

Zoals die flowchart al aangaf, moet je bepaalde headers controleren, valideren of het verzoek is toegestaan en een reactie sturen.
Hier wat meer info: http://docs.webplatform.org/wiki/tutorials/using_cors
Hier een voorbeeld implementatie in php: https://github.com/asm89/stack-cors

Maar een simpele versie is, die in simpele cases voldoende is (of dus ipv * het http domein)

code:

header("Access-Control-Allow-Origin: *");

[Hydra]

Dat snap ik dus prima. Mijn vraag is; staat Access-Control-Allow-Origin: http://hatseflats ook die HTTP URL toe als je een HTTPS url benaderd. Gewoon een Ja / Nee / Ik weet het niet vraag dus.

[Barryvdh]

Lijkt me wel dus, aangezien http -> https gezien wordt als crossdomain en dus als een andere origin. Maar dat zei ik ook al in de eerste instantie, en iH8 ook al, dus snap niet waarom je nou zo geïrriteerd raakt.
Ik heb het zelf niet getest, maar probeer het uit zou ik zeggen.

[iH8]

Hedendaagse browsers sturen automatisch de juiste access control headers mee op het moment dat je een XMLHttpRequest uitvoert naar een ander protocol, sub of hoofddomein. Met uitzondering van IE natuurlijk, die doen weer apart met een XDomainRequest. Alle frontend frameworks waar ik meegewerkt heb handelen die verschillen keurig voor je af. Je kunt controleren of je juiste headers verstuurt in je browser dev tools. Je hoort dan deze request header te zien:

Request vanaf http://example.org naar https://example.org

code:

Origin: http://example.org
Host: example.org

Die request moet je beantwoorden je met de juiste access control headers ander krijg je de foutmelding uit de OP. Dat kun je doen op server, host of applicatie niveau. Bijvoorbeeld bij Apache in de virtualhost of htaccess:

code:

<ifModule mod_headers.c>
Header always set Access-Control-Allow-Origin: "http://example.org"
</ifModule>

Of zoals Barryvdh als gaf, op applicatie niveau in PHP:

code:

header("Access-Control-Allow-Origin: http://example.org");

Of die header verzonden wordt kun je weer mooi zien in je dev tools bij de response headers

Response van https://example.org naar http://example.org

code:

Access-Control-Allow-Origin: http://example.org

Et voila, als de topicstarter nu zijn eerste oplossing jquery en ajax probeert krijgt hij die foutmelding niet meer én heeft ie wat geleerd. Dan gaat hij wel tegen andere dingen aan lopen maar daar had ik het niet over. Natuurlijk voelt een user zich tien keer veilig als ie altijd en overal HTTPS in z'n balk ziet. Is een heel andere discussie en offtopic. En je hoeft geen certificaat te kopen, die kun je keurig zelf signen, again offtopic.Een IP aanschaffen zelfs. Hele discussie gaat overal over behalve over het feit dat de starter zijn foutmelding verkeerd interpreteert, dat wilde ik even corrigeren.

Op grotere projecten ga je steevast tegen dat soort dingen aanlopen. Frontend van mijn huidige project haalt resources van meerdere subdomeinen, vier tileservers, een geojson server, image server etc. Iemand die niet zou weten wat die foutmelding inhield zou zeker aandragen dat alle servers maar naar het hoofddomein verplaatst moeten worden, dan is het ook opgelost.

[Hydra]

@iH8: bedankt.

Barryvdh schreef op donderdag 05 december 2013 @ 14:34:
Lijkt me wel dus

Ik vraag simpelweg (nieteens aan jou) of iemand met kennis van zaken aan kan geven of dat ook zo werkt of niet. Aan "lijkt me wel" heb ik dus helemaal niks. Ik kan dat zelf niet 'even' testen want ik heb hier geen projecten die iets dergelijks doen. Als je het niet weet, zeg dat dan gewoon, of reageer gewoon niet. Scheelt ons beiden een hoop tijd.

[Barryvdh]

Hydra schreef op vrijdag 06 december 2013 @ 09:22:
@iH8: bedankt.
[...]
Ik vraag simpelweg (nieteens aan jou) of iemand met kennis van zaken aan kan geven of dat ook zo werkt of niet. Aan "lijkt me wel" heb ik dus helemaal niks. Ik kan dat zelf niet 'even' testen want ik heb hier geen projecten die iets dergelijks doen. Als je het niet weet, zeg dat dan gewoon, of reageer gewoon niet. Scheelt ons beiden een hoop tijd.

Ik bedoel alleen maar dat het volgens de beschrijving/specificatie zo zou moeten werken, aangezien het verschil tussen https/http hetzelfde gezien wordt als tussen 2 totaal verschillende domeinen.
Maar heb het even getest met een ajax get/post tussen (hetzelfde) http en https domein, en zonder die header werkt het niet, maar na toevoegen van de allow-origin header met daarin het http domein, werkt het wel

[Anoniem: 111703]

Hydra schreef op vrijdag 06 december 2013 @ 09:22:
Ik vraag simpelweg (nieteens aan jou) of iemand met kennis van zaken aan kan geven of dat ook zo werkt of niet. Aan "lijkt me wel" heb ik dus helemaal niks. Ik kan dat zelf niet 'even' testen want ik heb hier geen projecten die iets dergelijks doen. Als je het niet weet, zeg dat dan gewoon, of reageer gewoon niet. Scheelt ons beiden een hoop tijd.

Ik kan bevestigen wat Barryvdh zegt. Zolang je serverside headers goed staan en je niet IE5.5 gebruikt () moet je gewoon cross-domain via XHR kunnen werken. Let (nogmaals) op de definitie van cross-domain in dit geval; http://mijndomein.org wordt gezien als een ander domein als https://mijndomein.org.

We gebruiken zelf een applicatie die op https://app.domain.com draait, maar XHR doet naar https://backend.domain.com doet, of zelfs naar https://cname.ofthatdomain.com. In firebug zie je netjes dan ook OPTION requests naar de server lopen (een z.g.n. pre-flight request) waarmee wordt gekeken of de request mag worden gedaan.
Een praktijkvoorbeeld kan ik je helaas niet geven daar de applicatie in kwestie nog in ontwikkeling is.. Maar ik kan je wel melden dat het perfect werkt.

offtopic:
Kan je verder even normaal doen tegen je mede fora-gebruikers? Iets teveel pepernoten gisteren gegeten waardoor je zo opgeblazen doet tegen anderen?

Over de keuze SSL/non-SSL gesproken trouwens: je overhead gaat zitten in HTTP handshakes als je SSL gebruikt, en niet noodzakelijkerwijs in de extra rekenkracht die nodig is om data te versleutelen; die performancehit is niet significant. Mits correct geconfigureerd is er dus niets op tegen om een gehele site op HTTPS te laten draaien, zelfs als er slechts een klein deel (bijvoorbeeld een salesfunnel of een loginpanel) een beveiligde verbinding vereist. Dat geeft het bijkomende voordeel dat de secure-flag van een cookie op true kan worden gezet en deze dus uitsluitend over een versleutelde lijn verstuurd worden en dus niet de ene keer over HTTP en de andere keer over HTTPS.

[ Voor 21% gewijzigd door Anoniem: 111703 op 06-12-2013 19:42 ]

[Hydra]

Anoniem: 111703 schreef op vrijdag 06 december 2013 @ 19:27:
Een praktijkvoorbeeld kan ik je helaas niet geven daar de applicatie in kwestie nog in ontwikkeling is.. Maar ik kan je wel melden dat het perfect werkt.

Goed om te weten. Ben zelf deze week met een API bezig geweest. Die echo's gewoon elke origin request dus die zou dan ook in een dergelijk scenario moeten werken.

offtopic:
Kan je verder even normaal doen tegen je mede fora-gebruikers? Iets teveel pepernoten gisteren gegeten waardoor je zo opgeblazen doet tegen anderen?

Sorry maar ik heb niks aan mensen die op een concrete vraag "ik denk het wel" antwoorden, of eerder, een plaatje dumpen waar niks nieuws in staat. Als ik dan keer op keer moet vragen wat precies bepaalt dat HTTPS-vanaf-HTTP toegestaan is, krijg ik daar geen antwoord op, maar alleen een antwoord op een vraag die ik niet gesteld heb. Reageer dan gewoon niet, scheelt ons beiden tijd

[Anoniem: 111703]

Hydra schreef op vrijdag 06 december 2013 @ 19:44:
Goed om te weten. Ben zelf deze week met een API bezig geweest. Die echo's gewoon elke origin request dus die zou dan ook in een dergelijk scenario moeten werken.

Let er wel op dat je vanuit je applicatie niet HTTP-OPTIONS requests volledig gaat afhandelen maar direct stopt met draaien na het echo-en van de CORS-headers. Onze applicatie was eerst ietwat aan te trage kant met cross-domain requests, maar dat bleek dus te liggen aan het feit dat ook preflight requests gezellig door hele hele dispatch stack heen gingen.

Sorry maar ik heb niks aan mensen die op een concrete vraag "ik denk het wel" antwoorden, of eerder, een plaatje dumpen waar niks nieuws in staat. Als ik dan keer op keer moet vragen wat precies bepaalt dat HTTPS-vanaf-HTTP toegestaan is, krijg ik daar geen antwoord op, maar alleen een antwoord op een vraag die ik niet gesteld heb. Reageer dan gewoon niet, scheelt ons beiden tijd

Van wat ik zie en lees, bieden verschillende mensen je verschillende informatiebronnen aan met verschillende voorbeelden, specificaties, flowcharts en toelichtingen. Je komt zo _onwijs_ geirriteerd over, terwijl mensen je gewoon proberen te voorzien van informatie. Je zal het vast niet zo bedoelen, maar lees je eigen reacties eens terug. Dat kan allemaal vast wel wat vriendelijker.

[TheNephilim]

Als het goed is wordt vandaag het certificaat opgeleverd, dus kan ik er eindelijk mee aan de slag. Nog bedankt voor alle reacties hier, het heeft mij weer een mooi inzicht in verschillende oplossingen opgeleverd.

De webshop staat als sinds vrijdag op de productie omgeving. Nog wel achter een .htaccess met wachtwoord, zodat de klant alles nog even kan checken en we de laatste puntjes op de i kunnen zetten.

[TheNephilim]

De website staat inmiddels online, volledig in https. Wordpress neemt je gedeeltelijk wat werk uit handen en een .htacces lost alle andere losse eindjes op. Hieronder de .htaccess waarvan ik me nog wel even afvraag of dit de juiste volgorde is. Het non-www gedeelte onder het https gedeelte levert problemen op, je krijgt dan de melding dat het certificaat niet geldig is als je de non-www versie in de browser intypt.

code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# www
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Default
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Volgens mij is het nu niet meer mogelijk om de website te bezoeken in http. Je moet https gebruiken en ook alle content word gewoon via https opgehaald. Op deze manier hebben zoekmachines er ook geen moeite meer mee, we moeten namelijk geen duplicate content krijgen en dergelijke.

Tot zover lijkt alles helemaal goed te werken!

[R4gnax]

iH8 schreef op donderdag 05 december 2013 @ 15:05:
Hedendaagse browsers sturen automatisch de juiste access control headers mee op het moment dat je een XMLHttpRequest uitvoert naar een ander protocol, sub of hoofddomein. Met uitzondering van IE natuurlijk, die doen weer apart met een XDomainRequest. Alle frontend frameworks waar ik meegewerkt heb handelen die verschillen keurig voor je af. Je kunt controleren of je juiste headers verstuurt in je browser dev tools. Je hoort dan deze request header te zien:

XDomainRequest werkt alleen cross-domain. Niet cross-protocol scheme. Dus je kunt daarmee niet communiceren tussen HTTP en HTTPS. Wat je wel kunt doen is een iframe openen op een HTTPS url, daarmee communiceren via de postMessage API en op die manier het iframe het request naar de server laten doen.

Ondanks dat er dus voor IE8 en 9 een alternatieve oplossing te verzinnen is, is dit nog steeds niet de juiste oplossing. Maakt niet uit door wat voor hoepels of via wat voor trucjes je via HTTP naar HTTPS wilt posten. CORS, XDomainRequest, postMessage iframes; het maakt allemaal geen ene moer uit, want:

VANAF HTTP NAAR HTTPS POSTEN IS NOOIT VEILIG !!!
Het is eerder al gemeld door iemand anders die er gelukkig ook met zijn gedachten bij is, maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

Als je op een HTTP pagina gegevens invult om via HTTPS versleuteld te versturen dan is dat altijd inherent onveilig. Via een man in the middle aanval op die eerste HTTP pagina kunnen er namelijk al eerder key logging scripts of andere troep toegevoegd zijn en die kunnen dan direct bij de bron, nog voor het wachtwoord versleuteld verstuurd wordt, het al direct oppikken terwijl je het invoert.

[TheNephilim]

R4gnax schreef op woensdag 11 december 2013 @ 20:24:Als je op een HTTP pagina gegevens invult om via HTTPS versleuteld te versturen dan is dat altijd inherent onveilig. Via een man in the middle aanval op die eerste HTTP pagina kunnen er namelijk al eerder key logging scripts of andere troep toegevoegd zijn en die kunnen dan direct bij de bron, nog voor het wachtwoord versleuteld verstuurd wordt, het al direct oppikken terwijl je het invoert.

Niet eens aan gedacht, maar dat is inderdaad meteen een probleem. Dus eigenlijk is inloggen door middel van Ajax nooit een goed idee, tenzij de pagina waarop je dat doet zelf ook https is. Eigenlijk heel logisch natuurlijk, maar daar moet je net even bij stil staan

[RobIII]

TheNephilim schreef op donderdag 12 december 2013 @ 10:21:
[...]


Niet eens aan gedacht, maar dat is inderdaad meteen een probleem. Dus eigenlijk is inloggen door middel van Ajax nooit een goed idee, tenzij de pagina waarop je dat doet zelf ook https is. Eigenlijk heel logisch natuurlijk, maar daar moet je net even bij stil staan

RobIII schreef op woensdag 04 december 2013 @ 15:43:
Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan ".

[ Voor 24% gewijzigd door RobIII op 12-12-2013 11:54 ]

[TheNephilim]

RobIII schreef op donderdag 12 december 2013 @ 11:26:

Haha, de webshop is volledig ondergebracht onder het https protocol

[iH8]

R4gnax schreef op woensdag 11 december 2013 @ 20:24:
het maakt allemaal geen ene moer uit, want:

VANAF HTTP NAAR HTTPS POSTEN IS NOOIT VEILIG !!!
Het is eerder al gemeld door iemand anders die er gelukkig ook met zijn gedachten bij is, maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

iH8 schreef op donderdag 05 december 2013 @ 15:05:
Et voila, als de topicstarter nu zijn eerste oplossing jquery en ajax probeert krijgt hij die foutmelding niet meer én heeft ie wat geleerd. Dan gaat hij wel tegen andere dingen aan lopen maar daar had ik het niet over

Maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

[R4gnax]

iH8 schreef op vrijdag 13 december 2013 @ 14:46:
Maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

Het onmogelijk maken om direct van HTTP naar HTTPS te posten is juist bedoeld om te zorgen dat mensen niet secure gegevens op insecure pagina's in gaan vullen. Het is dus helemaal niet "een ander probleem". Jij komt gewoon met het foute antwoord aan draven, blijft er een eind over door zagen en moet vervolgens toch nog proberen het laatste woord te halen.

[iH8]

Dat jullie willen blijven verkondigen dat het onmogelijk is om HTTPS resources aan te spreken vanaf HTTP moeten jullie helemaal zelf weten. Zegt meer over jullie dan over mij. Ik zeg dat dat wel kan punt. Verder ga ik hier echt niet verder over dimdammen met je. Heel je toon, fontweight, kleurtjes, mijn dialoog af doen met woorden als zagen en doordraven sieren jou, dit topic en GOT echt niet. Fijn weekend!

[Caelorum]

Wow, volgens mij spreekt niemand je tegen over dat het kan. Enige dat hier wordt gezegd is dat het niet de (juiste) oplossing is voor dit probleem.