mallyvai

LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'root': {
        'level': 'WARNING',
        'handlers': ['sentry'],
    },
    'formatters': {

mallyvai

http://www.offerletter.io/wp-login.php
http://www.offerletter.io/xmlrpc.php
http://www.offerletter.io/administrator/index.php
http://www.offerletter.io/wp-signup.php
http://www.offerletter.io/wp-content/uploads/samplc.php
http://www.offerletter.io/wp-includes/routing.php
http://www.offerletter.io/wp-admin/admin-ajax.php
http://www.offerletter.io/index.php
http://www.offerletter.io/admin/include/ktt.php
http://www.offerletter.io/store/index.php/admin

mallyvai

Django’s admin UI is wonderful, and a big part of the reason why we chose it for OfferLetter.io. Unfortunately the admin panel itself is extremely insecure, with simple password authentication and no modern security infrastructure. 


Given how widely-used and critical this admin UI is, I think that adding better, modern security practices would go a long way to keeping Django safe. Some rough ideas are below, in rough order of ease of implementation.


> Logging CSRF exceptions as special SuspiciousOperation security exceptions. CSRF tokens/cookies exist to provide security, and if there is some rogue actor, I’d like to know about as soon as possible. This is easy now to do now using the 403 handler. But in my view, the sensible default here is to treat it as a security violation and SuspiciousOperation.


> Logging failed admin account login attempts as SuspiciousOperation (including the IP). This will be highly-leveraged - easy to implement and straightforward.

mallyvai

require 'parallel'

Benchmark.measure do
    query = ->(table) do
        result = ActiveRecord::Base.connection.execute("CHECK TABLE #{table} EXTENDED;").to_a
        puts result
        result
    end
    result = Parallel.map(ActiveRecord::Base.connection.tables, in_processes: 10) { |table| query.call(table)}
end