SSL im Warenkorb

[Inktron]

Moin !

Folgendes Problem:

Google hat mein Merchant-Center Konto gesperrt. Begründung : In unserem
Shop findet eine “unverantwortliche Erfassung und Nutzung von Daten” statt.

Hintergrund : Klickt man oben recht auf das Warenkorb-Symbol öffnet sich das
kleine Fenster mit der Auwahl “Warenkorb anzeigen” und “Zur Kasse”

Mit einem Klick auf “Zur Kasse” (statt “Warenkorb anzeigen”), gelangt man zum
2.Bestellschritt mit der Auswahl “Bestellen ohne Registrierung”, “Persönliches
Kundenkonto eröffnen” und “Ich bin bereits Kunde”.

Der Aufhänger ist nun, dass diese Seite nicht SSL-gesichert ist.

(Klickt man statt auf “Zur Kasse” auf “Warenkorb anzeigen” gelangt man ebenfalls
zum 2.Bestellschritt - jedoch ist dieser dann SSL-gesichert)

Kann mir jemand einen Tipp geben, in welchem Template entsprechende Änderungen
vorgenommen werden müssten ?

Shop. ist CE 4.8.7 http://www.led.inktron.de

Besten Gruß
Stefan

[Inktron]

Hat sich erledigt.

Falls jemand das gleiche Problem hat :

Im Template minibasket.tpl ziemlich am Ende

<a href="[{ oxgetseourl ident=$oViewConf->getSelfLink()|cat:"cl=payment" }]"
class="submitButton largeButton">[{ oxmultilang ident="CHECKOUT" }]</a>
[{else}]
<a href="[{ oxgetseourl ident=$oViewConf->getSelfLink()|cat:"cl=user" }]"
class="submitButton largeButton">[{ oxmultilang ident="CHECKOUT" }]</a>

“getSelfLink” in “getSslSelfLink” ändern.

[marco.steinhaeuser]

Hallo Stefan,

vielen Dank für die Rückmeldung!
Dabei dürfte es sich um einen Bug handeln. Um diesen ein für alle Mal zu beheben, könntest Du ihn bitte entweder in den Bugtracker eintragen oder (nachdem Du die Lösung kennst) gleich als Pull Request einreichen?

Danke und Gruß

[wolkenkrieger]

Marco, was spricht eigentlich dagegen, HTTP komplett ad acta zu legen und den gesamten Shop zu verschlüsseln?

Funktionseinschränkungen gibt es keine (mein Server reagiert bei der Sub, auf der der Shop läuft, nur auf Port 443 … Port 80 wird per Indianer knallhart umgebogen) und Kosten entstehen für das Zert mitlerweile auch nicht mal mehr zwangsweise (wir haben vor wenigen Tagen auf “Let’s encrypt” umgestellt und das läuft absolut problemlos!).

Evtl. wäre das mal was für das nächste major?

[marco.steinhaeuser]

Du brauchst ja nur die config.inc. php ändern. …

[wolkenkrieger]

[QUOTE=Marco Steinhaeuser;180051]Du brauchst ja nur die config.inc. php ändern. …[/QUOTE]

Ja, das ist mir schon klar

Aber die Unterscheidung zwischen HTTP und HTTPS schon in der config (und in den Templates und wer weis sonst noch wo) birgt immer wieder Fehlerpotenzial, wie man hier im Forum sieht und wäre dem Grunde nach gar nicht mehr nötig - also eine potenzielle Fehlerquelle komplett ausgeschaltet.

[MCC]

Hallo zusammen,

die Praxis, nur Teilbereiche des Shops zu verschlüsseln, sehe ich auch kritisch.
Auf jeder Seite des Shops - auch auf unverschlüsselten - gibt es oben das Dropdown mit der Anmeldemaske. Bei einer “man in the middle”-Attacke könnte der Angreifer auf der unverschlüsselten Seite z.B. das Ziel der Anmeldung im Formular austauschen und so an die Login-Daten kommen.
Die Anmeldeseite selbst ist im Footer ohne https verlinkt (“Konto”) und alle verschlüsselten Seiten kann man auch unverschlüsselt aufrufen (also z.B. verlinken und angreifen).

