research-school-2024/writeups/checklist.md

Security checklist

Note: This checklist is in-progress and it will change a lot over time.

• Are all user inputs validated and sanitized both on the back-end and front-end? For instance, verify the usage of regex patterns for validation of email formats. (SQL injection, XSS)
• Are database interactions done through parameterized queries? In SQL queries use prepared statements to avoid injections. (SQL injection)
• Does output encoding take place at every instance of dynamic content? Make use of HTML encoding functions to escape the user-generated content so that it cannot cause XSS. (XSS)
• Is CSP applied to limit script execution sources? Set a CSP header only allowing scripts from trusted domains. (XSS, data injection)
• Are proper authorizations in place for every action taken by users? Always check user roles and session cookies before allowing any user or admin functionality. (Authorization flaws)
• Are indirect object references applied wherever applicable? In URL's use GUID's or any other unique identifiers instead of incremental IDs. (IDOR)
• Does the application have anti-CSRF token? Create a unique token for each and every form submission which must be validated on server-side. (CSRF)
• Does an application set the SameSite attribute for cookies? Set SameSite=Strict or SameSite=Lax for session cookies. (CSRF)
• Is multi-factor authentication implemented? Require temporary TOTP code and/or verification email in order to avoid issuance of session tokens to unauthorized people. (Account takeover)
• Strong password policies are in place and require passwords to be at least 18 characters in length, mixing letters, numbers, and symbols. (Brute force attack)
• Sensitive data is encrypted in transit/rest. Use TLS for transport of data, use an extra layer of encryption for more sensitive data, never store passwords in plain text. (Data breach)
• Sensitive data is minimized. Where possible, store only the last four digits of the credit card number and NOT the full number. (Data exposure)
• Are the security configurations audited? Perform quarterly server configuration audits against security benchmarks. By default block all ports, check for rootkits, ensure remote access configuration is secure. (Misconfiguration, basic security)
• Are default settings reviewed and hardened? Change default passwords and disable unnecessary services on servers. (Misconfiguration, Exploitation of default credentials)
• Are the libraries and dependencies up-to-date? Automate dependency updates using Dependabot, etc. (various outdated library vulnerabilities)
• Is there a process to continuously monitor vulnerabilities? Send vulnerability alerts by subscription or with services such as Snyk. (Undetected vulnerabilities)
• Does it provide comprehensive logging, which includes capturing critical actions? Log all login attempts, including those failed, with timestamp and IP. Utilize software such as fail2ban to avoid mass brute-force attempts and block IP addresses. (Brute force attacks, Undetected attacks/vulnerabilities)
• Does your application implement measures to prevent botting? Implement mechanisms like CAPTCHA to avoid spam and botting attempts. (Brute force attacks, data control)
• Are there configured alerts for suspicious activities detected within logs? Configure alerts on multiple failed login attempts from the same IP address. (Brute force attack, unauthorized access)
• Is user-supplied URL validated against a whitelist? Only allow URLs matching specific patterns or domains. (Open Redirect, SSRF)
• Are outgoing requests monitored for abnormalities? Rate limiting on outgoing requests will help in identifying SSRF attacks. (SSRF)
• Are third-party services checked for security compliance before integration? Review of the security policy and implication of third-party APIs before their use. (Third-party risks)
• Are backups of critical data done regularly and tested for restoration? Schedule daily backups and conduct quarterly restoration tests. (Data loss)
• Are secure coding guidelines followed? Ensure that your code using generally accepted security practices and error checking. (Various vulnerabilities)
• Is your application well-defined, with roles and responsibilities for each part? Ensure your application does not handle everything in one place which can lead to error-prone code. (Design flaws, code smells)
• Are permissions set to least privilege? Restrict applications, processes, and service accounts to only what they need to function. (Privilege escalation)
• Are elevated privileges managed appropriately? If the application needs to operate with increased privileges, increase them as late as possible and decrease them as soon as possible. (Privilege escalation)
• Have you removed functionality not required before deploying? Make sure all features and files unused are removed in order to minimize attack surfaces. (Attack surface exposure)
• Is your security configuration store human-readable? This allows for auditing and helps maintain the security configurations transparently. (Misconfiguration)
• Are the development environments isolated from the production? Provide access only to the authorized development and test groups to minimize the risks. (Data exposure, unauthorized access)
• Do you have a software change control system? This is going to manage and track the changes of the code within development and production. (Change management issues)
• Is your cryptographic module peer-reviewed open source? Using trusted cryptography increases the level of security. (Weak cryptography)
• Are crypto-functions done on a trusted system? Ensure all cryptography operations are performed in a trusted environment. (Weak cryptography)
• Do your cryptographic modules fail securely? They shall be designed to prevent access by an unauthorized party during failure. (Data exposure)
• Are random elements created using approved methods? Use a cryptographic random number generator for all random data generation. (Predictable random values, cryptographic insecurity)
• Are your cryptographic modules in compliance with current standards, such as FIPS 140-2? Compliance means your cryptography meets recognized security benchmarks. (Weak Cryptography)
• Is there a policy in place for key management? Clearly detail how keys will be generated, stored, rotated, and destroyed. (Key Management Vulnerabilities)
• Are secret keys properly protected from unauthorized access? Store keys in a secure vault or hardware security module. (Key Exposure)
• Are uploads restricted to required file types? Only allow specific types of files and perform a file header check rather than relying on extensions. (Malicious file upload)
• Does your application authenticate a user before uploading? Prevents an attacker from uploading a malicious file that they might subsequently access or execute. (Malicious file upload)
• Are execution privileges disabled for upload directories? Will minimize the risk of a user uploading some scripts to be executed by a user. (Remote code execution)
• Do you allow-list file names and types? Use an allow-list to reference existing files to avoid unauthorized access or execution of files. (Malicious file upload)
• Does the client not see the absolute file path? Never disclose internal paths; application files should be read-only by the client. (Information disclosure)
• Are the uploaded user files scanned for malware? Scanning can be put in place for the detection and mitigation of potential threats from uploaded content. (Malicious file upload)
• Have you classified all the data sources? Classification of data as trusted and untrusted helps a great deal in carrying out efficient input validation. (Input validation issues)
• Is each input data from an untrusted source validated? Make sure the input string corresponds to expected formats and constraints to avoid injection attacks. (Injection attacks)
• Is canonicalization used while validating inputs? This will make sure that the format of input provided is standardized to help defeat obfuscation attacks. (Injection attacks)
• Are threat models made as part of design? It involves identification of potential threats and vulnerabilities at an early phase in a project. (Understanding your threat model)
• Are security patches to software and systems applied in a timely manner? Devise a regular schedule to apply updates and patches within a week of the release. (Exploitation of known vulnerabilities)
• Is the security software installed on every device? Ensure each has antivirus and anti-malware solutions installed and current, such as ClamAV. Firewalls and log monitoring should be installed. (Malware infection)
• Are scans for vulnerabilities and abnormalities automated on a regular schedule? Perform monthly scanning of applications and systems for the opening of new vulnerabilities. Access to log files and usage of unusual resources. (New vulnerabilities)
• Is reverse proxy correctly configured, is the reverse proxied application correctly configured to run in a Production environment? Ensure application is in production mode over debug mode so it will stop leaking sensitive information along with debug logs. (Information disclosure)
• Would your application be secure even if everything, but the secret keys protecting the data and application, were public? Make sure your application, even if it was open source, is secure, no matter how open the source is. (Data exposure)
• Does your application pass security and linting checks of common sanity checkers and linters such as pylint, pyright, pyflakes, bandit, and safety? Such tools are useful to ensure your code complies to utmost security standards. (Various vulnerabilities and style)
• Does your testing framework implement static and dynamic code analysis? Ensure better security by using various types of code analysis. (Testing)
• Does your application ensure that buffers are protected, boundaries are checked, and buffer overflows are catchable? If not, implement ways to secure allocated buffers and add boundary and limit checks. (Data handling, exposure, and overflow)
• Are cryptographically secure keys used for access of systems over passwords? Ensure security and convenience by using keys over passwords. (Secure access)