Alik Levin's

Clarity, Technology, and Solving Problems | 

March, 2009

  • Alik Levin's

    ASP.NET Security Architecture Cheat Sheet For Very Busy Architects

     Alik Levin    You are an architect. You are sitting in your fancy office thinking about cloud computing and about the higher ground stuff. Suddenly the phone rings, it's your current project manager. "Quick! Come over here, we have a meeting with security department, they have tons of questions and I do not have a clue what they want from me! Our project must ship on time,

    Related Books

    we cannot afford postponing it anymore. It's your show time, dude, Save me!" - ...."Ehm... OK... I am coming...". You hang up the phone, scratch your head and... take the below cheat sheet with you on your way to the meeting.

    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


    ·          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


    Related Materials

    This post is made with plugin for Windows Live Writer

  • Alik Levin's

    WinDBG Walkthrough - Dump Values Of DataSet or DataTable

     Alik Levin    This walkthrough is completely based on Johan's post WinDBG+SOS: Getting at the values in a DataTable. I have created this one to help me do the job in straightforward way next time I hit similar problem. Joan also offers few scripts for process automation - recommended.

    by glennharper

    Customer Case Study

    The customer complained about potential memory leak. Following the procedure described in Identifying Memory Leak With Process Explorer And Windbg we realized that we are dealing with static variable that grows in unlimited way. This assumption is based on the fact that after running !gcroot on the leaking type we get the following:


    After reviewing Tess' .NET Debugging Demos Lab 7: Memory Leak - Review we found the following which made us believe we are dealing with static variable:

    DOMAIN(001CCE68):HANDLE(Strong) - Strong reference, Typically a static variable

    To identify what this static variable is we needed to dump its values. The variable was a DataTable. I have not found a straightforward way of dumping contents of DataTable. This is the walkthrough that does the job.

    Summary of steps

    • Step 1. Dump DataTables
    • Step 2. Dump DataTable
    • Step 3. Dump columnCollection
    • Step 4. Dump list object
    • Step 5. Dump raw memory - dd command
    • Step 6. Dump DataColumn
    • Step 7. Dump storage
    • Step 8. Dump values
    • Step 9. Bonus - automation

    Step 1. Dump DataTables

    The objective of this step is identify all DataTable object and pick the one of the interest

    0:000> !dumpdatatables
    DataTable       Rows    Columns    DataSet nextRowID ColumnCount
    0x024dc948 0x024dcbc8 0x024dcdec 0x064f2400         1         2
    0x025156b8 0x02515938 0x02515b5c 0x02515478         1         7

    0x0e5b9ce4 0x0e5b9f64 0x0e5ba138 0x0e55a338       428         5
    0x06510e54 0x065110d4 0x065112a8 0x064f2400     1,359         7
    0x0e5778f0 0x0e577b70 0x0e577d44 0x0e55a338     1,359         7
    0x0a55d270 0x0a55d4f0 0x0a55d6c4 0x06a62620 4,194,305        10
    Total 61 DataTable objects

    Step 2. Dump DataTable

    The objective of this step is identifying the address of columnCollection of the DataTable.

    0:000> !do 0x0a55d270
    Name: System.Data.DataTable
    0x176c1560 0x40003f2     0x18                CLASS   instance 0x0a55d6c4 columnCollection

    Step 3. Dump columnCollection

    The objective of this step is identifying  the address of list object of the columnCollection.

    0:000> !do 0x0a55d6c4
    Name: System.Data.DataColumnCollection
    0x176c5ffc 0x4000377      0x8                CLASS   instance 0x0a55d6f8 list

    Step 4. Dump list object

    The objective of this step is identifying the address of _items object.

    0:000> !do 0x0a55d6f8
    Name: System.Collections.ArrayList
    0x79ba75ec 0x4000362      0x4                CLASS   instance 0x0a55d710 _items

    Step 5. Dump raw memory - dd command

    The objective of this step is identifying addresses of DataColumn objects.

    0:000> dd 0x0a55d710
    0a55d710  01e5209c 00000010 79b92eec 0a55d854
    0a55d720  0a55d8d4 0a55d954 0a55d9d4 0a55da54
    0a55d730  0a55dad4 0a55db54 0a55dbd4 0a55dd74

    Step 6. Dump DataColumn

    The objective of this step is identifying the address of storage object.

    !do 0a55d854
    Name: System.Data.DataColumn
    0x176c69e8 0x400036b     0x48                CLASS   instance 0x0a55df40 storage

    Step 7. Dump storage

    The objective of this step is identifying address of value object.

    0:000> !do 0x0a55df40
    Name: System.Data.Common.Int32Storage
    0x176ecc8c 0x4000729     0x10                CLASS   instance 0x4dbd0030 values

    Step 8. Dump values

    The objective of this step is dumping the actual values, finally...

    0:000> !do 0x4dbd0030
    Name: System.Int32[]
    Content: 8,388,608 items

    Ouch, it is array.... !do -v will dump its values, but I am afraid it is not a good idea doing it for 8 million items here ;)

    Step 9. Bonus - automation

    The objective of this step is automate the process of dumping values (Step 8):

    • Create a text file named dumparray and save it in WinDBG directory. The contents of the file are:
      • .foreach ( o { !do ${$arg1} -v -short }) { !do ${o} }
    • Run the following command in WinDBG to dump the values of the array
      • $$>a< dumparray 0x4dbd0030

    Related Materials

    This post is made with plugin for Windows Live Writer

  • Alik Levin's

    Why My ASP.NET Application's Performance Is Less Than Optimal?

     Alik Levin    From my recent engagements I collected few performance anti-patterns that make ASP.NET web application to perform the way that is less than optimal. Many related to architecture and design.
    Below is the list of the anti-patterns and related materials on how to identify, analyze, and fix it.
    Have fun - if you feel like sharing your own experiences - that would rock my world!

    ASP.NET Performance not optimal

    by striatic

    Why My ASP.NET Application Slow?

    Lcked file in ASP.NET application CPU

    This post is made with plugin for Windows Live Writer

Page 1 of 3 (7 items) 123