Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alxndr-w opened this issue Feb 9, 2018 · 12 comments
Open

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

alxndr-w opened this issue Feb 9, 2018 · 12 comments

Comments

@alxndr-w
Copy link
Member

alxndr-w commented Feb 9, 2018

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
Copy link
Member

skerbis commented Feb 11, 2018

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
Copy link
Member Author

alxndr-w commented Mar 30, 2018

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
Copy link
Member Author

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

Sichere Cookies:
image

(alternativ beim Hosting)

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

Welche Angaben würdest du empfehlen? @skerbis

@skerbis
Copy link
Member

skerbis commented Feb 17, 2020

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

@alxndr-w
Copy link
Member Author

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
Copy link
Member

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

@skerbis
Copy link
Member

skerbis commented Feb 18, 2020

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

@skerbis
Copy link
Member

skerbis commented Feb 18, 2020

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

@aeberhard
Copy link
Member

Ah, hatte ich nicht gesehen :)

@alxndr-w
Copy link
Member Author

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

@alxndr-w alxndr-w removed their assignment Jul 15, 2020
@skerbis skerbis reopened this Aug 14, 2020
@engel4u
Copy link
Collaborator

engel4u commented Aug 14, 2020

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

@skerbis
Copy link
Member

skerbis commented Aug 14, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants