Magento Security Punch-Liste


27

Es kommt sehr oft vor, dass wir eine Site von einer anderen Firma übernehmen, und jetzt stecken wir in einem Konglomerat aus Code und möglicherweise Dutzenden von Personen, die an einer Site gearbeitet haben. Ich suche eine Durchschlagsliste mit Artikeln, die ich von einer Sicherheitsperson erfragen kann, um sicherzustellen, dass die Magento-Site geschützt ist. Dies wäre erforderlich, wenn jemand die volle Verantwortung für den gesamten Code übernehmen und der Client nicht von Grund auf neu erstellen möchte.

Meine Frage: Gibt es eine Top-10- oder Top-20-Liste mit zu stellenden und zu dokumentierenden Elementen?

Antworten:


39

Aus meiner Erfahrung sind dies wichtige Informationen, um einen neuen Shop sicherheitshalber zu übernehmen. Diese Liste ist noch nicht bestellt und vollständig. Ich werde weiter an der Liste arbeiten.

Magento-Sicherheit

  1. HTTPS verwendet (überall im Shop, nur zur Kasse)?
  2. Benutzerdefinierter Administrationspfad?
  3. Zugriff auf Admin-Pfad eingeschränkt?
  4. Wie viele Administratoren? Sind nicht benötigte Benutzer aktiv?
  5. Kontoschutz & Passwortverschlüsselung (für Kunden und Administratoren): Standard oder Anpassung? 2-Faktor-Authentifizierung?
  6. (Neueste) Magento-Version verwendet?
  7. Magento-Sicherheitspatches angewendet?
  8. Benutzerdefinierte Ordner / Skripte auf Stammebene, auf die von einem entfernten Standort aus zugegriffen werden muss?
  9. Zugriff auf Test- / Staging-System (falls verfügbar) eingeschränkt?
  10. Webservices, Import / Export-Funktionalität genutzt?
  11. Wie viele Webservice-Rollen? Sind nicht benötigte Rollen aktiv?
  12. Liste der installierten Erweiterungen
  13. Installierte Erweiterungen auf dem neuesten Stand?
  14. PCI-DSS, vertrauenswürdige Shops, andere Labels?
  15. Sitzungs- / Cookie-Liftzeit?
  16. Führen Sie nur Magento aus. (Keine Wordpress oder andere Software von Drittanbietern)
  17. Gespeicherte Daten: Welche Kunden- und Bestelldaten (sowie Daten von Drittanbietern und kundenspezifischen Erweiterungen) werden gespeichert? Bankdaten, Kreditkartendaten (siehe PCI-DSS)?

Systemsicherheit

  1. PHP-Version: Neue Version oder alte?
  2. Dateiberechtigungen: Laufen Sie als www-data / apache-Benutzer oder als root?
  3. Richtige Dateiberechtigungen festgelegt?
  4. Shopspezifische Datenbank-Zugangsdaten vs. Datenbank als root?
  5. SSH / SFTP Zugang? Schlüsselbasierte Authentifizierung?
  6. SLA mit Hosting-Provider über (reguläre) Betriebssystem-, PHP + -Modul-Updates und Sicherheitsupdates?

Organisation

  1. Wer ist für Systemaktualisierungen (Sicherheitsaktualisierungen) verantwortlich?
  2. Wer hat Zugriff auf den Live-Server?
  3. Wer hat Zugang zum Live-Shop?
  4. Wo ist der Code gehostet? Wer hat Zugriff auf das Bare-Repo und den Push-Zugriff?
  5. Wie sieht der aktuelle Softwareentwicklungsprozess aus? Werden Codeüberprüfungen und automatische Überprüfungen durchgeführt, bevor Code für Staging / Test / Live bereitgestellt wird?
  6. Werden (regelmäßig) Sicherheitstests oder Sicherheitsüberprüfungen durchgeführt?
  7. Gibt es eine regelmäßige Sicherung? Wenn ja, ist es extern?
  8. Abhängig von der Shop- / Unternehmensgröße: Gibt es Business Continuity- und / oder Recovery-Pläne?

1
Gute Liste @Anna Volki :)
Amit Bera

4
Einer meiner Käferbären sind Module von Drittanbietern, die ihren eigenen Admin-Frontnamen angeben. Sie ermöglichen es (wenn Sie wissen, dass das Geschäft die Erweiterung hat), herauszufinden, wie der angeblich geheime Frontname lautet!
Peter O'Callaghan

3

Stellen Sie sicher, dass Ihr / downloader / -Ordner sicher ist. Sie können das längste Passwort der Welt haben, aber wenn ich die ganze Zeit auf der Welt habe, um Ihre Benutzerinformationen auf Ihrer Download-Seite brutal zu erzwingen, werde ich es irgendwann bekommen. Sie können auch sicherstellen, dass Ihre Serververzeichnisse nicht aufgelistet werden. Wenn sie aufgelistet sind, kann ich Ihre Serverinhalte einfach bei Google abrufen und losbrowsen. Sie werden erstaunt sein, wie viele vertrauliche Informationen Menschen auf ihren Webservern speichern.


Ich würde empfehlen, den Download-Ordner zu entfernen ... wozu benötigen Sie ihn?
Brentwpeterson

1
Ich würde es nicht entfernen, sondern die Benutzer, die zum Downloader / * kommen, per htaccess-Regel auf die Homepage umleiten.
Kalpesh

3

Um die Liste von Anna Volk zu erweitern, geht diese Liste über das Übliche hinaus

  • Inhaltssicherheitsrichtlinie (Bei ordnungsgemäßer Implementierung ist XSS nicht möglich.)
  • HSTS (HTTP Strict Transport Security)
  • SELinux mit richtig eingestellten Kontexten.
  • yum-cron / unattended-updates installiert für automatische Sicherheitsupdates
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.