| Authentication |
| · How could an attacker spoof identity? · How could an attacker gain access to the credential store? · How could an attacker mount a dictionary attack? How are your user's credentials stored and what password policies are enforced? · How can an attacker modify, intercept, or bypass your user's credential reset mechanism? | · Are user names and passwords sent in clear text over an unprotected channel? Is any ad hoc cryptography used for sensitive information? · Are credentials stored? If they are stored, how are they stored and protected? · Do you enforce strong passwords? What other password policies are enforced? · How are credentials verified? · How is the authenticated user identified after the initial logon? | · Passing authentication credentials or authentication cookies over unencrypted network links, which can lead to credential capture or session hijacking · Using weak password and account policies, which can lead to unauthorized access · Mixing personalization with authentication |
| Authorization |
| · How could an attacker influence authorization checks to gain access to privileged operations? · How could an attacker elevate privileges? | · What access controls are used at the entry points of the application? · Does your application use roles? If it uses roles, are they sufficiently granular for access control and auditing purposes? · Does your authorization code fail securely and grant access only upon successful confirmation of credentials? · Do you restrict access to system resources? · Do you restrict database access? · How is authorization enforced at the database? | · Using over-privileged roles and accounts · Failing to provide sufficient role granularity · Failing to restrict system resources to particular application identities |
| Input and Data Validation |
| · How could an attacker inject SQL commands? · How could an attacker perform a cross-site scripting attack? · How could an attacker bypass input validation? · How could an attacker send invalid input to influence security logic on the server? · How could an attacker send malformed input to crash the application? | · Is all input data validated? · Do you validate for length, range, format, and type? · Do you rely on client-side validation? · Could an attacker inject commands or malicious data into the application? · Do you trust data you write out to Web pages, or do you need to HTML-encode it to help prevent cross-site scripting attacks? · Do you validate input before using it in SQL statements to help prevent SQL injection? · Is data validated at the recipient entry point as it is passed between separate trust boundaries? · Can you trust data in the database? · Do you accept input file names, URLs, or user names? Have you addressed canonicalization issues? | · Relying exclusively on client-side validation · Using a deny approach instead of allow for filtering input · Writing data you did not validate out to Web pages · Using input you did not validate to generate SQL queries · Using insecure data access coding techniques, which can increase the threat posed by SQL injection · Using input file names, URLs, or user names for security decisions |
| Configuration Management |
| · How could an attacker gain access to administration functionality? · How could an attacker gain access to your application's configuration data? | · How do you protect remote administration interfaces? · Do you protect configuration stores? · Do you encrypt sensitive configuration data? · Do you separate administrator privileges? · Do you use least privileged process and service accounts? | · Storing configuration secrets, such as connection strings and service account credentials, in clear text · Failing to protect the configuration management aspects of your application, including administration interfaces · Using over-privileged process accounts and service accounts |
| Sensitive Data |
| · Where and how does your application store sensitive data? · When and where is sensitive data passed across a network? · How could an attacker view sensitive data? · How could an attacker manipulate sensitive data? | · Do you store secrets in persistent stores? · How do you store sensitive data? · Do you store secrets in memory? · Do you pass sensitive data over the network? · Do you log sensitive data? | · Storing secrets when you do not need to store them · Storing secrets in code · Storing secrets in clear text · Passing sensitive data in clear text over networks |
| Session Management |
| · Do you use a custom encryption algorithm, and do you trust the algorithm? · How could an attacker hijack a session? · How could an attacker view or manipulate another user's session state? | · How are session cookies generated? · How are session identifiers exchanged? · How is session state protected as it crosses the network? · How is session state protected to prevent session hijacking? · How is the session state store protected? · Do you restrict session lifetime? · How does the application authenticate with the session store? · Are credentials passed over the network and are they maintained by the application? If they are, how are they protected? | · Passing session identifiers over unencrypted channels · Prolonged session lifetime · Insecure session state stores · Session identifiers in query strings |
| Cryptography |
| · What would it take for an attacker to crack your encryption? · How could an attacker obtain access to encryption keys? · Which cryptographic standards are you using? What, if any, are the known attacks on these standards? · Are you creating your own cryptography? · How does your deployment topology potentially impact your choice of encryption methods? | · What algorithms and cryptographic techniques are used? · Do you use custom encryption algorithms? · Why do you use particular algorithms? · How long are encryption keys, and how are they protected? · How often are keys recycled? · How are encryption keys distributed? | · Using custom cryptography · Using the wrong algorithm or a key size that is too small · Failing to protect encryption keys · Using the same key for a prolonged period of time |
| Parameter Manipulation |
| · How could an attacker manipulate parameters to influence security logic on the server? · How could an attacker manipulate sensitive parameter data? | · Do you validate all input parameters? · Do you validate all parameters in form fields, view state, cookie data, and HTTP headers? · Do you pass sensitive data in parameters? · Does the application detect tampered parameters? | · Failing to validate all input parameters. This makes your application susceptible to denial of service attacks and code injection attacks, including SQL injection and XSS. · Including sensitive data in unencrypted cookies. Cookie data can be changed at the client or it can be captured and changed as it is passed over the network. · Including sensitive data in query strings and form fields. Query strings and form fields are easily changed on the client. · Trusting HTTP header information. This information is easily changed on the client. |
| Exception Management |
| · How could an attacker crash the application? · How could an attacker gain useful exception details? | · How does the application handle error conditions? · Are exceptions ever allowed to propagate back to the client? · What type of data is included in exception messages? · Do you reveal too much information to the client? · Where do you log exception details? Are the log files secure? | · Failing to validate all input parameters · Revealing too much information to the client |
| Auditing and Logging |
| · How could an attacker cover his or her tracks? · How can you prove that an attacker (or legitimate user) performed specific actions? | · Have you identified key activities to audit? · Does your application audit activity across all layers and servers? · How are log files protected? | · Failing to audit failed logons · Failing to protect audit files · Failing to audit across application layers and servers |