Schon seit Anfang des Jahres zeigt Firefox in Nightly und Developer Edition bei unverschlüsselten Seiten mit Passwort-Feld das “Schloss” in rot.
https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/

Insecure passwords

Der Anhang zeigt, wie das im Oxid-Demoshop aussieht.

Ich schließe mich wolkenkrieger an: Die Option der Teilverschlüsselung sollte aufgegeben werden.

Viele Grüße
MCC

PS: Ist ja mein erster Post hier, nachdem ich schon lange mitlese, daher eine kurze Vorstellung: Bin Entwickler und habe in den letzten Jahren recht viel mit Oxid gearbeitet. Habe über diverse Module die Shops an die Wünsche der Kunden angepasst und individuelle responsive Templates umgesetzt.

[marco.steinhaeuser]

Hallo,

die Teilverschlüsselung ist nach wie vor eine Option: Es gibt nach wie vor die Meinung, dass SSL-Verschlüsselung zum Performance-Bottleneck werden kann.

@MCC: Du liegst richtig, wenn Du sagst, dass ein rotes Schlösselein beim Aufruf des Formulars angezeigt werden könnte. Allerdings ist es an dieser Stelle noch kein Problem, weil die Daten dort noch nicht abgeschickt wurden. Erst, wenn die Daten übertragen werden, kann es eine MITM geben.

Wie wir alle wissen, gibt es nun mit letsencrypt einen geeigneten CA-Service, der quasi kostenlos alle Webseiten über https ausliefern lässt. Allein einige exotische Browser scheinen das noch nicht verstanden zu haben:

Marco Steinhäuser (marcosteinhaeus)

Wer also komplette SSL-Verschlüsselung haben möchte, richtet sich das über die config.inc.php ein. Wird es irgendwo im Template falsch behandelt, ist es ein Bug.

Gruß

[vanilla_thunder]

Wir mussten ebenfalls wegen Google und EHI die Shops komplett verschlüsseln. Ich glaube, es ist nur die Frage der Zeit, bis Google die globale verschlüsselund erzwingt.

[MCC]

@Marco Steinhaeuser: Dass Login-Felder auf unverschlüsselten Seiten eben doch ein Problem sind, wird von Mozilla in den oben geposteten Links erläutert. Die Seite, die das Passwort-Feld enthält, kann manipuliert werden. Ich zitiere es mal:

@"Mozilla"

Anything on a non-secure page can be manipulated by a Man-In-The-Middle (MITM) attacker. The MITM can use a number of mechanisms to extract the password entered onto the non-secure page. Here are some examples:
[ul]
[li]Change the form action so the password submits to an attacker controlled server instead of the intended destination. Then seamlessly redirect to the intended destination, while sending along the stolen password.[/li][li]Use javascript to grab the contents of the password field before submission and send it to the attacker’s server.[/li][li]Use javascript to log the user’s keystrokes and send them to the attacker’s server.[/li][/ul]

Davon abgesehen dürfte das “rote Schlösselein” für die Besucher wenig vertrauenserweckend wirken. Ich denke nicht, dass Shopbetreiber das wollen.

Die Performance-Argumentation im Bezug auf https dürfte überholt sein. https://istlsfastyet.com/

[KaiNeuwerth]

@MCC: Die Attacken, die Mozilla dort aufführt, sind aber keine “Man in the middle attacks” sondern XSS (Cross-Site-Scripting) Attacken. Damit werden Javascripts von fremden Servern in der Seite eingeschleust. Wenn diese auch über HTTPS aufgerufen werden, werden sie vermutlich trotzdem ausgeführt und man kann selbst bei einer SSL-Verbindung verwundbar sein, denn auf deinem Client ist ja alles wieder unverschlüsselt. SSL schützt nur die Verbindung zwischen den Hosts, also wenn du z.B. ein Formular abschickst oder generell einen Request an den Server absendest.

