From f8fd72695300ebb6ea6a7fa75580b056f4a93736 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vili=20Sinerv=C3=A4?= Date: Mon, 25 Nov 2024 18:31:39 +0200 Subject: [PATCH] Add flaw 5: misconfiguration --- README.md | 12 +++++++++++- project/settings.py | 10 +++++++++- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 6e5a30e..1fa81b4 100644 --- a/README.md +++ b/README.md @@ -14,6 +14,7 @@ I am using the 2021 OWASP Top Ten list. LINK: https://github.com/VSinerva/csb-project-1 I am using the basic Django template, so no instructions are included. +The user accounts `test1:test1` and `test2:test2` have been added to the database for testing purposes. FLAW 1: > ADD EXACT SOURCE LINK @@ -27,6 +28,7 @@ The check compares the logged in user to the owner of the note, and only deletes This should never cause a problem for a normal user, but it makes sure that the note being deleted belongs to the logged in user. + FLAW 2: > ADD EXACT SOURCE LINK @@ -46,6 +48,7 @@ FLAW 3: SQL Injection (Unsanitized SQL query for search) + FLAW 4: > ADD EXACT SOURCE LINK @@ -56,7 +59,14 @@ The fix for this issue is to perform server-side validation on new passwords, an Django includes a simple built-in validator which checks that the password has a minimum length (default 8, in this app 10), is not too similar to the username, is not a common password (20000 password list) and is not purely numeric. These checks are implemented in the commented out code, and would significantly improve the situation. + FLAW 5: > ADD EXACT SOURCE LINK -Misconfiguration +(Security Misconfiguration) The current project settings set debug features to always be on, and contains the Django secret key in the public repository. +Django in debug mode shows detailed stack traces etc. when errors occur, which could reveal internal information. +The secret key is crucial for e.g. session security, so should absolutely never be posted publicly, as it has been here. + +The solution to both of these problems is to load the values from environment variables at runtime. +This, in combination with e.g. a .env file, helps to make sure that the correct settings and keys are in use in development and in production. +This fix is implemented in the commented out code. diff --git a/project/settings.py b/project/settings.py index 76707c0..ea27e1b 100644 --- a/project/settings.py +++ b/project/settings.py @@ -11,6 +11,7 @@ https://docs.djangoproject.com/en/3.2/ref/settings/ """ from pathlib import Path +from os import getenv # Build paths inside the project like this: BASE_DIR / 'subdir'. BASE_DIR = Path(__file__).resolve().parent.parent @@ -19,9 +20,16 @@ BASE_DIR = Path(__file__).resolve().parent.parent # Quick-start development settings - unsuitable for production # See https://docs.djangoproject.com/en/3.2/howto/deployment/checklist/ +# FLAW 5: +# The security key should be changed to be secure, and not visible in the repo! +# Debug should also be disabled in production, but is now hardcoded to True +# A good idea would be to load the values from environment variables +# This is implemented in the commented out code +# SECRET_KEY = getenv("DJANGO_SECRET_KEY") +# DEBUG = getenv("DJANGO_DEBUG") + # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = 'django-insecure-)10v6d=(_iu)19nfuzz9jc6#$1lw=-)33s(%nv*#dsa6tibt1!' - # SECURITY WARNING: don't run with debug turned on in production! DEBUG = True