Frage:
Ist es obligatorisch, https auf der E-Commerce-Website zu haben?
Harlandraka
2013-04-05 16:03:11 UTC
view on stackexchange narkive permalink

Ich habe gesehen, dass einige E-Commerce-Skripte auch ohne SSL ausgeführt werden können, aber jeder empfiehlt, sie zu aktivieren, um vertrauliche Daten zu schützen.

Ich habe gerade eine Website mit einem E-Shop-Link gesehen, wenn ich Klicken Sie darauf. Mein Browser sagt, dass das Sicherheitszertifikat nicht zuverlässig ist. Wenn ich auf "Weiter zur Website" klicke, wechselt es zu http.

Ist es obligatorisch, ssl in einem Shop zu aktivieren?

Sieben antworten:
Thomas Pornin
2013-04-05 16:34:13 UTC
view on stackexchange narkive permalink

Wenn Sie kein HTTPS verwenden, sondern nur HTTP, dann:

  • Sie werden gehackt; Kreditkartennummern werden während des Transports gestohlen und Kunden verklagen Sie in Vergessenheit geraten.
  • Sie würden sowieso irgendwann gehackt, das sind die vielen Websites. Selbst wenn der Hacker auf eine andere Weise eingegeben wurde, zeigt die Post-Mortem-Analyse den Mangel an SSL, und dies sieht wirklich schlecht aus.
  • Sie verlieren Kunden . Viele potenzielle Kunden geben ihre Kreditkartennummer nicht ein, da das beruhigende Bild des Vorhängeschlosses fehlt. Sie werden stattdessen auf der Website eines Mitbewerbers einkaufen.

Sie sind also nicht gesetzlich dazu verpflichtet, HTTPS zu verwenden. Wenn Sie dies nicht tun, wird Ihr Unternehmen scheitern. Open Business-Wettbewerb ist der darwinistischen Auswahl ziemlich ähnlich: Die Schwachen sterben.


Bearbeiten: @ XzKtos Kommentar zeigt, dass ich nicht ganz klar war: Das SSL-Bit ist Wird für die eigentliche Transaktion benötigt, wenn Bankwerte (z. B. Kreditkartennummern) über das Internet übertragen werden. Das ist der, über den ich spreche. Wenn die Site Zahlungsdetails aufzeichnet (damit Sie zurückkehren und erneut kaufen können, ohne die Kreditkartennummer erneut einzugeben), muss die Schaltfläche "Jetzt kaufen" auch SSL-geschützt sein (um zu vermeiden, dass ein Angreifer in Ihrem Konto darauf "klickt") Name). Der Rest der Site muss nicht unbedingt SSL-geschützt sein, obwohl Site-weites SSL oft noch eine gute Idee ist (es ist viel einfacher, als herauszufinden, welche Teile der Site geschützt werden müssen und welche Teile weggelassen werden können ).

Vielleicht bin ich ein seltsamer Kunde, aber ich habe kein Problem damit, von Websites zu kaufen, die kein SSL verwenden, aber ein externes Zahlungssystem verwenden. Darüber hinaus würde ich lieber von einer Website kaufen, die kein SSL verwendet, sondern externe Zahlungen verwendet, als von einer wenig bekannten Website, die SSL und ein internes Zahlungssystem verwendet. Ich glaube auch nicht, dass die Nichtverwendung von SSL etwas mit dem Hacken der Site zu tun hat. SSL schützt den Server nicht, sondern die Kunden. Vielleicht ändern Sie "Sie werden gehackt" in "Kunden können gehackt werden"? Wie auch immer, keine Ablehnung, aber die Antwort ist aufgeschlossen, imho.
Diese Antwort berücksichtigt auch nicht, dass Sie mehr als nötig unter SSL für Ihre Benutzer stellen müssen, sodass das Auswählen von Seiten noch komplexer wird. Solange die Übermittlung vertraulicher Informationen über HTTPS erfolgt, muss die Seite, auf der sie sich befindet, nicht vorhanden sein - außer dass der Browser dem Benutzer mitteilt, dass Sie sich nicht auf einer gesicherten Site befinden.
Vielen Dank, gibt es ein Gesetz, das bei gestohlenen Daten aufgrund unsicherer Zahlungen angewendet werden kann?
@Harlandraka: Das würde von vielen Dingen abhängen - der Gerichtsbarkeit des Käufers, Ihrer Gerichtsbarkeit und vor allem davon, wie gut Ihre und die jeweiligen Anwälte des Käufers sind;) Mit anderen Worten, "vielleicht".
@Piskvor Danke. Wissen Sie, ob die PayPal-Kaufabwicklung von Prestashop zu Paypal umleitet (ich benötige also kein https) oder die PayPal-API auf dem Server verwendet (also muss ich https aktivieren)?
-1
@Harlandraka Paypal-Anfragen werden niemals über Ihren Server gesendet, das ist der springende Punkt bei Paypal.
Adi
2013-04-05 16:29:11 UTC
view on stackexchange narkive permalink

