Skip to content
This repository has been archived by the owner on Oct 15, 2022. It is now read-only.

Latest commit

 

History

History
716 lines (591 loc) · 37.9 KB

Tasks-and-Mitigations.md

File metadata and controls

716 lines (591 loc) · 37.9 KB

Tasks for securing the web application

Table of Contents:

Jason:

Functionality Of Web Application

Implemented:

  • Home
  • Login
    • User Login
    • Admin Login
    • Super Admin Login
  • Signup
  • Admin Profile
  • Teacher Page
  • User Management System
    • Which allows the admin to:
      • Edit username
      • Recover a user's account
      • Reset profile image
      • Disable a user's 2FA if enabled
      • Ban/Unban a user
      • Delete a user
  • Improvement in Calvin's pagination
  • 2FA pages
  • Account Recovery pages
  • Integrating Cloudflare to the hosted web application
  • Integrating Google Cloud Platform (GCP) APIs
  • Deployment of the Web Application on Google Cloud Run

Selected OWASP Mitigations

Cryptographic Failures

Implemented:

gcp-kms

  • Using Google Cloud Platform Key Management Service (KMS) for cryptographic operations

    • Generated keys are stored and replicated globally in Google's servers
    • The generated keys are protected by using Google's Hardware Security Module (HSM)
    • Generated symmetric keys are also configured to rotate every 30 days

  • When generating something random such as for session IDs, I used a cryptographically secure random number generator (RNG).

    • Reasons:
      • RNG in computers can be a problem for sensitive actions such as for session identifier, cryptography operations, etc. as they can be very predictable.
      • Ensure that the randomly generated bytes/hex has high entropy.
    • Mitigations:
      • Using Python's secrets module
        • Recommended by OWASP to ensure higher entropy
      • Using Google Cloud Platform Key Management Service's Cloud Hardware Security Module RNG API.

  • Configured the 2 Factor Authentication verification to use HMAC-SHA512 instead of the default HMAC-SHA1

    • To avoid the use of SHA1 which is a deprecated hash function
    • With reference to pyotp's TOTP source code which uses the SHA1 as the default digest method

  • Securing Flask Session Cookie

    • The Flask session cookie is digitally signed using HMAC-SHA512 algorithm.
      • Although HMAC cannot be used for digital signature, in this context, it is possible as only the web application knows the secret/symmetric key used in the HMAC algorithm.
    • Configured the Flask session's default HMAC algorithm from HMAC-SHA1 to HMAC-SHA512.
      • Since SHA1 has been "broken" and is no longer considered secure, it is now recommended to use SHA256 or SHA512
      • References:
    • Changing the default salt from "cookie-session" to something more secure using Google Cloud Platform KMS API RNG in the Cloud HSM
      • The randomly generated 64 bytes salt will be stored in Google Cloud Platform Secret Manager API.
    • Using Google Cloud Platform KMS API RNG in the Cloud HSM for the symmetric key (4096 bits) used in the HMAC algorithm as Flask session's secret key.
      • Ensures high entropy
        • Generated key will have a high entropy as it is generated using a cryptographically secure random number generator (RNG) in the Cloud HSM.
        • Since the max cookie size is 4093 bits, specified in Flask's default configuration, a key size must be at least 4093 bits will be needed to ensure high entropy as the key size must match the message size.
          • If the key size is less than 4093 bits, the key will be padded with zeros to match the message size.
            • Wil reduce the entropy of the key.
          • If the key size is greater than 4093 bits, the key will be truncated to match the message size.
            • No effect on the entropy of the key.
          • If the key size is equal to 4093 bits, the key will be used as is.
            • No effect on the entropy of the key.
      • $2^{4096}$ possible keys (Unlikely to be guessed)
      • Prevent session cookie from being tampered with
      • Automatically rotated at the end of each month
      • In the event that the Flask session secret key is leaked, the key can be simply rotated.

  • Argon2 for hashing passwords

    • Argon2 will generate a random salt using os.urandom(nBytes) which is more secure than setting your own salt
    • Type used: Argon2id (A hybrid of Argon2i and Argon2d)
    • Minimum requirement as of OWASP:
      • 15MiB of memory
      • 2 count of iterations
      • 1 degree of parallelism
    • Default Argon2 configuration (Meets the minimum requirements):
      • 64MiB of memory
      • 3 count of iterations
      • 4 degree of parallelism
      • 16 bytes salt, os.urandom(16)
      • 32 bytes hash
      • Argon2id
      • On average, the time taken to hash a password is about 0.05+- seconds.
    • Manually tweaked Argon2 configurations (Meets the minimum requirements):
      • 64MiB of memory
      • 4 count of iterations
      • 4 degrees of parallelism
      • 64 bytes salt, os.urandom(64)
      • 64 bytes hash
      • Argon2id
      • On average, the time taken to hash a password is about 0.06+- seconds.
        • Not too resource intensive as to avoid server resource exhaustion.

  • Using Google OAuth2 for login/signup (removed the need for storing passwords)

  • Encrypting the sensitive data to be exposed in the public domain/internet using Google Cloud Platform KMS symmetric encryption service

    • 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata
    • A total of 2 AES-256 GCM keys are used:
      • Encrypting the (temporarily stored) sensitive data in the session cookie such as the state for Google OAuth2 logins
        • For layered security on top of HTTPS
        • Preventing sensitive data from being sniffed and exposed from the session cookie
      • Implemented tokens for authorising sensitive actions such as reset password using Python's secrets module
        • The token is in plaintext in the database but encrypted in the URL
          • Acts as a layer of security through obscurity
        • This means that the attacker will have to find the key used in the encryption of the token ID in order to encrypt it and use it in the URL

  • Encrypting the sensitive data in the database using Google Cloud Platform KMS symmetric encryption service

    • 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata
    • In total there is 2 AES-256 GCM keys for the database:
      • One for the user's sensitive data
      • One to use as pepper for encrypting the user's Argon2 password hash

  • Removed the need of storing credit/debit card information with the implementation of stripe as the payment gateway by Wei Ren

  • Integrated Cloudflare to the custom domain, coursefinity.social

    • Configured Cloudflare to redirect HTTP requests to use HTTPS
    • Enabled HTTP Strict Transport Security (HSTS) on Cloudflare
      • More secure than redirecting HTTP requests to HTTPS as the browser will know to automatically use HTTPS
        • Prevents man-in-the-middle attacks
      • More info on OWASP cheatsheet series

  • Enabled HSTS for the Flask web application to be hosted using Flask-Talisman

    • Flask-Talisman was originally created by Google but has not been maintained, hence, using a forked repository that is being maintained by Winterbloom and supported by other developers.
    • Since the web application will be hosted using gunicorn, I have configured the HTTP redirects to HTTPS and enabled HSTS to prevent MITM attacks.
      • Although we have already enabled it on Cloudflare, it would be a layered security as we are using Google Cloud Run to host the container which Google will provide a default URL.

