jzakotnik / openlibry

Simple and easy software to manage school libraries - books, users, rentals and statistics. Enjoy!
https://openlibry.de
MIT License
6 stars 3 forks source link

Sicherheit: Konfiguration von HTTP Headern ermöglichen #26

Closed jornfranke closed 11 months ago

jornfranke commented 11 months ago

HTTP Security Header sind einfache, aber mächtige, Möglichkeiten die Sicherheit der Benutzer zu erhöhen, weil Sie die im Browser vorhandenen Schutzmaßnahmen aktivieren.

Wichtige Header sind: Content-Security-Policy (CSP). Eine sehr sichere und strikte ist: Content-Security-Policy: default-src 'none'; base-uri 'self'; script-src 'self' ; style-src 'self' ; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; object-src 'none'; media-src 'none'; child-src 'self' blob:; form-action 'self'; frame-ancestors 'self'; navigate-to 'self'; block-all-mixed-content Häufig muss man, wenn man die Anwendung nicht nachbessern möchte, eine etwas weniger strikte nehmen:

Content-Security-Policy: default-src 'none'; base-uri 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; object-src 'none'; media-src 'none'; child-src 'self' blob:; form-action 'self'; frame-ancestors 'self'; navigate-to 'self'; block-all-mixed-content

Das ist immer noch ok und besser als keine.

Tool um die Sicherheit der CSP zu evaluieren: https://csp-evaluator.withgoogle.com/

Dann noch weitere mögliche Header: X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000; includeSubDomains Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cross-Origin-Resource-Policy: same-origin Referrer-Policy: no-referrer

und Permission-Policy. Z.B. Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Hier hilft auch dieses Tool: https://www.permissionspolicy.com/

Kann ganz einfach global gesetzt werden (geringer Aufwand!): https://nextjs.org/docs/pages/api-reference/next-config-js/headers

Natürlich muss man weitere Sicherheit noch in der Anwendung programmieren (injection attacks, input validation (backend UND frontend) usw.), aber diese Header helfen schon den Benutzer zu schützen, der die Anwendung nutzt.

jzakotnik commented 11 months ago

Also die CSP headers in nextjs habe ich nach der offiziellen Doku einfach nicht hingekriegt. Es soll so funktionieren, erzeugt aber jedes Mal Tonnen von CSP Fehlern auf der Seite. Die Idee ist, dass die middleware die http header entsprechend setzt.

Als Alternative kann man CSP auch im HTML setzen, wenn auch weniger sicher als HTTP header, jetzt in diesem branch zu finden. Es funktioniert, aber nicht via middleware. Seltsam.

jornfranke commented 11 months ago

Hallo, wenn jedesmal CSP Fehler kommen - dann funktionieren die Policies :) Dann muss man die Anwendung absichern. Z.B. werden Google Fonts von Google direkt geladen und nicht von dem Server, dann muss man die aus der Anwendung laden. Gefährliche Sachen wie eval oder Functions sollte man vermeiden.

Edit: Evt. mal mit einer weniger strikten Policy probieren und die immer strikter machen.

Kann evt. helfen, wenn ich einige konkrete Fehlermeldung hätte. Ich kann irgendwann auch mal versuchen die Anwendung auszuführen.

jornfranke commented 11 months ago

(Die anderen Header sind aber auch wichtig, aber CSP sicherlich eine der wichtigsten)

jzakotnik commented 11 months ago

Ja, ich tüftel noch ein wenig rum. Vielleicht ist es auch ein Issue mit dem MUI framework. An sich werden keine google fonts oder irgendwas von extern geladen. Die Fehlermeldung ist

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-Y2JmMTVkMTktN2E5NC00OGRhLTlkYzUyMGE4YWVlZTYxZWU=' 'unsafe-inline' 'unsafe-eval'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.

An sich macht es wenig sinn, weil im Dev Modus "self" ja localhost sein müsste und sonst wird nichts von woanders geladen:

image

Ggf. ist Teil des Problems auch der dev mode?

jzakotnik commented 11 months ago

Mit dem Set scheint es zu funktionieren, ist aber schon ziemlich relaxed:


const cspHeader = `
    default-src 'self' 'nonce-${nonce}' 'unsafe-eval' 'unsafe-inline';
    script-src 'self'  'unsafe-eval' 'unsafe-inline';
    style-src 'self' 'unsafe-inline' 'unsafe-eval';
    img-src 'self' blob: data:;
    font-src 'self';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    block-all-mixed-content;
    upgrade-insecure-requests;
`;
jornfranke commented 11 months ago

Es macht auf jeden Fall schon Sinn überhaupt eine zu haben. Man kann es dann Schritt für Schritt strenger machen.