Hossein Zahed

Web Developer, Entrepreneur, Software Educator

Events order in ASP.NET Master and Content Pages

Both master pages and content pages can contain event handlers for controls. For controls, events are handled locally—a control in a content page raises an event in the content page, and a control in the master page raises an event in the master page. Controls events are not sent from the content page to the master page. Similarly, you cannot handle an event from a master page control in a content page.

In some cases, the same event is raised in both the content and the master page. For example, both pages raise Init and Load events. The general rule for how events are raised is that the initialization events are raised from the innermost control to the outermost one, and all other events are raised from the outermost control to the innermost one. It is helpful to remember that the master page is merged into the content page and treated as a control in the content page.

The following is the sequence in which events occur when a master page is merged with a content page:

  1. Content page PreInit event.
  2. Master page controls Init event.
  3. Content controls Init event.
  4. Master page Init event.
  5. Content page Init event.
  6. Content page Load event.
  7. Master page Load event.
  8. Master page controls Load event.
  9. Content page controls Load event.
  10. Content page PreRender event.
  11. Master page PreRender event.
  12. Master page controls PreRender event.
  13. Content page controls PreRender event.
  14. Master page controls Unload event.
  15. Content page controls Unload event.
  16. Master page Unload event.
  17. Content page Unload event.

The sequence of events in master and content pages rarely is important for you as page developer. However, if you are creating event handlers that depend on the availability of certain controls, you will find it helpful to understand the event sequence in master and content pages.

Application LifeCycle

Options available to maintain the state

 

 

 Application Events

 

Methods in Global.asax

How to remove number in parenthesis near website/project name in Solution Explorer

In file C:\Users\Username\Documents\IISExpress\config\applicationhost.config, under section

<sites>

...

</sites>

You see all the websites / projects you have ever opened / created. You may delete some of these records carefully so that the numbers in parenthesis will be disappear in the solution explorer window.

ASP.NET Security Architecture Cheat Sheet For Very Busy Architects

Application Security Meeting

From my experience application security meetings are usually hard to manage since the participants do not share common language. Security guys come from infrastructure background and developers usually ... just hate security. There is a communication gap that results in antagonism prolonging the problem instead of solving it. There is the need for common language that everyone understands. The cheat sheet below helped me many times to establish the common ground for fruitful discussion. It is based on JD Meier's epic works:

Have fun.

The Cheat Sheet

Architecture and Design Issues for Web Applications

ASP.NET Security Architecture

Building Secure Assemblies

The main threats are:

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

Secure .Net assemblies

Building Secure ASP.NET Pages and Controls

The main threats are:

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

Secure ASP.NET pages

Building Secure Serviced Components

The main threats are:

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

Secure Serviced Components

Building Secure Web Services

The main threats are:

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

Secure Web Services

Building Secure Remoted Components

The main threats are:

  • Unauthorized access
  • Network eavesdropping
  • Parameter manipulation
  • Serialization

Secure Remoted Components

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

Secure Data Access Components

 

Complimentary questionnaire

 

 

Identify threats

Identify vulnerabilities

Common Vulnerabilities

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

 

 

Related Materials