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