Guidelines für Sicherheit (Injektions, CSRF, ...)

[alxndr-w]

Ich würde mir wünschen, ein Kapitel dem Thema Sicherheit zu widmen und best practice bezogen auf Redaxo zu veröffentlichen. Dies könnte man zunächst in den Tricks entwickeln und dann gerne auch in die offizielle Doku überführen, wenn ausgereift.

1. Ist dies erwünscht? Dann kümmere ich mich um die weitere Ausformulierung.
2. Wer kann hier noch Themen beitragen. Oft wird ja nicht absichtlich etwas unsicher in Redaxo umgesetzt, sondern mangels besserem Wissen.

SQL-Injection in rex_sql verhindern

aus Slack notiert:
Falsch:
...->getQuery("SELECT * FROM table WHERE id ='.$_GET['id'].'')
Hier könnte man mit $_GET['id'] eben fiese Sachen injezieren.

Ein bisschen besser, aber immer noch falsch:
...->getQuery("SELECT * FROM table WHERE id ='.rex_request('id', "int", 0).'')
Warum immer noch falsch? Weil das Konstrukt nicht aufgeht, wenn du bspw. einen String erwartest.

Richtig:
...->getQuery("SELECT * FROM table WHERE id =?', array(rex_request('id', "int", 0)))
Ersetzt den Platzhalter ? mit dem Wert aus dem Array (2. Parameter)

Noch schöner:
...->getQuery("SELECT * FROM table WHERE id =:id', array(":id" => rex_request('id', "int", 0)))
Ersetzt den Platzhalter :id mit dem Wert aus dem assoziativen Array. So behältst du den besten Überblick, wenn es darum geht, mehrere Parameter zu übergeben. Dabei werden die Werte sauber übergeben und eingesetzt, eine SQL-Injection ist dann nicht möglich.

CSRF in rex_form, YForm und eigenen Formularen verhindern

In Redaxo 5.5 wurde Schutz vor Crosssite-Scripting eingebaut. Hier würde ich mir von @dergel wünschen, ein paar Guidelines an Entwickler zusammenzustellen.

Weitere Themen

• SSL-Zertifikate
• Passwort-Regeln bearbeiten

[skerbis]

Aus Slack:
@dergel

csrfprotection, schütz einem davor, dass man einen link/formular untergejubelt bekommt, welcher dann irgendeine aktion ausführt.. Das gilt allgemeine für Formulare und auch für Links (z.B. delete Links) .. d.h. es nicht alles muss man mit eine csrf_token versehen, sondern nur fälle, die etwas verändern.. z.B. suchen sind nicht nötig etc-

$_csrf_key = ‘meinkey_addon_subpage’;
$csrf = rex_csrf_token::factory($_csrf_key);

$func = ‘delete’;

if ($func = ‘delete’) {
  if (!$csrf->isValid()) {
    echo rex_view::error(rex_i18n::msg(‘csrf_token_invalid’));
  } else {
    // meine deleteaktion
  }
}

$delete_link = http_build_url(“index.php?page=addon/subpage”, [“delete” => “func”] + $csrf->getUrlParams() ),

@gharlan

1. rex_form: csrf-schutz immer aktiv, da muss man nichts anpassen

2. api funcs: diese methode in der klasse ergänzen: https://github.com/redaxo/redaxo/blob/master/redaxo/src/addons/install/lib/api_core_update.php#L183-L186
   Und den link anpassen: https://github.com/redaxo/redaxo/blob/master/redaxo/src/addons/install/pages/packages.update.php#L40

3. yform .. ist immer da.. kann man aber deaktivieren

4. eigene aktionslinks: token am link hinzufügen und selbst prüfen ob valide vor ausführung der aktion

5. eigene formulare: token als hidden attribute hinzufügen und selbst prüfen ob valide nach absenden

[alxndr-w]

bei 2b verstehe ich die Notwendigkeit und die nötige Anpassung nicht.
zu 4. und 5. braucht es für mich noch mehr Erläuterungen, um sie zu verstehen.

[alxndr-w]

https://wiki.selfhtml.org/wiki/Grundlagen/sichere_Cookies

Sichere Cookies:

(alternativ beim Hosting)

Danke @engel4u @skerbis für die Diskussion dazu im Chat.

Welche Angaben würdest du empfehlen? @skerbis

[skerbis]

https://observatory.mozilla.org und die empfohlenen Schritte beim Hoster durchführen. Erlaubt es das Hosting nicht, dann hier.

[alxndr-w]

https://github.com/alexplusde/yform_spam_protection/ und https://github.com/yakamara/redaxo_yform_docs/blob/master/de_de/demo_kontakt-spamschutz.md passen hier ebenfalls in eine Doku-Tricks-Seite rein, da Versand von Bestätigungs-E-Mails an fremde Postfächer ohne Spamschutz zum Sicherheitsproblem werden kann. (Abwertung der Domain, Blacklist, Versand von Phishing-Mails)

[aeberhard]

https://securityheaders.com/ kennt das jemand und ist das hier evtl. auch interessant!?

[skerbis]

@aeberhard https://securityheaders.com/ ist in https://observatory.mozilla.org integriert
(Third-party Tests)

[skerbis]

https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/

[aeberhard]

Ah, hatte ich nicht gesehen :)

[alxndr-w]

• Redakteuren keine Eingaben zu PHP-Code direkt zur Verfügung stellen

[engel4u]

Warum geschlossen, dann wieder geöffnet? Was fehlt noch bzw was soll geändert werden?

[skerbis]

ich möchte es für Ergänzungen gerne offen lassen. Das Thema ist immer aktuell :-)