The SMART DEVELOPER’S The SMART DEVELOPER’S CHEAT SHEET CHEAT SHEET for Secure APPlications for Secure APPlications Trouble cannot be avoided , you either go looking for it or it will come looking for you. “ “ Constance Friday Contents How You Should Use This Guide 4 This Is Important Because Hackers Will Target You 5 The Business Case 6 Authentication Verification Checklist 10 Session Management Checklist 11 Access Control Checklist 12 Input Validation & Output Encoding Checklist 14 Cryptography Checklist 16 Error Handling & Logging Verification Checklist 17 Data Protection Checklist 18 Communications & Data Transport Tests 20 Malicious Code & Business Logic Tests 21 File & Resources Checklist 22 API Checklist 23 Where Are You In Your Journey? 24 /company/audacix /audacix audacix.com solutions@audacix.com How You Should Use This Guide We’ve created this guide to help you and your team deliver (almost) un-hackable web applications that reduce the chances of you being breached by hackers to almost zero. Here’s what you should do with this information: Apply It When Designing New Features Ask your architects to assess the security of their designs based on these tests. Verify compliance with these rules before approving new designs Apply It When Writing New Code Ask your developers to identify which of these tests their code needs to comply with before writing any code Verify compliance with these rules when conducting code reviews - ADVANCED STEP - Include It In Developers’ KPIs No initiative will work unless responsibility is assigned & it is measured This will help change your culture where great apps are built to one where great & SECURE apps are built 1. 2. 3. /company/audacix /audacix audacix.com solutions@audacix.com 1+6 Reasons This Checklist Should Matter To You 39 % greater vulnerability of large companies to insider threats, as compared to SMBs 4 x easier to breach medium-sized companies through social engineering, than large companies 61 % of breach victims in 2017 were businesses with under 1,000 employees 77 % 50 days to recover from a cybersecurity attack 43 % of remediation costs are spent on recovering lost data 36 % of vulnerabilities in applications are classified “high risk” Sources: Ponemon Institute, Coalfire, IBM Security, Accenture of tech buyers consider cybersecurity before making purchasing decisions /company/audacix /audacix audacix.com solutions@audacix.com The Business Case The PCI DSS standard, with which all companies that deal with financial transactions online have to comply, requires that a full penetration test be conducted “at least annually.” Most cybersecurity experts also agree that you should conduct a thorough penetration test on your applications at least annually, but more often if you introduce significant changes to your code base. Remember, significant changes include new code as well modifications to existing code, espcially if this is custom code. This is because: “93% of cybersecurity vulnerabilities come from custom code” - Helpnet Security What Does This Actually Mean? We find that most SaaS and digital teams see at least a 20% change in their code base every quarter. So should you be conducting thorough penetration tests every quarter? /company/audacix /audacix audacix.com solutions@audacix.com Probably, but it’s never that simple, is it? Penetration tests are time-consuming, intricate and, therefore, expensive. Especially if you don’t have an in-house security team and you need to rely on specialist external partners to conduct your penetration tests. So How Can I Increase The Gaps Between Pen Tests? By doing these three things: 1. Transforming the culture of your development and delivery team from one where cybersecurity is an afterthought, to one where cybersecurity is enmeshed into every phase; 2. Assigning responsibility to various people throughout your development and delivery processes to ensure compliance with secure development practice; and 3. Building the achievement of cybersecurity KPIs into performance reviews. We know that culture eats strategy for breakfast. This is best represented by the airline industry where over time, established, full-service airlines have embedded a culture of safety into their employees’ every action. These carriers have fewer serious safety incidents as compared to their newer rivals who simply haven’t had the time or haven’t understood the financial and marketing importance of focusing on saftey as a hygiene factor in their operations. /company/audacix /audacix audacix.com solutions@audacix.com We also know that culture is not easy to change, which is why the second and third suggestions above are key to accelerating the rate at which your team transforms from delivery great applications, to delivering great and secure apps. When your applications are built secure from the first line of code, you will naturally be able to increase the gap between penetration tests on your application and infrastructure. You will know when you are ready to do this because successive penetration tests will find not find any vulnerability regressions and any vulnerabilities found will be of low-risk. After all, strong foundations will always ensure that your house needs less maintenance and stays standing well after we have finished enjoying its utility. Next Steps The checklists outlined in this guide are a subset of those that are tested during a full and thorough penetration test. These checklists don’t represent everything that is tested in a pen test. However, by asking your architects and developers to include these checks in their daily activities you will be initiating the process that helps to eventually minimise your ongoing cybersecurity risk minimisation costs. Good luck and congratulations for taking this first step. Ayush Trivedi Director & Co-founder Audacix Knowledge without execution is like a great book that’s never been read. “ “ Christopher Crawford /company/audacix /audacix audacix.com solutions@audacix.com Authentication Verification Checklist These tests have two primary goals: • To validate that communication is happening between verified parties; and • Ensure that legitimate system users are able to authenticate using encrypted channels. Ensure that: that your application adheres to these mechanisms: 1. Is server-side authentication required for all non-public user interfaces? 2. Is auto-fill disabled for all user authentication credentials? 3. Are passwords required to be long and complex? 4. Is a user required to enter the existing password before changing their password? 5. Are all successful and unsuccessful user authentication attempts logged? 6. Are all passwords one-way hashed with a savlt? 7. Is all authentication data encrypted during transmission? 8. Are users required to re-authenticate after updating sensitive information like usernames, passwords, email addresses, etc? 9. Is two-factor authentication (2FA) available as an option to users? /company/audacix /audacix audacix.com solutions@audacix.com Session Management Checklist These tests have two primary goals, to validate that: • Sessions are unique and cannot be guessed or shared; and • Sessions are terminated when not required or after an extended period of inactivity. Poor session handling results in many security vulnerabilities, so pay careful attention to these: 1. Are sessions invalidated when the user logs out? 2. Are session timeout limits configurable by administrators? 3. Can a user logout easily from any non-public user interface? 4. Does the application check that it has issued a session ID before accepting it as active? 5. Are session IDs random and otherwise hard to guess, even for powerful computers? 6. Do cookie-based session IDs have the ‘HttpOnly’ and ‘Secure’ cookie flags enabled? 7. Can a user terminate all sessions globally, eg. across devices, from their account? 8. Does the application prompt the user to terminate all other sessions after changing their password? /company/audacix /audacix audacix.com solutions@audacix.com Access Control Checklist These tests have these primary goals, to validate that: • Users privileges are well defined so that users can only access those screens to which they have explicit access; and • Role and permission metadata is protected from replay or tampering. Ensure that you build these control mechanisms into your application: 1. Does a centralised mechanism manages access to all protected resources? 2. Can users tamper with parameters to access restricted pages / functions? 3. Where not required, are users prevented from browing server directories? 4. Are access control rules are mirrored between the application and its servers? 5. Is access and modification rights for all user and data attributes and policy information restricted to admin users? 6. Does the application restrict access to secured functions, resources and data? 7. Ensure that all access control decisions can be logged and particularly that all failed decisions are logged. 8. Ensure that the application or framework uses strong random anti-CSRF tokens or has another transaction protection mechanism. Learn how your competitors grow sales by proving their app is secure Learn how to protect your web & mobile apps & infrastructure from cyber attacks Learn how your dev team can deliver more secure apps with every release Help your profits scale new peaks with our Cybersecurity Mastermind Sessions /company/audacix /audacix audacix.com solutions@audacix.com Input Validation & Output Encoding Checklist These tests have two primary goals, to validate that: • Inputs are validated to be correct and fit-for-purpose; and • Data from external sources should be appropriately verified before ingestion. OWASP believes these to be critical in preventing common attacks like XSS or SQL injections: 1. Ensure that input validation routines are enforced on the server-side and all input validation failures result in request rejection and logging. 2. Is all input validation controlled by a centralised mechanism? 3. Are all parameterised database queries protected by a proper ORM application? 4. Are file path locations obfuscated where the path is not required to be displayed? 5. Are all string variables contextually encoded? 6. Is all input data validated before being stored or transmitted? 7. Are all unstructured data inputs sanitized for allowed characters and length, eg. postcodes, phone numbers, etc? 8. Is all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature? /company/audacix /audacix audacix.com solutions@audacix.com 9. Are safe JavaScript methods used where data is transferred between DOMs? 10. Is JSON.parse, not eval(), used to parse JSON in browsers and Javascipt backends? 11. Does that the application restrict XML parsers to only use the most restrictive configuration possible? 12. Does the application prohibit dangerous features such as the resolution of external entities? 13. Is the processing of unstructured data strongly protected where deserialization is unavoidable? /company/audacix /audacix audacix.com solutions@audacix.com Cryptography Checklist To ensure that application’s encryption methods are sound, with two primary goals: • Access to keys, and encryption failures and errors are handled securely; and • A suitable random number generator is used when randomness is required. Key protections to implement in application development include: 1. Are all random numbers, random file names and random strings are generated using an approved random number generator? 2. Does an explicit policy manage cryptographic keys and the key lifecycle? 3. Is all personally identifiable information encrypted when stored? 4. Are passwords, keys or other sensitive material that are maintained in memory overwritten with zeros as soon as they is no longer required? 5. Are all keys and passwords replaceable and required to be changed if automated passwords are used for first login? /company/audacix /audacix audacix.com solutions@audacix.com Error Handling & Logging Verification Checklist This category of tests has these primary goals, to validate that: • Sensitive data is only logged if specifically required; and • All logs are protected and log lifetimes are minimised to the shortest practical time required; and Key protections to implement in application development include: 1. Has all sensitive information been removed from error messages and stack traces? 2. Is access denied by default in error handling logic for security controls? 3. Are all security-relevant events logged with appropriate timestamps and metadata? 4. Does the application prevent untrusted data from being executed as code? 5. Are unauthorised users prevented from accessing all security logs? 6. Does the application prevent sensitive data including user session identifiers, passwords, hashes, or API tokens, from being logged? /company/audacix /audacix audacix.com solutions@audacix.com Data Protection Checklist OWASP believes data protection tests have three primary goals, to validate that: • Confidentiality: data should be protected from unauthorised observation or disclosure both in transit and when stored; and • Integrity: unauthorised users should not be able to create, alter or delete data; and • Availability: data should be available to authorized users as required. You should write code assuming that all user devices are compromised to varying degree, so: 1. Is client-side caching disabled on forms with sensitve data? 2. Is all sensitive data sent to the server in the HTTP message body or headers, not through URL parameters? 3. Are anti-caching headers used to prevent the client-side storage of sensitive data? 4. Are all attempts at accessing sensitive data logged? 5. Is all authenticated data cleared from browser DOMs and other client-side storage after a session is terminated? Learn how your competitors grow sales by proving their app is secure Learn how to protect your web & mobile apps & infrastructure from cyber attacks Learn how your dev team can deliver more secure apps with every release Transform defence into attack. Learn how with our Cybersecurity Mastermind Sessions /company/audacix /audacix audacix.com solutions@audacix.com Communications & Data Transport Tests Communications and data transport standards have two primary goals, to validate that: • Transport Layer Security (TLS) is used where data is transmitted; and • Strong algorithms and ciphers are used at all times. Key protections to implement in application development include: 1. Does the application verify the path from a trusted certificate authority to each TLS server certificate, and verify that each server certificate is valid? 2. Is TLS v1.2 used for all authenticated connections (including both external and backend connections)? 3. Are all connections to external systems authenticated? 4. Ensure that TLS certificate public key pinning (HPKP) is implemented with production and backup public keys. 5. Are HTTP Strict Transport Security headers included on all requests? 6. Is Online Certificate Status Protocol (OCSP) stapling enabled?