Beveilig je eigen project

Aan het eind van elke reeks heb je het geleerde op je eigen project toegepast. Hier staat alles bij elkaar, als één lijst om je project na te lopen voordat je het aan anderen laat zien. Bij elk punt staat waar je het leerde. In de cheatsheet staat onder Veiligheid per reeks een kort codevoorbeeld, in dezelfde volgorde als hieronder.

Het idee onder de hele lijst blijft hetzelfde: wat van de bezoeker komt, vertrouw je niet, en de controle hoort op de server.

Wat je server laat zien

• Elk endpoint op /docs is voor iedereen bedoeld. Een endpoint dat je voor jezelf maakte of dat gegevens van anderen teruggeeft, zoals GET /sessies, is weg. (Een vergeten endpoint, Wie mag wat in je eigen project)
• Zet je je server open, dan staan docs_url, redoc_url en openapi_url op None. (De handleiding uitzetten)
• Een .gitignore slaat .venv/, __pycache__/ en *.db over, en een zip die je deelt bevat geen .db-bestand. (Een .gitignore en een nette zip)

Invoer

• Elk tekstveld heeft max_length in Form. (Grenzen in Form)
• Elk getal is een int met ge en le. (Getallen met een grens)
• Een veld dat niet uit alleen spaties mag bestaan, controleer je met strip(). (De inhoud controleren)
• Een keuze uit een paar woorden controleer je tegen een lijst met wat mag. (Een keuze uit een lijst)
• Kiest een bezoeker een bestand, zoals met ?naam=, dan gaat de naam pas naar FileResponse als hij in je lijst staat. (Een bestandsnaam van een bezoeker)

HTML van een bezoeker

• Tekst van een bezoeker komt alleen via een .html-template in je pagina, of met escape() in een f-string. (Escapen in Python, Templates escapen vanzelf)
• Ook tekst uit de URL, zoals een zoekterm, gaat door escape() of een template. (Tekst uit de URL)
• Nergens staat |safe achter tekst van een bezoeker. (|safe)
• Je JavaScript zet tekst uit een veld of de URL in de pagina met textContent, niet met innerHTML. (Tekst blijft tekst: textContent)

Te veel verzoeken

• Het endpoint dat iets opslaat, heeft een verzoeklimiet. (Wat de 429 vertelt, opdracht 3)

Wie mag wat

• Elk endpoint dat iets verwijdert of aanpast, controleert zelf of het van deze bezoeker is, en stuurt anders een 403. (De controle met 403)
• De controle gebruikt wat de server weet, zoals de naam in de sessie, niet wat de bezoeker in een formulier of de URL meestuurt. (Controleer op wat de server weet)
• Die controle staat in elk endpoint apart, ook in Alles wissen en in een endpoint dat je later toevoegt. (Elk endpoint apart)

Cookies

• De sessie-cookie heeft httponly=True en samesite="lax". (httponly, samesite)
• In een cookie staat alleen een sessie-id, geen naam of rechten. (Onthouden op de server: sessies)
• Uitloggen is een POST, en gooit de sessie ook op de server weg, niet alleen de cookie met delete_cookie. (Uitloggen)
• Een sessie verloopt ook op de server, niet alleen in de browser met max_age. (Een sessie laten verlopen)

Wachtwoorden

Je gastenboek heeft accounts sinds de basis; een eigen project alleen als je ze erin bouwde.

• /registreer weigert een naam die al bestaat, anders overschrijft een tweede registratie het wachtwoord van de eerste. (Een server met accounts)
• Je bewaart ph.hash(wachtwoord), nooit het wachtwoord zelf. (Registreren met Argon2)
• Inloggen gebruikt ph.verify, met dezelfde melding bij een onbekende naam en een fout wachtwoord, en ook bij een onbekende naam een verify tegen een nep-hash. (Inloggen met verify)
• Bij het inloggen werk je na een geslaagde verify een oude hash bij met check_needs_rehash. (Een oude hash bijwerken)
• Elk endpoint dat een wachtwoord controleert, zoals /inloggen, heeft een limiet: @limiter.limit direct onder @app.post, met request: Request. (Inlogpogingen beperken)
• Ook /registreer heeft een limiet: elke registratie kost een trage ph.hash, en de melding over een bezette naam verraadt welke namen bestaan. (Inlogpogingen beperken)
• Heb je een endpoint om een wachtwoord te wijzigen, dan vraagt het eerst het oude, met ph.verify, en heeft het ook een limiet. (Wachtwoord wijzigen)

Test het zoals een bezoeker

Een lijst aflopen is niet hetzelfde als testen. Draai voor elk punt dat een statuscode geeft een klein script uit Een script als bezoeker tegen je eigen server op 127.0.0.1, en kijk of je de statuscode krijgt die je verwacht: een 404 op /docs, een 422 bij een te lang veld, een 429 na te veel verzoeken, een 403 bij het bericht van een ander.

Alleen je eigen server

Test alleen je eigen project, op je eigen computer. Wil je weten of de site van een klasgenoot veilig is, vraag dan of je samen naar de code mag kijken.

Terug naar de startpagina van de route.