Davon abgesehen dürfte das “rote Schlösselein” für die Besucher wenig vertrauenserweckend wirken. Ich denke nicht, dass Shopbetreiber das wollen.

Ja, da gebe ich dir natürlich Recht.

[MCC]

Beschreibung einer MITM-Attacke zum Einschleusen von JS:

Your login form posts to HTTPS, but you blew it when you loaded it over HTTP

[KaiNeuwerth]

An Einschleusen von JS über einen Proxy hab ich gar nicht gedacht, aber klar macht Sinn bei einer MITM-Attacke, good point! Hast mich überzeugt

[vanilla_thunder]

Aber ist das ein Problem des Shops, wenn die Besucher über dubiose proxies surfen?
Diesen Artikel habe ich schon vor 2 Jahren gelesen und ich verstehe durchaus das Problem, aber wie die Saturn Mitarbeiter immer so sagen: “das ist nicht meine Abteilung” wenn der Kunde bei sich irgendwas einstellt, was ihm schadet

[wolkenkrieger]

[QUOTE=vanilla thunder;180083]Aber ist das ein Problem des Shops, wenn die Besucher über dubiose proxies surfen?[/QUOTE]

Nein, natürlich nicht … aber wenn wir als Betreiber des Shops die technischen Mittel haben, um ein derartiges Kundenrisiko zu minimieren, sollten wir die meiner Meinung nach auch nutzen.

Im Bedarfsfall können wir dann nämlich ruhigen Gewissens sagen, dass auf unserer Seite keine Lücken bestanden.

[MCC]

Es braucht keine “dubiosen Proxies”, um Opfer einer solchen Attacke zu werden.
Es genügt ein offenes WLAN, in das sich jemand mit einem kleinen Gerät eingeklinkt hat. Oder vielleicht einer der vielen offenen Hotspots, die wir zukünftig haben werden.

Über die Sicherheit in öffentlichen Netzen:

Here’s Why Public Wifi is a Public Health Hazard – Matter – Medium

edit: Noch eine Ergänzung:
Im Falle der Oxid-Teilverschlüsselung braucht es noch nicht einmal ein eingeschleustes Script. Es genügt, den Traffic auf http umzubiegen. Oxid antwortet dann im Klartext und man kann einfach mitlesen.

[keywan.ghadami]

Ich zitiere aus:

@MCC;180086

Maybe Better If You Don’t Read This Story on Public WiFi | by Matter | Matter | Medium

Within 20 minutes he’s obtained the login details, including passwords for my Live.com, SNS Bank, Facebook, and DigiD accounts.

Da hilft es nicht mehr das Loginformular zu schützen (das übrigens in vielen Shops im Menü oder im footer zu finden ist).
Das einzige was dagenen hilft ist allen klar zu machen nur noch SSL zu verwenden überall. Alles andere ist unsicher:

„• Use SSL sitewide. Don’t offer anything over http. Instead, any connection via http should immediately redirect to the main site’s landing page via https.”
web application - Guidance for implementors of HTTPS-only sites (Server side) - Information Security Stack Exchange

[schaumb]

Sorry wenn ich den Thread nochmal vorhole…

Es wurde ja bereits erwähnt, dass wenn ich den kompletten Shop auf https umstellen will, nur die config.inc.php zu ändern brauche.

Aber was muss ich genau in die config.inc.php eintragen, damit ich das erreiche:

So sieht es im Moment aus:

$this->sShopURL = 'http://www.deineshopurl.de'; 
$this->sSSLShopURL  = 'https://www.deineshopurl.de';   
$this->sAdminSSLURL = 'https://www.deineshopurl.de/admin';          

Reicht es, wenn ich die base url auch einfach mit https definiere? Also:

$this->sShopURL = 'https://www.deineshopurl.de'; 

[andoreen]

Jupp und Du brauchst ein Zertifikat. Dein Hoster bietet sowas in aller Regel an.

[patchwork.de]

sinnvoll ist es in der .htaccess eine Weiterleitung einzubauen, sonst ist der Shop sowohl unter http als auch unter https erreichbar

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