Identification and Authentication Failures

Implemented:

guard otp demo gif

  • IP address-based authentication (Guard OTP)
    • Idea inspired by Steam Guard
    • Checks against known IP addresses of users against the login request
    • If the IP address is not known, the user will be asked to authenticate himself/herself using a randomly generated 16 characters code that is sent to the user's email
      • The 16 characters code is a randomly generated 12 bytes from Google Cloud Platform KMS Cloud HSM
      • The 16 characters code will also only be valid for 8 minutes
    • After a successful authentication, the new IP address will be saved in the database such that the web application will not do this verification again unless the IP address has not been accessed for more than 10 days

setup 2fa demo gif

  • 2 Factor Authentication using Google Authenticator Time-based OTP (TOTP)

    • A base32 encoded 20 bytes secret token (32 characters) will be generated using GCP KMS Cloud HSM and will be shared with the user
    • The user will be required to scan the QR code or enter the 20 bytes/32 characters setup key into Google Authenticator on their phone.
    • There will be backup codes for the user to use to recover his/her account in the event his/her device is lost and is unable to retrieve the 2FA codes.
      • Recommended by OWASP Multi-factor Authentication Cheat Sheet
      • Will generate 8 sets of 8 bytes hexadecimal single-use codes and save them in the database
        • The stored codes in the database are encrypted using Google Cloud Platform KMS Symmetric Encryption/Decryption

  • Implemented mitigations to deter/prevent automated attacks

    • Flask limiter
      • Rate limiting for routes that deal with identification and authentication in the web application to prevent brute-force attacks
        • Sensitive Pages: 9 requests/min
          • This configuration was also checked and refined by Eden as part of his security misconfiguration OWASP
    • reCAPTCHA Enterprise
      • Added on:
        • Login page
        • Reset password request page
        • IP address-based authentication (Guard OTP) page
      • Prevent automated attacks such as
        • Credential stuffing attacks
        • Brute force attacks