Ich werde weitermachen und es sagen. Ja, es ist obligatorisch, SSL mit einer E-Commerce-Site zu verwenden.

Während Ihnen niemand wirklich mit einer Axt folgt, um Sie zu enthaupten, wenn Sie kein SSL verwenden, verwenden Sie SSL Für Websites wie E-Commerce ist entscheidend . Daher ist es in dem Sinne obligatorisch, dass Sie in viele Probleme geraten, wenn die Konten Ihrer Kunden gestohlen werden oder wenn jemand anfängt, die Sitzungen Ihres Kunden zu manipulieren.

Warum sollten Sie SSL mit einem e verwenden? -commerce-Website?

  1. Schützen Sie die Anmeldeinformationen Ihrer Kunden.
  2. Schützen Sie die Sitzungen Ihrer Kunden vor Entführungen (Cookies werden im Klartext gesendet).
  3. Schützen Sie Ihre Kunden davor, auf eine ganz andere gefälschte Website weitergeleitet zu werden ( DNS-Spoofing).
  4. ol>
Wenn Sie dies nicht tun, müssen Sie sich während der PCI SAQ-D-Selbsteinschätzung selbst verloben. Und wenn etwas schief geht, werden Sie mit Geldstrafen von Ihrem Kreditkartenverarbeiter konfrontiert, zusammen mit Ihrer Fähigkeit, gesperrte Kreditkarten zu verarbeiten.
AJ Henderson
2013-04-05 18:10:20 UTC
view on stackexchange narkive permalink

Wenn Sie keine Kontoinformationen haben und Kreditkarteninformationen über ein Zahlungsgateway verarbeiten, ist dies nicht obligatorisch. Es ist durchaus möglich, eine E-Commerce-Site ohne HTTPS sicher zu betreiben, wenn Sie wissen, was Sie tun, und durch eine Reihe ganz besonderer Rahmen springen. (Kein Benutzername / Passwort, Zahlung außerhalb des Unternehmens über ein Zahlungsgateway oder Paypal verarbeiten, Bestellnummern für die Nachverfolgung verwenden usw.). In diesem Fall müssen Sie lediglich eine Liste der Elemente zusammenstellen und diese Liste (oder die Gesamtsumme) an einen sicheren Dienst senden, um die vertraulichen Bits zu verarbeiten, und ein Token als Quittung zurücksenden.

Das heißt, warum sollten Sie Kopfschmerzen haben wollen? Es ist weitaus unwahrscheinlicher, dass Menschen Ihrer Website vertrauen, selbst wenn Sie sie korrekt eingerichtet haben, um alle möglichen Fallstricke zu vermeiden, wenn Sie kein HTTPS haben. Es ist viel einfacher mit HTTPS zu tun und es lohnt sich, entweder ein selbstsigniertes oder ein billiges SSL-Zertifikat zu verwenden. Sie können SSL-Zertifikate für zwei Jahre (und möglicherweise billiger) für nur 60 US-Dollar erhalten. Es gibt wirklich keinen guten Grund, SSL (HTTPS) nicht zu verwenden.

Beachten Sie auch, dass es für die Verarbeitung von Kreditkartendaten im Allgemeinen obligatorisch ist, SSL für den Austausch als Teil des Händlerdienstvertrags zu verwenden. Insbesondere wenn Sie Zahlungskarteninformationen (PCI) berühren, verarbeiten, damit arbeiten oder speichern, erfordert die Vereinbarung über Händlerservices mit ziemlicher Sicherheit, dass Sie PCI-DSS befolgen. Dies ist ein wesentlicher Grund dafür, dass selbst Storefronts, die SSL verwenden, häufig ein Zahlungsgateway für die Verarbeitung der Kreditkartendaten verwenden, damit sie sich nicht um die Feinheiten von PCI-DSS kümmern müssen.

Manishearth
2013-04-05 16:09:40 UTC
view on stackexchange narkive permalink

Es ist nicht "obligatorisch" - niemand erzwingt die Websites.

Aber es ist ratsam. Während sich die Homepage / etc 1 sup> nicht in einer HTTPS-Verbindung befinden muss, sollten alle Seiten mit Formularen und Seiten mit vertraulichen Daten vorhanden sein. Zum Beispiel ist es für eine Site vollkommen in Ordnung, Sie über HTTP einkaufen zu lassen, leitet Sie jedoch zum Auschecken zu HTTPS weiter.

Versuchen Sie, HTTPS nach dem Anmelden für alle Seiten beizubehalten, um auch die Entführung von Sitzungen zu verhindern. Aus demselben Grund sollten Sie Ihre HTTPS-Seiten in einer separaten Domain ( http://example.com , aber https://shop.example.com ) aufbewahren.

Andernfalls verschlüsseln Sie einfach alle Dinge. Es ist nicht zu schwer.

Ohne eine HTTPS-Verbindung sind alle Details, die Sie in das Formular eingeben, für einen Angreifer sichtbar.

1. Dies kann jedoch einige Vorteile haben. Dies könnte verhindern, dass ein Mann in der Mitte die sicheren Links so ändert, dass sie auf ihre eigenen HTTP-Sites verweisen. Sup>

Warum wird das abgelehnt? Daran ist nichts auszusetzen. +1
@TerryChia _ "Während sich die Homepage / etc nicht in einer HTTPS-Verbindung befinden muss" _. Zumindest das "Secure" -Flag sollte erwähnt werden, um diese Aussage irgendwie in Ordnung zu bringen.
@Adnan: Was ist daran falsch? Was schadet es, eine Homepage auf HTTP zu haben? Solange sich alle Formulare / Seiten mit vertraulichen Informationen auf HTTP befinden, kann ein MITM-Angriff auf einer Homepage nichts bewirken.
Egal, ich habe es verstanden. Bearbeitet in.
@Manishearth Downvote rückgängig gemacht. Schauen Sie sich # 2 in meiner Antwort an.
Die Entführung von @Adnan:-Cookies ist nur dann ein Problem, wenn für einen Teil eine Anmeldung erforderlich ist. Alles nach einem Login sollte natürlich HTTPS sein :) (das füge ich auch hinzu)
@Manishearth ** Falsch **. Solange es sich in derselben Domain befindet und das Flag "Sicher" nicht gesetzt ist, wird das Cookie trotzdem gesendet (Browser tun dies normalerweise).
@Adnan:? Welche vertraulichen Informationen sind in Pre-Login-Cookies enthalten?
@Manishearth Das Cookie wird über eine HTTPS-Seite gesetzt. Wenn der Benutzer jedoch die Homepage besucht (für die Sie die Verwendung von HTTP vorgeschlagen haben), die sich in derselben Domain befindet, sendet der Browser das wichtige Cookie (das Login) Plätzchen).
Keith
2013-04-05 20:43:01 UTC
view on stackexchange narkive permalink

Nein, es ist nicht obligatorisch, aber Sie müssen äußerst vorsichtig sein, wenn Sie dies nicht tun.

HTTPS kann Man-in-the-Middle-Angriffe stoppen, für die HTTP sehr anfällig ist.

HTTPS ist jedoch mit einem Prozessor- (und damit Geschwindigkeits-) Overhead verbunden. HTTPS bewirkt, dass Daten außerhalb der Sitzung nicht zwischengespeichert werden und daher bei jedem Besuch Inhalte erneut heruntergeladen werden können. Es hindert Sie auch daran, Content-Delivery-Netzwerke zu verwenden (oder erschwert deren Verwendung erheblich).

Viele Websites versuchen, ohne sie auszukommen, aber es ist eine gefährliche Linie, da das Mischen von HTTP und HTTPS sehr riskant ist - Sie müssen HTTPS-Authentifizierungscookies verwenden. Dies bedeutet, dass Ihr Benutzer nur beim Besuch von HTTPS-Seiten angemeldet ist.

Wenn Sie jemals zulassen, dass ein HTTPS-Authentifizierungscookie an eine HTTP-Seite gesendet wird, sind Sie gegangen Öffnen Sie eine einfache Angriffsroute für Hacker.

Viele Websites tun Folgendes:

  • Anonyme Benutzer können im E-Shop stöbern und einen Einkaufskorb aufbauen
  • Sobald sie zur Kasse gehen oder angemeldet sind, werden sie auf die (langsamere) sichere HTTPS-Version umgestellt.
  • Sie erhalten sie Ein Nur-HTTPS-Authentifizierungscookie und manchmal auch ein HTTP-Cookie mit nur dem Benutzernamen.

