Architecture and Design Issues for Web Application


Microsoft .NET Framework v4.5 logo.png

Architecture and Design Issues for Web Applications

Building Secure Assemblies

The main threats are:

  • Unauthorized access or privilege elevation, or both
  • Code injection
  • Information disclosure
  • Tampering

Building Secure ASP.NET Pages and Controls

The main threats are:

  • Code injection
  • Session hijacking
  • Identity spoofing
  • Parameter manipulation
  • Network eavesdropping
  • Information disclosure

Building Secure Serviced Components

The main threats are:

  • Network eavesdropping
  • Unauthorized access
  • Unconstrained delegation
  • Disclosure of configuration data
  • Repudiation

Building Secure Web Services

The main threats are:

  • Unauthorized access
  • Parameter manipulation
  • Network eavesdropping
  • Disclosure of configuration data
  • Message replay

Building Secure Remoted Components

The main threats are:

  • Unauthorized access
  • Network eavesdropping
  • Parameter manipulation
  • Serialization

Building Secure Data Access

The main threats are:

  • SQL injection
  • Disclosure of configuration data
  • Disclosure of sensitive application data
  • Disclosure of database schema and connection details
  • Unauthorized access
  • Network eavesdropping

Complimentary questionnaire 

Identify threats

Identify vulnerabilities

Common Vulnerabilities


·          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



·          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



·          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


  Today, there have been 1 visitors (5 hits) on this page!  
Free Domain This site was last updated Monday, 23 January 2017
Copyright © 2006-2017 smfaizhaider. All rights reserved.