password complexity demo gif

  • Password Complexity Policy
    • Requires user to match at least 3 of the criteria stated below:
      • At least 1 uppercase letter
      • At least 1 lowercase letter
      • At least 1 digit
      • At least 1 special character
      • At least 8 characters
      • Not more than 2 repeated characters
    • Password strength meter to help users meet the password complexity policy
    • Verification of passwords if the passwords have been compromised using haveibeenpwned's API
      • Verified when:
        • After a successful login
        • Sign up
        • Changing password
        • Resetting password
      • If haveibeenpwned's API is unavailable, the password must match ALL the minimum password complexity policy criteria as a fallback
    • As recommended by:

too many login attempts demo gif

  • Maximum of 8 failed login attempts per account (will reset after 30 mins)
    • To prevent brute force attacks
    • If the attacker tries to do a denial-of-service attack knowing that one could lock out authentic users:
      • An email will be sent to the user's email with a one-time link that contains a token to unlock the account

session validations diagram

  • Session Management Implementation (Mainly using Flask session):
    • Session identifier of 32 bytes (Unlikely to be guessed) stored in the database.
      • Ensured high entropy by using Google Cloud Platform Key Management Service (KMS) Cloud HSM's RNG API
    • Configured the session cookie to be deleted from the browser once the user closes the browser.
    • After 1.5 hours of inactivity, the session identifier will be deleted from the database.
      • To invalidate the session identifier.
      • To free up space in the database.
      • Chose 1.5 hours as a video can last from several minutes to several hours for this web application.
        • Improve usability to avoid the legitimate user from being logged out after watching a video.
        • After an hour of inactivity, a modal message will appear to check if the user is active in order to extend the session expiry datetime.
    • Session validations upon each request to a web page:
      • Checks the session identifier and the userID in the database and compare them with the values in the cookie
      • Checks the user's digital fingerprint against the digital fingerprint in the database
        • Computes the SHA512 hash of the user's IP Address and user agent for the user's digital fingerprint for each request to the web application
          • If the user's digital fingerprint hash does not match the one in the database of the same session identifier, the user's session cookie will be cleared from their browser
        • Helps to prevent session hijacking via cookie theft
        • The idea was inspired by flask-paranoid
          • I did not use this library because it is not consistently maintained and it was easy to implement on top of my session management implementation
    • All mitigations above are aimed at mitigating the risk of session hijacking

Google OAuth2 login demo gif

  • Using Google OAuth2 for authenticating users

    • More info on OAuth
    • Security of the login process will be handled by Google as the user has to sign in with their Google account

  • A different method for logging in as an Admin (Using Google OAuth2)

    • Requires Google OAuth2 logins as identification and authentication will be handled by Google themselves which is more secure.
    • More secure as the admin does not use the same method of logging as normal users of the web application.
    • The admin routes are also IP address protected via a whitelist for extra security
      • Will retrieve the list of whitelisted IP addresses from Google Cloud Platform Secret Manager API for each request to the admin pages

  • Securing the session cookie by setting the correct attributes such as HttpOnly, Secure, etc.

    • Secure:
      • Only allow the cookie to be transmitted via HTTPS
        • Prevent the session cookie from being sniffed and exposed
    • HttpOnly:
      • Prevent client-side scripts from accessing the cookie
        • Prevent cookie theft

