Top Ten Proactive Web Security Controls v5

Editor's Notes

• #8: Creating an awareness of the system’s Attack Surface, trying to minimize it where possible, understanding when/how you are increasing it and understanding that this increases the risks of attack. For example, anonymous public access to the system, file uploads and interfaces to external systems are all potentially serious sources of security risk. Platform selection: language(s), O/S, web server, database or NOSQL data manager, etc. These architectural choices result in technology-specific security risks and constraints that the team needs to learn about and understand. Know your tools.
• #10: Business logic requirement Multi-step multi-branch workflow Unable to test properly unless you understand the business Can often be very complex and difficult to test completely
• #21: Guidance   Do not defeat users’ attempts to secure their credentialslimit type of characters or length of user passwords Some organizations restrict the 1) types of special characters and 2) length of credentials accepted by systems because of their inability to prevent SQL Injection, Cross-site scripting, and analogous command-injection attacks. However, secure password storage mechanisms possess design elements that prevent length, constituency, and even encoding from subverting system security. Do not apply length, character set, or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to rendering this information when applicable.   
• #22: Salts serve two purposes: De-duplicate protected output of identical credentials and Augment entropy fed to protecting function without relying on credential complexity. The second aims to make pre-computed lookup attacks [*2] on an individual credential and time-based attacks on a population intractable.
• #23: HMACs inherit properties of hash functions including their speed, allowing for near instant verification. Key size imposes intractable size- and/or space- requirements on compromise--even for common credentials (aka password = ‘password’). Designers protecting stored credentials with keyed functions:   Use a single “site-wide” key;   Protect this key as any private key using best practices; Store the key outside the credential store (aka: not in the database); Generate the key using cryptographically-strong pseudo-random data; Do not worry about output block size (i.e. SHA-256 vs. SHA-512). Example protect() pseudo-code follows: return [salt] + HMAC-SHA-256([key], [salt] + [credential]);   Upholding security improvement over (solely) salted schemes relies on proper key management.   Design protection/verification for compromise The frequency and ease with which threats steal protected credentials demands “design for failure”. having detected theft, a credential storage scheme must support continued operation by marking credential data compromised and engaging alternative credential validation workflows as follows:   Protect the user’s account Invalidate authN ‘shortcuts’ disallowing login without 2nd factors or secret questions Disallow changes to account (secret questions, out of band exchange channel setup/selection, etc.) Load & use new protection scheme Load a new (stronger) protect(credential) function Include version information stored with form Set ‘tainted’/‘compromised’ bit until user resets credentials Rotate any keys and/or adjust protection function parameters (iter count) Increment scheme version number When user logs in: Validate credentials based on stored version (old or new); if old demand 2nd factor or secret answers Prompt user for credential change, apologize, & conduct OOB confirmation Convert stored credentials to new scheme as user successfully log in   Supporting workflow outlined above requires tight integration with Authentication frameworks and workflows. http://www.tarsnap.com/scrypt/scrypt.pdf  
• #24: Impose intractable verification on [only] attacker The function used to protect stored credentials should balance between A) acceptable response time for verification of users’ credentials during peak use while B) placing time required to map <credential> → <protected form>  beyond threats’ hardware (GPU, FPGA) and technique (dictionary-based, brute force, etc) capabilities. Two approaches facilitate this, each imperfectly. Leverage an adaptive one-way function - Adaptive one-way functions compute a one-way (irreversible) transform. Each function allows configuration of ‘work factor’. Underlying mechanisms used to achieve irreversibility and govern work factors (such as time, space, and parallelism) vary between functions and remain unimportant to this discussion. Select:   PBKDF2 [*4] when FIPS certification or enterprise support on many platforms is required; Scrypt [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t. Example protect() pseudo-code follows: return [salt] + pbkdf2([salt], [credential], c=10000);   Designers select one-way adaptive functions to implement protect() because these functions can be configured to cost (linearly or exponentially) more than a hash function to execute. Defenders adjust work factor to keep pace with threats’ increasing hardware capabilities. Those implementing adaptive one-way functions must tune work factors so as to impede attackers while providing acceptable user experience and scale. Additionally, adaptive one-way functions do not effectively prevent reversal of common dictionary-based credentials (users with password ‘password’) regardless of user population size or salt usage.   Leverage Keyed functions - Keyed functions, such as HMACs, compute a one-way (irreversible) transform using a private key and given input. For example, HMACs inherit properties of hash functions including their speed, allowing for near instant verification. Key size imposes intractable size- and/or space- requirements on compromise--even for common credentials (aka password = ‘password’). Designers protecting stored credentials with keyed functions:   Use a single “site-wide” key;   Protect this key as any private key using best practices; Store the key outside the credential store (aka: not in the database); Generate the key using cryptographically-strong pseudo-random data; Do not worry about output block size (i.e. SHA-256 vs. SHA-512). Example protect() pseudo-code follows: return [salt] + HMAC-SHA-256([key], [salt] + [credential]);   Upholding security improvement over (solely) salted schemes relies on proper key management.   Design protection/verification for compromise The frequency and ease with which threats steal protected credentials demands “design for failure”. having detected theft, a credential storage scheme must support continued operation by marking credential data compromised and engaging alternative credential validation workflows as follows:   Protect the user’s account Invalidate authN ‘shortcuts’ disallowing login without 2nd factors or secret questions Disallow changes to account (secret questions, out of band exchange channel setup/selection, etc.) Load & use new protection scheme Load a new (stronger) protect(credential) function Include version information stored with form Set ‘tainted’/‘compromised’ bit until user resets credentials Rotate any keys and/or adjust protection function parameters (iter count) Increment scheme version number When user logs in: Validate credentials based on stored version (old or new); if old demand 2nd factor or secret answers Prompt user for credential change, apologize, & conduct OOB confirmation Convert stored credentials to new scheme as user successfully log in   Supporting workflow outlined above requires tight integration with Authentication frameworks and workflows. http://www.tarsnap.com/scrypt/scrypt.pdf  
• #26: > Also, SMS can be defeated a number of ways, fro SIM swop fraud > (http://financialcryptography.com/mt/archives/001349.html), to Zitmo's > patching at the kernel (SMS is sent/received via the socket API), to > simply being the highest priority receiver and swallowing the SMS on > Android (https://groups.google.com/d/msg/android-security-discuss/TURchbIN_LE/8x69SeMF7eQJ). So it reduces risk but is not full proof. Hi Jim, Below is the reference for the statement that US banks suffer fraud at 600x the rate of a DE bank. It's from Gutmann's Engineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎), page 542. The effect of different banks’ attitudes towards password security (and security in general) is shown in phishing loss figures, with losses in the UK, which has traditionally used straight passwords, being eight times higher than in Germany, which used to use TANs and has since moved on to even stronger measures. Similar sorts of figures are given in a comparison of US and Asian banks, who use (real) two-factor authentication, perform comprehensive analyses of electronic crime incidents, and in general are concerned about their reputation and image and are prepared to invest extra effort to protect them. For example one Japanese bank maintains multiple independent security-audit/assessment teams, often using two or more teams to check a particular system, with the different teams acting as a cross-check on each others’ performance. The bank’s security people plant known vulnerabilities in order to verify that their auditing teams are catching things, and rate each team’s performance against that of the others. At the end of the year the lowest-performing team for that year gets reassigned to other work, and new auditors/assessors are brought in to replace them. The losses due to electronic crime like phishing and malware for these banks is twenty-five times lower than for equivalent US banks [100]. In contrast in the US, where banks not only use straight passwords but as previous chapters have pointed out actively train their customers to become phishing victims, phishing losses are a staggering six hundred times higher than in Germany [101].
• #41: Other problems : what else is wrong with this code?
• #52: HTML Contexts Encode#forHtmlContent(String) Encode#forHtmlAttribute(String) Encode#forHtmlUnquotedAttribute(String) XML Contexts Encode#forXml(String) Encode#forXmlContent(String) Encode#forXmlAttribute(String) Encode#forXmlComment(String) Encode#forCDATA(String) CSS Contexts Encode#forCssString(String) Encode#forCssUrl(String) JavaScript Contexts Encode#forJava(String) Encode#forJavaScript(String) Encode#forJavaScriptAttribute(String) JavaScript attribute Encode#forJavaScriptBlock(String) JavaScript block Encode#forJavaScriptSource(String) JavaScript source URI/URL contexts Encode#forUri(String) Encode#forUriComponent(String)
• #67: Pinning is a key continuity scheme, and the idea is to either (1) carry around a copy of the server’s public key; or (2) note of the server’s public key on first use (Trust-on-First-Use, Tofu). The former is great if you are distributing a dedicated client-server application since you know the server’s certificate or public key in advance. The latter is useful when no a priori knowledge exists, such as SSH or a Browser. Both detect the unexpected change that occurs when an imposter with a fake certificate attempts to act like the real server.   While you have a choice to pin the certificate or public key, it’s often best to pin the public key. That is because some companies, such as Google, rotate its certificate regularly (every 30 days or so) but re-certifies the inner public key.
• #81: AES Keys AES provides authenticated encryption through use of HMAC_SHA1 and AES. AES keys consist of the following fields: "mode": A CipherMode. Currently "CBC" is the only mode supported. "aesKeyString": A WebSafeBase64 representation of the raw AES key bytes. "hmacKey": A JSON representation of an HmacKey used to sign ciphertexts. The block size is 128 bits.