adamalton / django-csp-reports Goto Github PK

Application settings are not handled by Django, but there are several apps which tries to solve that. I suggest to use https://github.com/Genida/django-appsettings to handle CSP settings.

Hi,
Can you remove the limitation on djano <1.11.99 or check compatibility with django 2.0>

Add a command to print summary about the CSP reports.

Usage

make_csp_summary [--since date] [--to date] [--top number]

by default prints the summary of yesterday's reports. --since and --to modify the interval. --top defines the size of each limit section, 10 by default.

Content

• Total number of reports, number of invalid reports.
• Top sources (document_uri) + examples (source, blocked URI)
• Top violated directives + examples (source, blocked URI)
• Top blocked URIs + examples (source, blocked URI)
• Examples of invalid reports

URIs will be merged regardless of query and fragment.

Think about

• Summary customization

This should be done!

Possibly with versioned migrations? See #7.

Under Python3, Django wants to generate a new version of this migration:

https://github.com/adamalton/django-csp-reports/blob/master/cspreports/migrations/0002_auto_20141011_1800.py#L16

However, the only difference is that

        options={'ordering': (b'-created',)},

becomes:

         options={'ordering': ('-created',)},

The issue is discussed here:

https://code.djangoproject.com/ticket/23226#comment:18

The solution is to edit the migration to use '-created' and not b'-created', which works for both versions.

Thanks!

Hey,

thanks for the project so far! :)

I could like to add an acknowledge function to the reports (instead of deleting them). Therefore I would have to add a field to the csp model (or create a construct with an extra table pointing at acknowledged reports, which would be kinda clumsy to use in django admin).

My use case is probably only one example of how one would adjust the model to it's individual needs.

I would offer to create a PR to enable customization of the used model doing the following steps:

• I would propose to add a setting for specifying the used csp model and transform the current model into an abstract base class with default implementation. That's a pattern you often find in django's third party packages.

• Before doing that, I could refactor the settings access and gather app settings in one central module, if that's appreciated.

Please tell me, what you think about it :)

First, thank you for maintaining this! I'm eager to try it with my site.

I have a question - Is there any validation done on the CSP reports? I didn't see any, and I'm wondering if this doesn't open a site up to various security issues?

For instance, what if we set log_report and then start sending thousands of massive reports, i.e., huge JSON objects, at the same time? Couldn't that immediately eat up a server's RAM?

It appears that there's some amount of validation in the save_report function in terms of requiring that the report match the desired keys, and some fields are limited by choices, but I'm wondering whether directives shouldn't be more fully validated? I'm not well versed on CSP RFC's so if you know of a place that shows good validation or a repo that might do it already I'd love to take a look and make a PR if I'm able.

I suppose one thing to do short-term is to use log_reports and simply add a custom filter that verifies the size of the log is below a certain threshold of kb?

Mainly opening this issue to see if maintainers have ideas that would be useful in making sure that the endpoint doesn't open up any vulnerabilities. Thanks again for maintaining this repo!

• Add codecov
• Check all tests run

It would be nice to have tests run in CI.

CSP reports are stored as they came in, which makes it very impossible to filter using SQL.

I propose additional model fields:

• valid - whether CSP report is valid (i.e. can be split into fields)

CSP 1.0 fields according to https://www.w3.org/TR/2012/CR-CSP-20121115/#report-uri - will be NULL for invalid CSP reports

• document_uri
• referrer
• blocked-uri
• violated-directive
• original-policy

CSP 2.0 fields accoring to https://www.w3.org/TR/CSP2/#violation-reports - will be NULL for invalid CSP reports or if not present in the report

• effective-directive
• status-code
• source-file
• line-number
• column-number

CSP 3.0 fields https://www.w3.org/TR/CSP/#deprecated-serialize-violation

• disposition - will be NULL for invalid CSP reports or CSP < 3.0 reports

#31 introduced a string representation property for report which should be used where the nice report is required.

Ideas

• Drop CSPReport.json_as_html and keep only CSPReportAdmin.json_as_html.
• Refactor utils to pass around a report instance and not only request.

Add checks by pydocstyle.

The migrations have unsynced changes.

Enforce isort, flake8, pydocstyle...

Current pypi version was released 18 months ago and doesn't work with django>=1.9

The tests seem to run fine for Django 4.0.

Is it just a matter of bumping the requirement on Django to allow 4.0?

The cspreports/summary.txt is missing from the version 1.5 pypi package.

I'd guess because of the manifest in this recent commit: 414d23d

Suggestions

• Show individual fields
• Prevent users from creating/updating reports

Support for django 2.1 would be very helpful since we want to migrate our projekt to django 2.1

when migrating an existing Django project from
django 2.2 to django 3.2

and specifying in settings :
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

this will generate a migration file inside 'cspreports' module.
IMHO i think this migration should not happen

when launching unit test in my Django project (Django 3.2)

coverage run $(which pytest)

i get the following warning

RemovedInDjango41Warning: 'cspreports' defines default_app_config = 'cspreports.apps.CSPReportsConfig'. Django now detects this configuration automatically. You can remove default_app_config.

(declared in cspreports/init.py)
nevertheless when i run other command with manage.py (manage.py runserver, manage.py makemigrations, ...) i don't have this warning