VSinerva/csb-project-1
Archived
1
0
Fork 0
Code Activity

Add flaw 5: misconfiguration

Browse source
This commit is contained in:
Vili Sinervä 2024-11-25 18:31:39 +02:00
parent 0d8bedf002
commit f8fd726953
No known key found for this signature in database
GPG key ID: DF8FEAF54EFAC996
2 changed files with 20 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

12
README.md
View file

@ -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.

10
project/settings.py
View file

@ -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