Secure Software Development | Information Security Guideline | Version 2.1
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 1 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI Communications Security [DG 1-1] Utilize TLS certificates issued by the officially supported certification authority issued for the correct domain scope. Do not utilize self-signed TLS certificates.
Ensure components requiring TLS connectivity cease to function if TLS certificates are invalid (expired, X X X revoked, not issued from a trusted authority, not issued for the correct subject, etc.). If possible, implement OCSP stapling to enhance the usability and availability of Online Certificate Status Protocol validation. If possible, implement HTTP Public Key Pinning to resist man-in-the-middle attacks.
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 2 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 1-2] Ensure login form pages and other pages used to submit sensitive data to or retrieve sensitive data from the server are loaded over strongly encrypted TLS 1.2+ connections. Protocol obfuscation is not X X X a sufficient means of protecting data transmissions. [DG 1-3] Ensure authentication credentials, security tokens, and session identifiers are only sent over strongly encrypted TLS 1.2+ connections. Protocol obfuscation is not a sufficient means of protecting data X X X transmissions. [DG 1-4] Disable HTTP and other clear text communication protocols for access to protected resources. If HTTP is required for initial ease of availability (e.g., for an external customer typing a domain name into a web browser address bar), redirect all HTTP requests to HTTPS and avoid transmitting sensitive X X X information in requests and responses until HTTPS is in use. Encrypt the channel for all communications involving protected resources. [DG 1-5] Send and receive sensitive communications (e.g., Top Secret, Confidential, PCI, PII, HIPAA/HITECH, SOX, proprietary, or otherwise used in decisioning) exclusively over encrypted HTTPS, encrypted IPsec, or equivalently encrypted channels. Use HTTP Strict Transport Security (HSTS) headers to force user agents to connect to domain names X X X only over HTTPS. The “max-age” attribute value should be far in the future (e.g., 7776000, representing 90 days) and should be the same value in every response. Include the “includeSubDomains” attribute. Include the “preload” attribute and submit the domain to browser vendor HSTS preload lists (e.g., https://hstspreload.appspot.com/). [DG 1-6] Use a 2048-bit or larger RSA modulus in certificate generation. X X X [DG 1-7] Issue and use certificates only with the correct trust anchor and chain of trust order. X X X [DG 1-8] Disable client-initiated TLS renegotiation. X X X [DG 1-9] Disable TLS compression. X X X [DG 1-10] During the TLS handshake, select the strongest cipher suite supported by both the client and server. X X X [DG 1-11] TLS connections should use TLS 1.2 or higher. Disable SSL 2.0, SSL 3.0, and TLS 1.0. X X X [DG 1-12] Disable TLS cipher suites utilizing the following components: For key exchange: • Anonymous Diffie Hellman algorithm (no authentication) For bulk encryption: • Camellia algorithm • DES and 3DES algorithms • IDEA algorithm • RC4 algorithm • SEED algorithm • Block sizes under 128 bits X X X • Electronic codebook (ECB) mode For message authentication: • MD5 algorithm • MD2 algorithm
If possible, avoid operating bulk encryption algorithms in cipher block chaining (CBC) mode.
If possible, support the following components: • Key exchange algorithms that support forward secrecy, including Diffie Hellman and Elliptic Curve Diffie Hellman. Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 3 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI • Authenticated encryption with associated data (AEAD), including AES-GCM and ChaCha20- Poly1305. [DG 1-13] For protected resources, ensure that active content (e.g., scripts, CSS, embedded controls, and XMLHttpRequest requests) is embedded and loaded with HTTPS URIs to avoid man-in-the-middle attacks and browser blocking of “mixed content.” Consider loading passive content (e.g., images and HTML5 video) over HTTPS to avoid man-in-the-middle attacks and browser warnings. Where third party APIs do not support encrypted channels, perform pre-load data validation to ensure X X X malicious content cannot be executed unwittingly or through social engineering. Refer to the W3C Mixed Content specification and individual browser vendors to determine what content types are “blockable” and “optionally-blockable.” [DG 1-14] Use a cryptographically strong signature algorithm in certificate generation. Do not use MD5 or SHA-1. X X X Privacy [DG 2-1] Do not pass sensitive parameters, including PCI data, GLBA data, HIPAA/HITECH data, SOX data, PII data, transactional data, security tokens, session identifiers, or passwords within the URL request path. When parameters must be logged, utilize the application server platform’s supported logging X X X mechanism in a secure manner (see DG 9-6). [DG 2-2] Apply the following anti-caching HTTP headers to pages containing identifiers (e.g., username, email address, and account number), form input fields for identifiers (e.g., input fields on login, registration, forgotten password request, forgotten username request, forgotten associated email request, and username change workflows) and other sensitive form fields: X X X Cache-Control: no-cache, no-store Expires: 0 [DG 2-3] Apply the following anti-caching HTTP headers to pages containing sensitive information: Cache-Control: no-cache, no-store Expires: 0 X X X Ensure end user agents observe anti-caching headers. [DG 2-4] Never return passwords to clients, including for forgotten password requests, and limit returning other unnecessary sensitive information (visible or otherwise). X X X [DG 2-5] Never permit passwords to be displayed (e.g., in form fields). X X X [DG 2-6] Set the TYPE attribute to PASSWORD for HTML password fields. X X [DG 2-7] Do not cache passwords. X X X [DG 2-8] Set the AUTOCOMPLETE attribute to OFF for HTML password fields, credit card numbers, and other sensitive form fields. X X [DG 2-9] Ensure files persisted to disk during application usage are only accessible with appropriate permissions by authorized users. X X X [DG 2-10] Do not unnecessarily persist files (especially those containing sensitive data elements) to disk. X X X [DG 2-11] Delete data files containing sensitive information after use. Securely overwrite data files containing sensitive information with a cryptographically random data sequence prior to deletion. X X X [DG 2-12] Scrub sensitive data from memory (e.g., sensitive variables) as soon as possible after use. X X X [DG 2-13] Protect temporary files. Only write temporary files to the runtime-specific temporary directory, and ensure the filenames of temporary files are generated randomly. X X X [DG 2-14] Clear payment card information stored for non-recurring payments (i.e., payment for web purchases) upon successful completion of a password change initiated using an out-of-band activation X X code sent in response to a forgotten password request. Password/PIN Length and Complexity Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 4 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 3-1] Permit one password change per user per day. X X X [DG 3-2] Do not permit the ability to change the password to the most recent value. X X X [DG 3-3] For employees, do not permit reuse of the previous six (6) passwords. For elevated access such as administrator or service accounts, do not permit reuse of the previous twenty (20) passwords. For X X X customers, do not permit reuse of the previous password. [DG 3-4] Require passwords to have a minimum length of eight (8) characters for employees, sixteen (16) characters for elevated access such as administrator or service accounts, or six (6) characters for X X X customers. If possible, permit passwords to have a length of up to 64 or more characters. [DG 3-5] Permit passwords to contain uppercase letters, lowercase letters, digits, and special characters including but not limited to ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } and ~. X X X Treat uppercase and lowercase versions of the same letter as distinct characters.
[DG 3-6] For employees or for elevated access such as administrator or service accounts, do not permit the following types of passwords: • Passwords including the user’s username in any combination of casing. For example, the user “jdoe” would not be permitted to have a password of “3jDOE4”. • Passwords based on simple constructions of identifying information entered during registration sequences. For example, John Doe, born February 19, 1991, with a phone number of 555-777- 7777, and username of “mr_doe”, would not be permitted to have a password of “johndoe”, “2/19/91”, or “5557777777”. • Passwords listed in various top 1,000; 500; 200; and 100 most common passwords lists. For example, no user would be permitted to have a password of “mountain”. • Passwords based on dictionary words (in any language). X X X • Passwords matching known weak password patterns. For example, no user would be permitted to have a password containing only repeated characters (e.g., “1111111”, “YYYYYYYYYY”, “;;;;;;;;;;;;;;;;;;;”) or obvious sequences (e.g., “98765432”, “asdfghjk”, “ASDFASDF”, “HIJKLMNOP”, “!@#$%^&*”).Passwords matching a component of the application’s domain (or, for servers without a domain name, the server name). For example, no user would be permitted to have a password of “screenshots” or “thisisareallyfunwebsite” if the domain name of hosted content was screenshots.thisisareallyfunwebsite.com. • Passwords matching simple constructions of the friendly name or web path of the application’s name. For example, no user would be permitted to have a password of “PURCHASETOOL” or “employeepurchasing” if the friendly name of an application was “Purchase Tool” and the URL of the hosted content was http://screenshots.thisisareallyfunwebsite.com/apps/employeepurchasing. [DG 3-7] Require passwords to meet password complexity requirements as appropriate to the type of account. For employees or elevated access such as administrator or service accounts, require that passwords contain at least three of the four character classes of uppercase letters, lowercase letters, X X X digits, and special characters. For customers, require that passwords contain at least one digit, and also contain at least one uppercase or lowercase letter. Treat uppercase and lowercase versions of the same letter as distinct characters. [DG 3-8] Do not provide unnecessarily verbose explanations to end users violating password rules when attempting to set a password. Provide generic explanations to end users violating password rules when attempting to set a password. For example: • The password entered was too short. X X X • The password entered doesn’t contain the following required types of characters.
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 5 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI • The password entered looked like an easily guessable sequence (e.g., 12345678). • The password entered looked like a commonly used password. The password entered looked like part of our site name. [DG 3-9] For customer facing technology, protect customers from selecting weak or insecure passwords by at least one of the following means, in addition to refusal of passwords equivalent to the username: • Refusal of any password contained in the EIP Weak Password List. Do not present the contents of the EIP Weak Password List to the client. X X X Implementation of a password strength meter that educates the user when passwords are insecure in nature. Insecure passwords include short passwords, non-complex passwords, passwords containing the username in any casing, passwords containing a component of the application’s domain name or server name, and passwords containing three or more consecutively repeated characters. [DG 3-10] Do not rely strictly on the password strength meter to enforce password policies. Always validate passwords on the server using the rules above. X X X [DG 3-11] Do not implement logic in client-side password strength meter code that results in disclosure of the full list of explicitly prohibited passwords. X X X [DG 3-12] Present the following language to users attempting to set a password: Please avoid the following types of passwords: • Passwords including your username. • Passwords based on information about you like your name, date of birth, phone number, or other information you provide to us during registration. X X X • Passwords based on dictionary words. • Passwords with repeating characters such as “11111111”, keyboard sequences such as “asdfghjkl”, or other obvious sequences such as “1234567890” and “ABCDEFGH”. Passwords that are part of our website name “
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 6 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 4-5] Implement declarative security (e.g., through deployment descriptors like web.xml) to enforce access control decisions where possible. When programmatic security is required, implement programmatic security through a centralized access control component where possible. Ensure all access X X X control decisions are enforced server-side. Ensure access control defaults to “deny all” when the access control system is unavailable or encounters an error. [DG 4-6] Utilize enterprise authentication methods. X X X [DG 4-7] If passwords are stored in a user table within a database or a file, store them using a SHA-2 (or stronger) hash of the password and a cryptographically strong (i.e., long, random, and not easily reproducible) per-row secret salt value. Never store passwords in plaintext or encoded formats. Compare a submitted password by evaluating the equality after applying the identical hashing function to the submitted password against the previously stored password hash. Never store a password file within the web document root. Where possible, implement password hashing with a hashing algorithm designed for passwords such as X X bcrypt or scrypt. Store the secret salt value on a server independent of the user table. Contact Best Buy Enterprise Information Protection to cooperatively define and implement all password storage schemes, including those involving simple use cases and those involving multi-round hashing and per-row salting techniques. [DG 4-8] Do not permit test accounts on production systems. X X X [DG 4-9] Permit authenticated web-based administrative application functionality only from designated secure IP address ranges over strongly encrypted TLS 1.2+ connections. Ensure administrative functionality is logically separated from the main application by implementing it within a separate application, on a separate port, on a separate domain, or on a different server altogether. X X X Permit authenticated console administrative application functionality only from designated secure IP address ranges over strongly encrypted connections utilizing up-to-date software and protocols free of security vulnerabilities. [DG 4-10] Do not disclose specifically whether a username, password, or other identifier (e.g., the last four digits of a social security number) was invalid in response to failed authentication attempts, as doing so may aid an attacker in valid account determination. Additionally, do not disclose failed login count or the X X X account locked/unlocked status. Instead, return a generic error message only indicating that authentication failed such as “invalid authentication credentials or account locked.” [DG 4-11] Do not disclose the existence of an already registered username during registration, and do not permit automatically authenticated access with the new username. Instead: • Return a generic message such as “account activation information will be sent to the
Alternatively: Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 7 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI • If disclosure of the existence of an already registered username during registration is necessary, use a Best Buy Enterprise Information Protection approved CAPTCHA implementation, requiring the correct solution to a new CAPTCHA challenge for each username reservation attempt prior to indication of account existence. • If a username is already taken, do not permit a new registration with the already taken username. Consider a nondescript error message when a username is already taken. • If a username is available and out-of-band account activation is required: o Return a generic message such as “account activation information will be sent to the
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 8 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 4-14] Securely log all login bind attempts to a secure location that is not within the web server root directory or on the system drive of the application server. The safely encoded log data should be utilized to detect malicious login bind attempt sequences, and administrators should be alerted to malicious activity. Examples of malicious login bind activity include: • Short-term and sustained password brute forcing attempts against an individual account, including “trickle” attacks such as an average of 70 failed passwords per week over the life of a user’s password • Short-term and sustained password brute forcing attempts against multiple accounts, including attempts to evade filters by using the same/similar password or small groups of passwords against a nontrivial number of accounts Ensure the logs contain the following elements for each login bind attempt: • The server date and time • The source IP address • The target username X X • The number of failed attempts associated with the username after the attempted login (or “N/A” if the username does not exist) • The account locked/unlocked status associated with the username after attempted login (or “N/A” if the username does not exist) • Whether the login attempt succeeded or failed • If the password was incorrect, a SHA-2 (or stronger) hash of the attempted password and cryptographically strong (i.e., long, random, and not easily reproducible) secret per-row salt value (or “N/A” if the password was correct); the cryptographically strong secret salt value must not be used in any other part of the application (e.g., password verification function or previous password verification function), and must be stored on a server independent of the logs • If the login succeeded, a SHA-2 (or stronger) hash of the resultant authenticated session identifier and cryptographically strong (i.e., long, random, and not easily reproducible) per-row secret salt value (or “N/A” if the login failed); the cryptographically strong secret salt value must not be used in any other part of the application, and must be stored on a server independent of the logs
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 9 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 4-15] Securely log all access attempts to a secure location that is not within the web server root directory or on the system drive of the application server. The safely encoded log data should be utilized to detect malicious activity, and administrators should be alerted to malicious activity. Ensure the logs contain the following elements for each access attempt: • The server date and time • The source IP address • The target username • A nonsensitive representation of the canonicalized target user’s security authorization claim(s) or role(s) • The full path to the component attempted to be accessed • Whether the access attempt succeeded or failed • A plaintext status code representing the class(es) of input data submitted. For example, TS_PII_PCI_SOX indicates that the component expects, potentially, TOP SECRET Personally X X Identifiable Information, Payment Card Industry, and Sarbanes-Oxley data. • A plaintext status code representing the class(es) of data being attempted to be accessed through the component. For example, CONF_PII_GLBA indicates the component returns, potentially, CONFIDENTIAL Personally Identifiable Information and Gramm-Leach-Bliley data. • A serialized structure representing the nonsensitive method arguments • A serialized structure containing SHA-2 (or stronger) hashes representing each of the critical sensitive method arguments; the sensitive arguments must be salted with a cryptographically strong (i.e., long, random, and not easily reproducible) secret salt value not used in any other tier or part of the application, and must be stored on a server independent of the logs • A SHA-2 (or stronger) hash of the session identifier/security token and cryptographically strong (i.e., long, random, and not easily reproducible) secret salt value; the cryptographically strong secret salt value must not be used in any other tier or part of the application, and must be stored on a server independent of the logs [DG 4-16] For employee and elevated access such as administrator or service accounts, do not permit access to the application if the user’s password age exceeds the threshold appropriate to the type of account. Passwords normally entered interactively, employee or administrator, must be changed at least X X X every ninety (90) days. Elevated access account passwords not normally entered interactively must be managed so that passwords are only valid for a single use. [DG 4-17] If using a challenge question/token, do not permit application usage strictly on the basis of X X X presentation of a correct username and answer to a challenge question/token. [DG 4-18] For customers, do not ask challenge questions requiring sensitive answers, to include the following: • Government issued identifiers (e.g., Social Security Numbers, Social Insurance Numbers, driver license number, and passport number). X X X • Mother’s maiden name. • Financial instrument or cardholder information (e.g., primary account number).
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 10 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 4-19] Provide a secure means for users to reset forgotten passwords. Do not immediately reset account passwords or lock accounts in response to forgotten password requests. Additionally, do not immediately clear payment card information stored for non-recurring payment (i.e., payment for web purchases) in response to forgotten password requests. Instead: • Return a generic message such as “account information will be sent if the account is valid”. • Send an activation code out-of-band (e.g., email or text message), ensuring the activation code is time limited (e.g., must be used within 30 minutes), cryptographically strong (i.e., long, random, and not easily reproducible), and only associated with the specific user for one use. • Continue to honor the old password and, if payment card information is stored for non-recurring payment, continue secure storage of payment card information stored for non-recurring payment X X X until the password change is completed successfully using the activation code. Continue supporting login attempts and enforcing account lockout rules as usual while an activation code is outstanding for an account. Upon successful password change using the activation code, ensure that payment card information stored for non-recurring payments is immediately cleared from the account, that the associated account is then unlocked, that the account’s consecutive failed login counter is reset, and that the activation code is deactivated. • Send an out-of-band message (e.g., email or text message) to end users after account modifications such as a password change. • Consider deactivating an issued forgotten password token upon a successful intervening login for an account with an outstanding forgotten password token. [DG 4-20] Provide a password change option for authenticated users. X X X [DG 4-21] Do not immediately display the existence of the association of a username with an account in response to forgotten username requests. Instead: X X X • Return a generic message such as “account information will be sent if the account is valid”. • Send the username out-of-band (e.g., email or text message). [DG 4-22] Do not immediately display the existence of the association of an email address with an account in response to forgotten associated email address requests. Instead: X X X • Return a generic message such as “account information will be sent if the account is valid”. • Send the email association confirmation out-of-band (e.g., email or text message). [DG 4-23] For password change requests issued within an authenticated session: • Require the existing password in addition to the new password. If the existing password is not correctly entered within five (5) consecutive attempts, logout the user and terminate the session both server- and client-side. • Do not submit the username to the server as a parameter along with the old and new password. Instead, retrieve the username from a server side variable associated with the valid authenticated session identifier. X X X • Send an out-of-band message (e.g., an email or text message) to the user after account modifications such as a password change. • Ensure the password change logic provides protection against Cross-Site Request Forgery (CSRF/XSRF) attacks.
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 11 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 4-24] Prevent automated valid account determination, reward redemption fraud, and spam. Utilize a CAPTCHA component to deter brute forcing of reward redemption codes, brute forcing of account credentials (e.g., registered username, email address, mobile phone number, social networking ID) during registration, brute forcing of account credentials during registration changes (e.g., username change or email address change), denial of service spam via forgotten password request activation code messages, denial of service spam via forgotten username request messages, denial of service spam via forgotten associated email request messages, brute forcing of answers to challenge questions during multi-stage login, brute force discovery of password hints, denial of service spam via messaging forms (e.g., SMTP form mailers), and denial of service spam via online posts (e.g., message board forms). For employee or elevated access administrator accounts, if possible, utilize a CAPTCHA component to deter brute forcing X X X of account credentials during login. Use only Best Buy Enterprise Information Protection approved CAPTCHA implementations. Do not pass a CAPTCHA’s text value or other information that assists in deriving the CAPTCHA in a hidden form field or script to the client. Ensure CAPTCHAs are generated randomly and are unique for one use. Ensure the digital token used for tracking a CAPTCHA code’s use is cryptographically strong (i.e., long, random, and not easily reproducible) and unique for one use. Regularly update CAPTCHA component technology to prevent evolving threats against CAPTCHA algorithms. Monitor CAPTCHA use for abuse, alerting administrators to suspicious activity. [DG 4-25] If user configurable usernames are implemented (as opposed to usernames synonymous with the primary contact target such as email address, mobile phone number, or social networking ID) during registration, ensure subsequent username changes are issued only from within a properly authenticated session. For username changes attempted within an authenticated session: • Require the existing password. If the existing password is not correctly entered within five (5) attempts, logout the user and terminate the session server- and client-side. • Do not submit the current username as a parameter along with the new username. Instead, retrieve the existing username from a server side variable associated with the valid authenticated session identifier. X X X • Use a Best Buy Enterprise Information Protection approved CAPTCHA implementation, requiring the correct solution to a new CAPTCHA challenge for each username reservation attempt prior to indication of account existence. • If a username is already taken, do not permit a change of registration with the taken username. Consider a nondescript error message when a username is already taken. • Disable the old username upon reservation of a new username. • Prevent automated valid account determination elsewhere within the application. [DG 4-26] If using challenge questions during forgotten password requests, enforce consistent rules: • If using challenge questions with user-specified answers, ensure the same challenge question is presented for the existent username until it is successfully answered by the user. • If using challenge questions with user-specified answers, present the exact same valid challenge X X X question in response to all entered non-existent usernames. • Do not authenticate a user to the application on the basis of a correct answer to a challenge question used for a forgotten password request workflow.
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 12 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 4-27] If using multi-stage logins, enforce consistent workflow and timing as follows: • If using challenge questions with user-specified answers, ensure the same challenge question is presented for the existent username until it is successfully answered by the user. Do not authenticate locked or nonexistent users. Do not rotate the presented challenge question upon successful answer for a locked user. • If using challenge questions with user-specified answers, present the exact same valid challenge X X X question in response to all submitted non-existent usernames. • Present a generic error message for failed login at the end of the full attempted login sequence. • Require all steps of the full login sequence before making backend calls for authentication decisions and ensure response times are consistent for both successful and failed attempts. • Require all steps of the full login sequence to be performed in the correct order. [DG 4-28] Avoid implementation of login mechanisms supporting transmission of Best Buy enterprise credentials across the unmanaged Internet. Contact Best Buy Enterprise Information Protection to cooperatively define and implement any such login mechanism with proper safeguards (including, but not limited to, anti-brute forcing mechanisms such as CAPTCHA and limited and X X X disconnected identity provider databases implementing lockout) and only with formal approval from the Best Buy CISO.
[DG 4-29] Defend against malicious changes of registration details. Require the user’s password for attempts to change registration details. If the password is not correctly entered within five (5) consecutive attempts, logout the user and terminate the session both server-side and client-side. In the case of an attempted change of username where the username is synonymous with the primary contact target (e.g., email address, mobile phone number, or social networking ID), do not disclose the existence of an already registered username, and do not permit automatically authenticated access with the new username. Instead: o Return a generic message such as “account activation information will be sent to the
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI . Return a generic message such as “account activation information will be sent to the
Safe: cannot be guessed or researched Stable: does not change over time X X X Memorable: can remember Simple: is precise, easy, consistent Many: has many possible answers
Session Management [DG 5-1] Identify application users by cryptographically strong (i.e., long, random, and not easily reproducible) and unique per session identifiers, not by incremented numbers or user identifiers subject to deconstruction. Generate session identifiers through the enterprise session management or application X X X server platform if possible. Do not allow the client to generate session identifiers that result in creation of a valid server-side session (also known as “session fixation”). Instead, discard unknown session identifiers and generate session identifiers exclusively on the server. [DG 5-2] Do not store or cache credentials in memory allocated for the client agent. If the client agent must prompt the end user for credentials after a short span (e.g., seven minutes in a PCI kiosk application) of inactivity in order to maintain the session, validate the entered credentials server-side, forcing termination of the user’s session server-side upon five (5) consecutive failed re-authentication attempts. In addition to terminating the user’s session server-side upon five (5) consecutive failed re-authentication attempts, ensure the client also terminates the user’s local application session. The following type of dialog box is suggested when a username/password prompt is required due to user inactivity: You need to re-authenticate as the currently logged-in user to keep this session active. X X X If you don’t re-authenticate as the currently logged-in user, you will lose all of the data entered for this session. You have M minutes and S seconds left to re-authenticate. You have J attempts left to re-authenticate. Username:
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 14 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 5-4] To prevent Cross-Site Request Forgery (CSRF/XSRF) attacks, incorporate a per-session unique cryptographically strong (i.e., long, random, and not easily reproducible) value into a hidden field or appended to the URI query string for all pages after successful authentication. The per-session unique value should not be stored within a cookie or transmitted over cleartext network connections. The application must verify for each subsequent request after authentication that the per-session unique value is correct. Requests containing invalid or missing per-session unique values should result in the destruction of the associated session and redirection back to the authentication page. Alternatively, require users to successfully pass a secondary round of authentication as part of the final X X X step within sensitive workflows. The secondary round of authentication must be validated prior to processing the sensitive workflow request. Logout the user and terminate the session both server- and client-side if the credentials are not correctly entered within five (5) consecutive attempts. Consider implementing CSRF resistance measures in login forms and other forms that could result in browser botnet attacks if abused. Contact Best Buy Enterprise Information Protection to cooperatively define and implement CSRF resistant functionality. [DG 5-5] Set the Secure and HTTPOnly flags on cookies that store sensitive information such as session X X X identifiers. If possible, ensure the Secure and HTTPOnly flags are observed by the client. [DG 5-6] Utilize the correct DOMAIN and PATH cookie attributes for protected application namespaces where appropriate. Do not intentionally liberalize the DOMAIN scope of cookies. Instead, use the Fully Qualified Domain Name (FQDN) of the server hosting the application if setting the DOMAIN attribute at all. For example, if an application’s protected functionality requiring a session identifier is hosted at app.bestbuy.com, set the DOMAIN attribute for the cookie holding the session identifier to X X X app.bestbuy.com, not bestbuy.com. Ensure the PATH scope is specified for the web path of the protected application page resources (generally, not the web root), ensuring a trailing slash (“/”) character is included in this path (e.g., “/myapp/”). If possible, ensure the DOMAIN and PATH cookie attributes are observed by the client. [DG 5-7] Update session identifiers after a successful user authentication. Do not permit session X X X identifiers corresponding to unauthenticated sessions to be reused to access protected resources. [DG 5-8] Invalidate session identifiers on the server after an end user reaches time limits within an X X X authenticated session context. [DG 5-9] Enforce authorization rules on the server through use of cryptographically sound session management techniques, not through a static or otherwise cryptographically weak parameter controlled by X X X the client subject to tampering. [DG 5-10] Provide a logout option to end users that terminates the application session both server- and X X X client-side. [DG 5-11] Do not permit concurrent sessions for the same user. X X X [DG 5-12] Avoid client-side “Remember Me” functionality. If using “Remember Me” functionality, provide a clearly labeled opt-in mechanism describing the risk associated with “Remember Me” functionality. Upon successful authentication for a user who has expressly chosen to utilize “Remember Me” functionality, ensure the security token transmitted to the client is cryptographically strong (i.e., long, random, and not easily reproducible), associated with the specific user who successfully logged in to be issued the “Remember Me” security token, unique for the lifetime of the “Remember Me” period associated with the token (i.e., a wholly different token must be issued for subsequent use of the “Remember Me” X X X functionality for the same user requesting a separate “Remember Me” token, and every “Remember Me” token must be unique), and is set to expire in the session identifier cache (e.g., cookie store) on the client. Invalidate the “Remember Me” security token both client- and server-side upon the following: • The user logs out from a session tied to the “Remember Me” security token. • The server determines that the “Remember Me” security token has reached its maximum lifetime.
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 15 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI Contact Best Buy Enterprise Information Protection to cooperatively define and implement “Remember Me” functionality with proper safeguards, including proper use of protected storage. [DG 5-13] Do not deploy HTTP Basic authentication as the sole means of restricting web application access. Instead, implement form- based authentication or stronger authentication mechanisms not subject X X X to Cross-Site Request Forgery (CSRF/XSRF) attacks. [DG 5-14] When HTML5 cross-document messaging (also known as web messaging) is in use, require cross-document messages to originate from well-defined whitelisted source origin domain names, and require messages to conform to strict data validation rules based on careful object typing and pattern matching. Prevent against HTML5 cross-document messaging CSRF attacks through implementation of security claims/token verification (e.g., a secure message channel between the receiving window and a X X security claims validation server could be utilized).
Additionally, consider implementation of source origin domain names purpose built and specifically named for protected cross-document messaging. Additionally, as usual, require messages to conform to strict data validation rules based on careful object typing and pattern matching. [DG 5-15] When HTML5 cross-origin resource sharing (CORS) is in use, return safe preflight HTTP Access-Control-
For example, do not return an Access-Control-Allow-Origin preflight response header with an unbounded domain list (i.e., do not allow the unbounded wildcard “*” value), but instead return a specifically whitelisted and bounded domain name list. As another example, return only the necessary HTTP methods/verbs in the Access-Control-Allow-Methods preflight response header. X X
Prevent HTML5 CORS CSRF attacks through implementation of target side server (i.e., the server receiving XMLHttpRequest [XHR] or XDomainRequest [XDR] messages) security claims/token verification. Additionally, consider implementation of source origin domain names purpose built and specifically named for protected CORS. [DG 5-16] When HTML5 Web Storage or IndexedDB are in use, construct storage schemes in a manner resistant to CSRF attacks through implementation of domain names purpose built and specifically named for protected HTML5 API interaction (i.e., not domains with shared hosting). Permit API interaction only X X from pages served from the purpose built domain or through an approved cross-document messaging or CORS security design pattern. [DG 5-17] Do not store sensitive data in HTML5 Web Storage or IndexedDB, including authentication credentials, security tokens, and session identifiers. Treat data in web storage the same as untrusted user input. X X For the Web Storage API, if persistent storage is not needed, use the sessionStorage object instead of localStorage. Data Validation [DG 6-1] Filter, canonicalize, and validate client input data prior to submission to the server. However, do not rely only on clients to protect the server from attacks (e.g., data validation layer attacks). Do not trust user-supplied, proxied, or server-generated input data. Always fully filter, canonicalize, and validate data X X X input server-side (e.g., perform price validation server-side instead of trusting customer supplied input element values) prior to processing.
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 16 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 6-2] Properly filter, canonicalize, and validate all input data to prevent attacks against both server and client attack surfaces. Validate input against a whitelist of known good characters within data bounds or a permitted list of options, rejecting input containing unexpected characters and values.
Ensure that security decisions using data obtained outside of the sandboxed application rely upon data received through trusted means (e.g., authentically encrypted or signed data payloads from trusted sources falling within data bounds).
Defend attack surfaces including, but not limited to: • SQL and NoSQL interpreters • Object-relational mappers (e.g., Hibernate ORM) • JavaScript/ECMAScript and VBScript interpreters • Application server and rich client platform APIs • OS command processors • Directory/path canonicalization mechanisms • Parameter canonicalization mechanisms X X X • LDAP • SMTP (email) • XPATH • SOAP XML • REST • JSON DOM • Browser and browser control HTTP handlers • Browser and browser control HTML handlers • HTML5 rich content (e.g.,
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 17 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 6-4] Protect message recipients from unsolicited and dangerous messages submitted through forms: • Use a Best Buy Enterprise Information Protection approved CAPTCHA implementation, requiring the correct solution to a new CAPTCHA challenge for each distinct messaging form submission. • Limit each messaging form submission transmission of the message to five X X X (5) distinct recipients. • Eliminate or sanitize HTML tags, email addresses, and URIs in submitted messaging form content. [DG 6-5] Do not disable the Microsoft Internet Explorer cross-site scripting filter. The following header is dangerous in most cases and must not be set: X X X X-XSS-Protection: 0 [DG 6-6] Ensure that user generated hyperlinks are validated against link reputation services as safe prior to transmission or storage for later display to other users. As required by Best Buy Legal, provide an X X X interstitial to notify users of the risks inherent with following offsite links. If possible, present the option to users to validate offsite links in realtime against link reputation services. [DG 6-7] When using automatic mass parameter assignment (also known as automatic variable binding) from a request to a model, ensure that sensitive fields (e.g., “accountBalance”, “role”, or “password”) are X X X not bound. [DG 6-8] Handle Unicode input safely. Ensure that input validation and output encoding cannot be bypassed by using certain Unicode characters. Ensure that Unicode is not used to perform visual spoofing attacks (e.g., an attacker creates a username that appears to be an administrator’s username, but uses X X X similar-looking characters from other languages). Beware that some platforms/frameworks automatically perform “best-fit” mapping of characters to their “equivalents” in other character sets. [DG 6-9] Prevent XML injection attacks, including: XML tag or attribute injection XPath injection XML External Entity (XXE) injection using local or remote files XML Entity Expansion denial of service attacks
Properly filter, canonicalize, and validate all input data. Properly encode and escape characters that are potentially malicious but that are also required by the application (e.g., the angle brackets or the double quote character). Encode and escape input both prior to server processing requests (e.g., parsing an XML document or executing an XPath expression) and prior to returning data to the end user. X X X
Configure the XML library to disable potentially dangerous features when parsing user input, unless necessary: Disable resolution of internal and external DTDs Disable external entity support Disable retrieval of schemas specified in the “schemaLocation” and “noNamespaceSchemaLocation” attributes Use a whitelist of intended URL schemas for retrieving any remote resources Disable XIncludes support [DG 6-10] Do not dynamically generate database queries or other data provider calls. If possible, utilize parameterized queries (e.g., prepared statements), securely coded stored procedures, or other safe data access providers. (Beware that some parameterized APIs are still injectable.) X X X
Properly encode and escape characters that are potentially malicious but that are also required by the application (e.g., the single quote character).
Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 18 of 27
Secure Software Development | Information Security Guideline | Version 2.1
Requirement WA WS GUI [DG 6-11] Consider rendering user generated or lower trust content in an