Eden:

Functionality Of Web Application

Implemented:

  • Review Feature
  • Course Page
  • Admin Management System

Selected OWASP Mitigations

Broken Access Control

Plan

  • Make a admin only file
    • Make a admin only files (such as a csv file of admin account info, user base info, etc.)
  • Validate access (deny by default) such as for admin pages, etc. through the use of RBAC
  • Deny request to a user's purchase course link
  • Block all read and write access to SQL database except for the web app
  • Work on integrating AWS Identity Provider with GCP Workforce Identification Pool
    • Since google-sm.json is stored locally in the web file system, it is a security risk as one might get a copy and have access to all the secrets stored in Google Secret Manager API.
  • Work on Admin console, a Super Administrator account must be created to access the admin console
  • Check for IDOR attacks
  • Layer for access control
  • allow for changes to the access control configuration
  • show different UI based on the RBAC

Implemented:

  • Roles:
    • Super Admin
    • Admin
    • Teacher
    • Student
    • Guest

These are the roles implemented. Super Admins have limited functionalities and only 1 super admin can be created at a time.

Super Admins are to manage the administrators,Roles,Creation of admin. Super Admins do not do the tasks of the admins.

Admins Can manage teachers and students, Admins can ban students, modify student behaviours.

Teachers have other functionalities such as creating courses, managing courses.

Students can view and purchase courses, a teacher can also do the roles a student has.

Guest requires an account to do any activities such as purchasing a course.

  • Role based Access Control which groups the app routes via Blueprints, access control is granted only to the specific blueprints group
  • Role Based Access Control for the MySQL Server
    • Removal of complex group in MySQL based on teachers recommendations
    • This is due to the complexities of the group role functionality
    • Reduce the permissions of the MySQL server to CRUD and Execute for calling stored procedures and functions, keeping security simple
    • Security of MySQL server depends on the web application to have proper Access Control

SAConsole

  • Implemented IDOR prevention against attackers guessing for AdminID on teacher page
    • Page will abort 404 if id doesn't exists
    • page will abort 404 if the id exist but role is not a teacher
  • RBAC will make Different roles see different content
    • Home page will be different for guest, admins , super admins and other roles
    • Certain UI will be different for each users

SAConsole

  • RBAC Console
    • super admin can change the app route group based access controls
    • Super admin can create google accounts
    • Super admin can edit and modify the admin users

SAConsole

SAConsole

Security Misconfiguration

Plan:

  • Check if there's unnecessary features
  • Showing too detailed error messages (such as in login pages)
  • Check vulnerabilities in dependencies used
  • Block users from access files outside of the web app
  • Disallow default admin password such as "admin123"
  • Ensure the web application has security in depth
  • Security features have to be layered
  • secure coding is practiced
  • separation of privileges
  • application should fail safely
  • Ensure RBAC are not hardcoded security constants
  • ensure the configuration of cache-control is secure
  • ensure the policies in-placed are of good security requirements
    • password policy
    • session policy
    • auto scheduler Policy
    • Cloudflare
    • google cloud configuration

Sources:

