Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

March, 2009

  • Alik Levin's

    ASP.NET MVC For Aspiring Architects - #1

    • 2 Comments

     Alik Levin    Is ASP.NET MVC more than just new cool technology? What advantages it brings over ASP.NET Web Forms? When should I use ASP.NET MVC and when ASP.NET Web Forms? How do I MVC this and MVC that?

    Resources

    This the first post in series of posts that should help me as an architect to answer these questions. It is based on and digested from ASP.NET MVC Overview.

    ASP.NET MVC Overview

    The Model-View-Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller.

    • Models. Model objects are the parts of the application that implement the logic for the application's data domain.
    • Views. Views are the components that display the application's user interface (UI).
    • Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI.

    Advantages of an MVC-Based Web Application

    • It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
    • It does not use view state or server-based forms.
    • It uses a Front Controller pattern that processes Web application requests through a single controller.
    • It provides better support for test-driven development (TDD).
    • It works well for Web applications that are supported by large teams of developers and Web designers who need a high degree of control over the application behavior.

    Advantages of a Web Forms-Based Web Application

    • It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development.
    • It uses a Page Controller pattern that adds functionality to individual pages.
    • It uses view state or server-based forms.
    • It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.
    • In general, it is less complex for application development, because the components (the Page class, controls, and so on) are tightly integrated and usually require less code than the MVC model.

    Related Materials

    This post is made with PracticeThis.com plugin for Windows Live Writer

  • Alik Levin's

    ASP.NET Security Architecture Cheat Sheet For Very Busy Architects

    • 2 Comments
     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

    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

    This post is made with PracticeThis.com plugin for Windows Live Writer

  • Alik Levin's

    Things You Know Now

    • 1 Comments
     Alik Levin    Jimmy May, aspiring geek and part time editor in chief for www.PracticeThis.com tagged me for Things You Know Now. The idea behind all this is sharing the lessons learned at  hard knock school of life. Or in other words it is about what would I do differently if I had a chance to rewind. Here is my take.

    Things You Know Now

    by www.wordle.net

    Things I Know Now

     

    I tag MCS IL team and ACE team blogs. These teams are my most significant source of insights and continuous learning.

     

    What are the Things You Know Now?

    This post is made with PracticeThis.com plugin for Windows Live Writer

Page 1 of 3 (7 items) 123