Dies ist, was Amazon tut - Cookies, die Ihren Benutzernamen und Ihren Warenkorb enthalten, sind nicht sicher und können leicht geklaut werden. Sie müssen sich jedoch im HTTPS-Bereich anmelden (oder eine gültige, nicht erfahrene Person haben) rotes HTTPS-Cookie), um etwas zu kaufen oder Ihr Konto anzuzeigen.

Das ist jedoch eine feine Linie. Sie benötigen gute (sehr sicherheitsbewusste) Entwickler und Support-Mitarbeiter. Für die meisten Websites ist es viel einfacher und das Risiko, nur HTTPS zu verwenden.

Update 2016

Ich glaube nicht Meine Antwort oben ist nicht mehr richtig. HTTPS ist aus mehreren Gründen jetzt obligatorisch:

Eventual depiction of all non secure connection in Chrome

Sofern Sie nicht die Größe von Google haben, hat Moore's Law das Problem des "Geschwindigkeits-Overheads" irgendwann im letzten Jahrzehnt beseitigt. Und wenn Sie * in Google-Größe * sind, gibt es auch Möglichkeiten, das Problem der "Geschwindigkeit" zu überwinden. ** TL; DR **: "HTTPS ist langsam" ist heutzutage nur eine Ausrede.
@Piskvor Ich wünschte, Sie hätten Recht, aber mein Unternehmen hat Kunden unter Windows 2000, IE6, heruntergekommener Hardware und Sub-DFÜ-Verbindungen. Sie stöhnen über die Geschwindigkeit, wenn sie bei jeder SSL-Sitzung alle JS-, CSS- und Images auf nur zwei parallelen HTTP-Verbindungen erneut herunterladen müssen. Auf Moores Gesetz kann man sich sicher verlassen, um eine Vorstellung davon zu bekommen, welche Macht Ihre Angreifer in die Hände bekommen können, aber Ihre tatsächlichen Benutzer? Sie könnten auf irgendeinem alten Müll sein.
@Piskvor führt außerdem dazu, dass die Verschlüsselung des ausgehenden SSL-Inhalts Ihrem Server nur 15% Arbeitslast hinzufügt, was den Unterschied zwischen 85% der Kapazität und einem überlasteten Server ausmachen kann.
Shurmajee
2013-04-05 16:17:05 UTC
view on stackexchange narkive permalink

Es ist nicht obligatorisch und funktioniert auch mit http, aber es wird nicht empfohlen .

Durch die Verwendung von https stellen Sie sicher, dass die Kommunikation zwischen Ihnen und Ihren Kunden möglich ist Die Kreditkartendaten und Bestelldaten sind verschlüsselt und können von Dritten, die einen Paket-Sniffer ausführen, nicht gesehen werden.

Nehmen wir an, Sie verwenden kein https:

  1. The Kreditkartendetails und andere Informationen können durch die einfache Paketerfassung kompromittiert werden.
  2. Es ist sehr einfach, einen MITM-Angriff durchzuführen. Dies kann zu einer Beschädigung wichtiger Daten wie Zahlungsdetails oder Bestelldetails führen, ohne dass die beiden kommunizierenden Parteien dies wissen.
  3. Sie betreiben ein Geschäft. Wenn Ihre Kollegen über diese Funktion verfügen, müssen Sie diese Funktion implementieren, da sonst Kunden verloren gehen.
  4. ol>
Gurzo
2013-04-05 19:28:12 UTC
view on stackexchange narkive permalink

Während eine Vorgehensweise, die bei der Übertragung vertraulicher Daten (z. B. Authentifizierungsdaten) unbedingt befolgt werden sollte, nur dann obligatorisch ist, wenn der PCI-DSS (Payment Card Industry Data Security Standard) beteiligt ist.

Ist die E-Commerce-Site, die Kontodaten speichert, verarbeitet oder überträgt? Wenn ja, muss es PCI-DSS entsprechen.

In PCI-DSS v2.0 heißt es eindeutig:

4.1 Verwenden Sie starke Kryptografie- und Sicherheitsprotokolle (z. B. SSL) / TLS, IPSEC, SSH usw.) zum Schutz sensibler Karteninhaberdaten während der Übertragung über offene öffentliche Netzwerke.

Hinweis: Kontodaten enthalten die primäre Kontonummer ( PAN), Name des Karteninhabers, Ablaufdatum, Servicecode, vollständige Magnetstreifendaten oder Äquivalent auf einem Chip, CAV2 / CVC2 / CVV2 / CID, PINs / PIN-Blöcke



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...