Implemented:

  • Currently we are using these third-party resources:

    • Docker Container
    • Google Cloud Storage
    • Cloudflare Dos protection
    • VdoCipher for video storage

  • Separation of user roles connecting to the mysql server

  • Separation of user role privileges in the mysql database

  • Checked if Flask App.py uses default configuration

    • Currently we have set the cookies to be ONLY HTTPS
      • Settings in the app ensures that cookies can only be send through HTTPS
      • Our website uses HTTPS through mkcert for localhost development and when hosted on Google Cloud Run it uses HTTPS by default
      • supported by the configuration of CSRF Cookie settings which are set to TRUE for HTTPS
      • Cookies are set to lax because setting it to STRICT comes with too much restriction to obtaining "more" security
      • https://stackoverflow.com/questions/41841880/what-is-the-benefit-of-blocking-cookie-for-clicked-link-samesite-strict
      • We may only implement cookies strict if we are securing against CSRF via get request and timing attacks but these are low chances as the tradeoffs for the user experience is significantly much worse
    • Debug Mode must be disabled when application is set to Production

  • Removal of any unused ports if any

    • Currently we are using port 8080 for the web application when hosted on Google Cloud Platform Cloud Run via gunicorn as specified by Google Cloud Platform Cloud Run documentation
    • The hosted server will listen on port 80 and port 443 for HTTP and HTTPS respectively

  • List of Files/Folders that must be disabled during production (due to possible attack surface)

    • For the sake of the technical review, they will be enabled
    • Folders that must be removed during production:
      • Sample files
        • Removal of demo files as they posed a security risk of default admin and unused accounts
      • Test files
        • These test files are used to demonstrate the OWASP security
    • Remove any unused HTML, JavaScript, and CSS Files

  • Edited Cache Control settings such that sessionIDs are not saved in cache

    • "Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the Cache-Control: no-cache="Set-Cookie, Set-Cookie2" directive, to allow web clients to cache everything except the session ID (see here)." -OWASP
    • response.headers["Cache-Control"] = "no-cache='Set-Cookie, Set-Cookie2', max-age=0"

  • Checked Security configuration of CloudFlare

    • Edited Cloudflare DOS protection to use the browser cache ttl of our server header
    • Edited Caching level to basic, no query string, this prevents public, max-age=3156000
    • ensure development mode is disabled
    • disabled web crawler hints
    • Not enabling the paid services such as Web application firewall as we do not have the money
    • Documentation:
    • Changes the SSL/TSL security to full(STRICT) This requires the server to have a trusted Certificate authority or cloudflare Certificate on the server

  • Ensure that admin,user and error pages specific webpages are not indexed by default(security by obscurity)

    • Only guest pages are indexed

  • Checked Google Cloud Platform SQL configuration settings

    • ensure that only whitelisted users can connect to the Google Cloud Platform as an administrator
    • Only ensure the minimum amount of users connected to the server which is root and CourseFinity
    • Ensure no unused databases are in the google cloud platform

  • Use of static code analysis to check for potential misconfiguration

    • bandit for python code analysis
    • Synk for dockerfile

  • DockerFile configuration has no medium-critical severity in the configuration file

    • currently the configuration has no available fixes for the Dockerfile

  • Error Pages are informative to users, does not reveal excessive information

  • Redirection confirmation when clicking outside links, ensures user take responsibility of checking the links before continuing

Redirection

Wei Ren:

Functionality Of Web Application

Implemented:

  1. Purchase History
  2. Purchase Details
  3. Upload Video
  4. Shopping Cart

Selected OWASP Mitigations

Insecure Design

