C1: Define Security Requirements

C2: Security Frameworks and Libraries

In this chapter we will cover the security frameworks and libraries incorporated in the system.

 User set passwords are at least 8 characters in length.

 Users can change their password.
 Password change functionality requires the user's current and new password.
 A password strength meter is provided to help users set a stronger password.
 "Paste" functionality, browser password helpers, and external password managers are
permitted.

Django default configuration: - Django framework by default provides number of security techniques
which enables applications developed by Django to be protected from list of security threats such as
cross site scripting(XSS), Cross site request forgery (CSRF), SQL Injection and etc.

Django Axes: - is a Django plugin for keeping track of suspicious login attempts for our Django based
website and implementing simple brute-force attack blocking. Functionality of axes are listed below.

 Axes records login attempts to your Django powered site and prevents attackers from
attempting further logins to your site when they exceed the configured attempt limit.
 Axes can track the attempts and persist them in the database indefinitely, or alternatively
use a fast and DDoS resistant cache implementation.
 Axes can be configured to monitor login attempts by IP address, username, user agent, or
their combinations.
 Axes supports cool off periods, IP address whitelisting and blacklisting, user account
whitelisting, and other features for Django access management.

Google reCaptcha:- uses an advanced risk analysis engine and adaptive challenges to keep malicious
software from engaging in abusive activities on your website. Meanwhile, legitimate users will be able to
login, make purchases, view pages, or create accounts and fake users will be blocked.

Django security logger:- Django-security-logger is library for logging input, output request and Django
commands. Library can be used with django-reversion to log which data was changed in a request. The
library provides throttling security mechanism.