Implemented

  • Stripe API

    • Error 402 (Payment Required) check
    • Double charge check
    • Checkout session expiry (when new session created)
    • Confirmation
      • Send receipt (Client side)
      • Record transaction (Server side)

  • VdoCipher Video Storage, Processing

    • Mpeg-DASH Video Player with randomised 'blob' (or byte/raw data) URL
    • DRM (Digital Rights Management) with CENC (Common Excryption) and EME (Encrypted Media Extension)
    • URL Whitelist to only play on the web app's domain
    • WARNING: Trial period lasts 30 days, and only allows up to 4 videos stored at any time.
    • Standardised error messages; processing, else success or failed

  • Console self-XSS warning

    • "Careful. This might not be what you think. This is a browser feature intended for developers. If someone told you to copy-paste something here to enable a CourseFinity feature or "hack" someone's account, it is probably a scam and will give them access to your CourseFinity account."

  • Add to cart validation

    • Own course
    • Purchased course
    • Inactive course
    • Already in cart
    • Full cart

  • Policies (Teacher's Handbook)

    • Video, thumbnail type accepted
    • Video, thumbnail size accepted

  • Contact Us Form

    • False positive reports must be rectified

Security Logging and Monitoring Failures

Implemented:

  • Google Cloud Logging (All logs sent to Google Cloud Logs)
    • Logging stack (app.py)
    • Log all logins (successful and failed logins)and server-side input failures (SQL query, etc.)
    • Alert the security teams and/or admins in the event of issues that cannot be fixed automatically.
    • Make use of built-in functions
      • Search logs by query (severity, timing, id)
      • View frequency of query (and types) over periods of time

Dropped Features

  • JWT Token
    • CourseCartIDs, UserID, for checkout
    • Video ID/Path, Teacher ID for video upload
  • Video Player
    • Video.JS
    • Shaka Player (Incomplete)
    • Video JS-Shaka Player
  • Video Conversion
    • Shaka Packager
    • Python ffmpeg_streaming package (Incomplete)
    • ffmpeg
    • mp4.to
  • Splunk Enterprise Logging
    • Python Backup File Collection (Automatic Collection Incomplete)
    • Failsafe: Temporary Local Storage if error

Calvin:

Functionality Of Web Application

Implemented:

  • User Profile
  • Course Video Upload
  • Course Video Management (Edit, Delete)
  • Search Bar
  • Explore Page
  • View All Course For a Particular Teacher
  • Pagination for above 4 pages (Edited By Jason)
  • Improvements of teacher page implemented by Jason

Selected OWASP Mitigations

Injection

Implemented:

  • Best Practices Followed

    • Using Development Tools Like Snyk to detect Unsafe code

    • SQL Injection

      • Remove & Avoid Using Dynamic SQL (String Concatenation)
        • If used string concatenation, it will accept malicious code as CODE instead of data. Because the command being run is fully made before passing into a function

    • Server Side Template Injection

      • Remove & Avoid using render_template_string(template)
        • render_template() is safer because users are unable to modify the template
      • Python templates engine API mechanisms enforce the separation between code and data (e.g. Jinja)

    • Code Injection

      • Remove & Avoid using:
        • exec() & eval()
          • The former expects a string representing a (single) valid Python expression, while the later can execute multiple expressions - making it able to create new module, class, and function definitions. Both functions have access to the global and local state at the point of invocation

    • Command Injection

      • Remove & Avoid using:
      • os.system()
      • os.popen()
      • They allow users to run commands to gain information of it

    • Cross Site Scripting

      • Remove & Avoid using render_template_string(template) (Example)
        • In Jinja, everything is escaped by default except for values explicitly marked with the "| safe" filter.
          • If required use Markup() or MarkupSafe()
          • Remove & Avoid {% autoescape false %}
          • Remove & Avoid .jinja2 extensions
          • Usage of url_for
      • Remove & Avoid using innerHTML, outerHTML, document.write() to stop DOM-Based XSS
        • These Javascript functions allow attackers to write scripts into the html
      • Use JSON.parse() for Javascript and not eval()

    • CRLF Injection

      • Remove & Avoid using CRLF as a special sequence
        • To avoid log poisoning et cetera

    • Regex Injection : Yes this exists

      • Testing of regex to ensure it returns what we want

  • Features Implemented

    • SQL Injection

      • Implement Parameterised Queries
        • Parameterized statements make sure that the parameters (i.e. inputs) passed into SQL statements are treated in a safe manner.
      • Implement Stored Procedures
        • Similar logic to Parameterised queries, by creating parameterised stored procedures. The interpreter will treat the data as DATA instead of Code

      parameterised queries
      parameterised queries 3

    • Command Injection

      • shell = False in subprocess_run()
      • Restrict Permitted Commands - Construct shell commands using string literals, rather than user input.
        • So that Users cannot pass in commands for the python interpreter to run
      • Uses subprocess_call() because it only runs one command when passed in a string

    • Cross Site Scripting

      • Implemented Flask Talisman
        • Set CSP, Perms Policy
        • Though some already done on Cloudflare,
          • Set for XSS Protection
          • HTTPS configuration to redirect HTTP requests to HTTPS
          • HSTS to ensure that HTTPS is used (Done On Cloudflare)
      • Implemented CSP
        • tell the browser to never execute inline JavaScript, and to lock down which domains can host JavaScript for a page. So if attacker manages to inject a script in. It still cannot run
          • Nonce-in only for inline scripts, those inline scripts without the nonce tags will not run properly
          • script src in csp shows all the scripts allowed to be taken from external sources
          • frame src in csp shows all the iframes allowed to be run
          • style src in csp shows all the css allowed to run
      • Escaping Dynamic Content for Markdown (HOWEVER, now unable to use list items et cetera, need to find a fix)
        • This is to let the browser know it is to be treated as the contents of HTML tags, as opposed to raw HTML.

      csp
      csp nonce
      CSP restriction

    • Cross Site Request Injection(?)

      • Implemented CSRF
        • Prevents victims from being tricked into sending a malicious request. Each request has a unique csrf token.

    • Host Header Injection

      • Generating Paths SAFELY
        • Attackers can manipulate data in their headers and poison the URL.
        • Using Constants to specify the path instead of taking it from host headers et cetera for absolute paths
        • Using relative urls where Possible

    • Regex Injection

      • Defined in Codebase, not generated directly from untrusted input
        • Attackers cannot take advantage of inefficient regular expressions. If generated directly, possibility of slow-running validation expressions causing them to DOS the server

      regex

    • Avoid Bad Coding Practices that lead to Injection Attacks

    • Sanitisation for All input

    • Escaping all input

      • Encoding it all
      • Output Encoding

    • Logging Of SQL Commands
      sql logging

  • Dropped Features (& Why):

    • Implement DDL Triggers (?)
      • It drops but immediately rollbacks. (Need deal with concurrency)

Software and Data Integrity Failures

Implemented:

  • Best Practices Followed

    • Code reviews to find bugs / errors

    • Usage Of HTTPS to send data from Client Side to Server Side

      • Provides encryption to ensure that it was the user that sent it

    • Usage of JSON data format, lesser chance of custom deserialisation logic

      • Lowers chance of insecure deserialisation

    • Removal Of Pickle due to high vulnerability in deserialization

    • Avoid using pickle, extremely vulnerable to insecure deserialisation

    • Usage of Python Modules such as JSON with built in encoders

      • Lowers chance of insecure deserialisation. It already encodes and decodes for the user

    • Secure Library Practices - Ensure that out libraries won't provide problems in the future

      • Keeping Libraries Up to Date
      • Usage Of Libraries That Have No known Vulnerabilities recorded
      • Usage of Libraries that are Trusted
      • Be careful Private Dependencies
      • usage of Pip Dependency Management

    • Infrastructure As Code Security

      • Develop & Distribute
        • Usage of Extensions such as Snyk to detect Potential Risks
          • Static Analysis Et cetera
        • Usage of Github for Version Control

  • Features Implemented

    • Flask Talisman

      • HSTS & HTTPS Encrypt the Hashes being sent from client to server

    • Implemented MySQL

      • Fix deserialization vulnerability with pickle (shelve) by changing to SQL

    • Comparing Hashes of Packages, before pip installing them

      • Ensures that there was no tampering between the files when it was being taken from the source
      hash comparison package

    • Storing of files in a cloud-based storage. Helps in isolation if file does contain malicious input google cloud bucket

    • Data Integrity For Profile Pictures hash comparison profile picture

    • Logging of Deserialization
      deserialisation logging

    Removed:

    • Check Hash of Video File, before saving it
      • Ensures that there was no tampering between the files when it was being taken from the source
      • Uploading to API directly, so removed

  • Dropped Features (& why?):

    • Digital Signatures
      • Not really necessary due to HTTPS & HSTS to ensure request is sent across HTTPS will already provide encryption
      • Redundant and may incur more errors
    • Digest Authentication
      • No use