PBKDF2:- PBKDF2 is a simple cryptographic key derivation function, which is resistant to dictionary
attacks and rainbow table attacks. It is based on iteratively deriving HMAC many times with some
padding. The PBKDF2 algorithm is described in the Internet standard RFC 2898(PKCS #5).
C3: Secure Database Access
In this section we will discuss the mechanism used to make a secure database access

Django ORM: - The Django web framework includes a default object-relational mapping layer (ORM)
that can be used to interact with data from various relational databases such as SQLite, PostgreSQL, and
MySQL. Django allows us to add, delete, modify and query objects, using an API called ORM. ORM
stands for Object Relational Mapping. An object-relational mapper provides an object-oriented layer
between relational databases and object-oriented programming languages without having to write SQL
queries.

While we attempt to write raw SQL queries and custom SQL, doing so may open the door for an attack.
Django’s object-relational-mapping (ORM) framework is designed to make querying your database easy.
Query sets are constructed using query parametrization. The queries parameters have been abstracted
away from the queries SQL code. A user attempting to perform a SQL Injection (execute arbitrary SQL on
a database) is going to find it much harder if you always use the ORM.

C4: Encode and Escape Data

In this section we will discuss the mechanism and technologies used to maintain Encoding and
Escape data

 Data selection or database queries (SQL) use parameterized queries, ORMs and entity
frameworks to protect from database injection attacks.

CSRF: - Django features a percent CSRF token percent tag that is used to prevent malicious attacks.
When generating the page on the server, it generates a token and ensures that any requests coming
back in are cross-checked against this token. The token is not included in the incoming requests; thus
they are not executed.

To prevent we made sure all GET requests are free of side effects. That way, if a malicious site includes
one of our pages as an, it will not have a negative effect. That leaves the POST requests to be attended.
The second step is to give each POST a hidden field whose value is secret and is generated from the
user’s session ID. Then, when processing the form on the server side, check for that secret field and raise
an error if it does not validate.

SQL Injection: - SQL injection is a type of attack where a malicious user is able to execute arbitrary SQL
code on a database. This can result in records being deleted or data leakage.

Django’s query sets are protected from SQL injection since their queries are constructed using query
parameterization. A query’s SQL code is defined separately from the query’s parameters. Since
parameters may be user-provided and therefore unsafe, they are escaped by the underlying database
driver.

Django also gives developers power to write raw queries or execute custom SQL. These capabilities
should be used sparingly and you should always be careful to properly escape any parameters that the
user can control.
C5: Validate All Inputs
In this section we will discuss how input validation is maintained.

 The application has defenses against HTTP parameter pollution attacks, particularly if
the application framework makes no distinction about the source of request parameters
(GET, POST, cookies, headers, or environment variables).
 Django framework protects against mass parameter assignment attacks, or that the
application has countermeasures to protect against unsafe parameter assignment, such
as marking fields private or similar.
 All input (HTML form fields, REST requests, URL parameters are validated using positive
validation.

C6: Implement Digital Identity

In this section we will discuss the mechanism used to implement digital identity

 The application never reveals session tokens in URL parameters.

 The application generates a new session token on user authentication.
 Session tokens possess at least 64 bits of entropy.
 Session tokens are generated using approved cryptographic algorithms.
 Logout and expiration invalidate the session token, such that the back button or a
downstream relying party does not resume an authenticated session, including across
relying parties.
 If authenticators permit users to remain logged in, re-authentication occurs periodically
both when actively used or after an idle period of 12 hours or 30 minutes of inactivity, 2FA
optional.
 The application allows system to revoke OAuth tokens that form trust relationships with
linked applications.
 The application uses session tokens rather than static API secrets and keys, except with
legacy implementations.
 Stateless session tokens use digital signatures, encryption, and other countermeasures to
protect against tampering, enveloping, replay, null cipher, and key substitution attacks.

To implement digital identities with points mentioned above we have used two techniques. Session
based digital identity and Token based digital identity.

Session based digital identity: - Session-based authentication is a state-full authentication technique

where we use sessions to keep track of the authenticated user. Here is how Session Based
Authentication works:
  User submits the login request for authentication.

 Server validates the credentials. If the credentials are valid, the server initiates a session and
stores some information about the client. This information can be stored in memory, file system,
or database. The server also generates a unique identifier that it can later use to retrieve this
session information from the storage. Server sends this unique session identifier to the client.

 Client saves the session id in a cookie and this cookie is sent to the server in each request made
after the authentication.

 Server, upon receiving a request, checks if the session id is present in the request and uses this
session id to get information about the client.

Token identity verification: - Token authentication refers to exchanging a username and password for a
token that will be used in all subsequent requests so to identify the user on the server side. This article
revolves about implementing token authentication using Django REST Framework to make an API. The
token authentication works by providing token in exchange for exchanging usernames and passwords.

C7: Enforce Access Controls

In this section we will discuss the mechanism used to enforce access control

 The application enforces access control rules on a trusted service layer, since client-side
access control is present and could be bypassed.
 All user and data attributes and policy information used by access controls cannot be
manipulated by end users unless specifically authorized.
 The principle of least privilege exists - users should only be able to access functions, data
files, URLs, controllers, services, and other resources, for which they possess specific
authorization.
 Sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR)
attacks targeting creation, reading, updating and deletion of records, such as creating or
updating someone else's record, viewing everyone's records, or deleting all records.
 Django framework enforces a strong anti-CSRF mechanism to protect authenticated
functionality, and effective anti-automation or anti-CSRF protects unauthenticated
functionality.
 Administrative interfaces use appropriate multi-factor authentication to prevent
unauthorized use.

This access control mechanism are mainly done using to mechanism. Role based and Permission based
access control systems.

Role based: - Role-based access control (RBAC) restricts network access based on a person's role within
an organization and has become one of the main methods for advanced access control. The roles in
RBAC refer to the levels of access that employees have to the network.

Permission based: - Defines specific permissions for every entity using a system. As previously stated,
each permission typically is a tuple indicating both a resource and an operation.

C8: Protect Data Everywhere

 In this section we will discuss the mechanism used to protect data

 The application sets sufficient anti-caching headers so that sensitive data is not cached in
modern browsers.
 The data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or
cookies) does not contain sensitive data.
 All sensitive data created and processed by the application has been identified, and ensure
that a policy is in place on how to deal with sensitive data.
 Accessing sensitive data is audited (without logging the sensitive data itself), if the data is
collected under relevant data protection directives or where logging of access is required.
 Sensitive or private information that is required to be encrypted, is encrypted using
approved algorithms that provide both confidentiality and integrity.

For encryption protection we have used the SHA256 Encryption system. Additionally we used One Time
Password technique which is also encrypted.)

C9: Implement Security Logging and Monitoring

In this section we will discuss the technics used to implement Security logging and monitoring.

 The application does not log credentials or payment details. Session tokens should only be
stored in logs in an irreversible, hashed form.
 Each log event includes necessary information that would allow for a detailed investigation
of the timeline when an event happens.
 All authentication decisions are logged, without storing sensitive session tokens or
passwords. This should include requests with relevant metadata needed for security
investigations.

We used Django security logger for implementing security logging and monitoring.

C10: Handle All Errors and Exceptions

In this section we will discuss how the system handles errors and exceptions.

 A generic message is shown when an unexpected or security sensitive error occurs.

 Exception handling is used across the code-base to account for expected and unexpected error
conditions.
 A "last resort" error handler is defined which will catch all unhandled exceptions.