Alik Levin's : Security

ASP.NET Security Architecture Cheat Sheet For Very Busy Architects

alikl — Thu, 19 Mar 2009 12:20:30 GMT

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,

by erik ERXON

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

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

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

Consulting And Security Reviews - How To Get Everyone Onboard

alikl — Mon, 24 Nov 2008 21:56:40 GMT

Security reviews are a respected methodology. People know about them, and probably use them semi-regularly. Ask anyone if security reviews are important, and they would all say yes. Ask them if they do it regularly, and most would say no.

Related Materials

This post discusses the obstacles to implementing security reviews and the secrets to holding effective and successful regular security reviews.

Who’s Involved and What Motivates Them?

Suppose a large enterprise, Contoso Banking, is building its next generation Internet facing web site. Who’s involved and what motivates them?

Project sponsor. The project sponsor wants to ship the project to the end user’s requirements.
Project manager. The project manager wants to ship the project on budget and on time.
Development manager. The development manager wants to ship working version with less bugs as possible.
Architect. The architect wants to create cutting edge architecture with some new technology TLA’s (three letter acronyms).
Development Lead. The development team lead wants to build designs to proven patterns and practices saving on dev management costs.
Developers. The developers want to build the feature and hit code complete mark.
Systems engineers. The IT system engineers want to support bug free systems that do not require maintenance (or as less as possible).

Who Cares About Security?

Now, who cares about security of the project?

Common sense tells us security is the domain of the security guy’s, say, the Chief Security Officer.

Consider the following (not uncommon) scenario. The Chief Security Officer tells the team that the system needs to support two factor authentication due to regulatory compliance. That would usually result into the following reactions:

Project sponsor will need to tell the customers that web access won’t be as smooth as planned, since they will need to carry smart cards. End users usually get upset with such news. So the project sponsor is unhappy.

Project manager understands that with such requirement she will never ship it neither on budget nor on time.

Development manager freaks out imagining how many more bugs this requirement brings in.

Development team lead after quick search on the web finds designs that require special skills, tools, and methodologies. More sleepless nights ahead.

Developer never used crypto in any of her projects and now she needs serious ramp up on this cryptic topic. She is seriously considering moving on to a better project.

A Proven Pattern for Security Participation

Let’s ask who cares about security once more? All of the project participants suddenly care, but most of them are not pleased with the security focus. Working with my customers I found a proven pattern to get everyone onboard with security. The pattern can be boiled down to the following principles:

Speak the language people understand.
Understand motivations of the team.
Optimize security according to the context.
Be consistent.
Be effective.

Speak the language people understand

This might sound funny but what I witness in the field is that people speak different languages, they might all speak their native English, Hebrew, or Russian, but in the end, even when communicating with the same language, no one understands each other. Consider another example, the unexpected security defect.

Tackling the unexpected security defect

Suppose the security tester proudly presents a Cross Site Scripting vulnerability to senior project stakeholders. It goes like this:

- “I found Cross Site Scripting vulnerability in your web site”, - Security Tester happily announces.

- “So?...”, – Project Sponsor asks honestly.

- “So?!?!, Let me repeat what I just said – I found Cross Site Scripting vulnerability in OUR web site”, - Security Tester repeats honestly confused.

- “So?.....”, - Project Sponsor asks even more confused.

And it goes on and on. Until Project Sponsor asks simple question about the subject he really cares

- “How are the end users affected?”.

- “Their identities can be stolen and abused” – Security Tester explains with huge relief.

- “Oh my!!”, - now Project Sponsor understands the severity of the issue, then he continues – “What should be done to mitigate this?”

- “You need rewrite all web pages, with the right encoding, depending on where the data appears in the HTML output” – answers the Security Tester.

The Project Manager comes to life, he understands that he is not going to hit the deadline. He looks at Development Lead asking him silently with his rolling eyes:

- “How long will it take?”

- “Well.. we need to extend the schedule by… 3 months as our developers are not that proficient with such code”, - the Development Lead answers.

Everyone is upset. Security Tester comes to the rescue:

- “Let me suggest the following. You run this simple search and find all occurrences of the issue, and use a common library to make the encoding a simple one line fix in each case”

Project Manager sees the light in the end of the tunnel. In the end he might hit the deadline.

Speak the language that people understand.

"No matter how it looks at first, it's always a people problem." - The Second Law Of Consulting by Gerald M. Weinberg

Optimize security according to the context (what’s-in-it-for-me in action)

Security means different things to different roles. Understand motivations and show what’s in it for me to each one to make everyone buy in.

Project sponsor sees security as the main reason to make end user happy or unhappy. Show how a security bug can reveal the end user’s information. Show how security feature alienates end users. Show how security feature actually brings in more end users.
Project manager sees security feature as the main reason to not hit the deadline or as a reasons for extra expenses. Show how to easily implement security fixes, show how not implementing the fix will bring even more expenses and result in missing the deadline.
Development manager does not see security vulnerabilities as bugs. Show him or her sample penetration testing report that looks very familiar to the bug reports. Such reports usually get the project from staging environment back to the development to fix the vulnerabilities.
Development team lead cares to build proven designs. Point him or her to patterns & practices web site where the proven designs live. Save time and use proven practices. Make the development team leader a hero.
IT System Engineer sees security as more incident calls, more sleepless nights as a result of incident management. Show IT System Engineer how fixing the security bug reduces incident management burden.
Developer hates security. The code is tricky and the fixes are always urgent. Show Developer that security is actually very simple and can be easily implemented like this.

Be consistent

Consistency is the foundation of effectiveness, which will be discussed later on. Frames of core principles help a lot to be consistent. I found Security Frame very useful. It guides me and the rest of the involved parties, Project Sponsor, Project Manager, Development Manager, Development Team Lead, Developer. It creates a common language that everyone understands. Notice how the Security Frame can be used either for Threats that are relevant to Project Sponsor or for Countermeasures that are relevant to Development Force and more Technical audience.

Be effective

If you speak common a language, you get everyone to buy in. It is show time, time to deliver.

How do your effectively create security requirements document?
How do your effectively build secure architecture and designs or inspect those that others created?
How do you effectively guide developers for security?
How do you effectively conduct security code reviews and deployment inspections?

The answer is simple; you follow proven patterns and practices. Fortunately, patterns & practices PAG team, led by J.D. Meier, has built fantastic tool, Guidance Explorer that maintains more than 3,500 easily consumable items on security, performance, and Visual Studio topics. J.D. also maintains his SecurityGuidanceShare.com wiki where he chunks the guidance in more consumable way. Guidance Explorer allows quick searches, direct access to the information according to Security Frame. But two features that bring me effectiveness is its ability to create Word documents and ability to be consumed via any RSS reader.

Practices

Apply proven practices. Avoid approaches that do not work. Do more in less time.

The highest return on investment is achieved when security activities match specific phase of the development lifecycle. These activities must produce results that are relevant to key personas of the phase.

The following table summarizes personas and focused deliverables according to development lifecycle:

Phase	Key Persona	Activity	Deliverable
Envision and requirements gathering	Project Sponsor	Security requirements discussed Helpful resources: - STRIDE Explained - Visualizing – use Hello Secure World - Use Guidance Explorer to effectively build more technical requirements.	Key stake holders buy in for Security. Best result achieved when key project member send out an email to the whole team
Architecture and Design	Architect, Development Leads	Compile Security Design Guidance. Conduct Threat Modeling using Threat Modeling Template Use Guidance Explorer to quickly build guidance and inspection documents.	Threats identified and prioritized.
Coding/Building	Developers	Cannibalize ASP.NET 2.0 Internet Security Reference Implementation to effectively write more secure code – it is endless source of proven Security Code nuggets Bookmark ASP.NET 2.0 FAQs to address security question during the development Conduct effective Security Code Review asking questions from Security Question List: ASP.NET 2.0	Security bug list including priorities and how-to’s for fixtures.
Deployment, Stabilizing	IT System Administrators	Stream line security deployment inspection using this step-by-step guide	Security deployment bug list including priorities and how-to’s for fixtures.

Driving for effective security reviews

Ideally all these activities should be conducted throughout the whole development lifecycle. In the real world projects this happens rarely. Nevertheless, effective security inspection techniques prove that security bar can be constantly raised. One thing to keep in mind that security bugs can be revealed at any development phase but the cost of fixture climbs exponentially as the projects approaches production environment. It is all about risk management.

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

Security Code Review – String Search Patterns For Authorization Vulnerabilities

alikl — Thu, 24 Jul 2008 22:53:10 GMT

These are the questions and the search criteria I use to identify authorization vulnerabilities in the code beyond web.config <authorization> node.

How does the code protect access to page classes?

Attributes

Search for PrincipalPermission attributes. If there is no match, the code does not perform standard authorization checks.

findstr /S /I "PrincipalPermission" *.cs

Empirical checks

Search for empirical IsInRole calls. If there is no match, the code does not perform standard authorization checks.

findstr /S /I "IsInRole" *.cs

Rolemanager

Search for empirical IsUserInRole calls for Rolemanager API. If there is no match, the code does not perform standard authorization checks.

findstr /S /I "IsUserInRole" *.cs

Does the code use Server.Transfer?

When the code uses Server.Transfer it may improve performance but potentially it may pose a threat of elevation of privileges, more info is here Performance Gain - Security Risk

findstr /S /I "Transfer" *.cs

Security Code Review – String Search Patterns For Authentication Vulnerabilities

alikl — Mon, 21 Jul 2008 15:39:59 GMT

This post contains string search patterns that can help identifying authentication vulnerabilities during security code inspection for your ASP.NET application. Most common vulnerability is about insecurely manipulating credentials in the code. The question we want to actually ask is:

Are you passing clear text credentials?

The associated threat is identity theft or identity spoof that can be achieved by disclosing the credentials or/and tampering it.

What to Search for and Why

Credentials are usually required when accessing a down stream resource – database, web service, active directory, MQSeries, or any other. This information can be easily obtained from the architecture document. Following are possible searches that can lead you to the hotspots to nail potential authentication vulnerabilities:

DB Connections

findstr /S /I ".Open( " *.cs

Web Services

findstr /S /I ".Credentials =" *.cs

LogonUser API – usually used for impersonation

findstr /S /I "LogonUser" *.cs

IIdentity usage

This one is my favorite. This search pattern is actually trying to spot the anti-pattern of identifying end user. The assumption here is that when there is no matches for that search then the solution either does not identifies the requests or uses home grown solution which might be potential vulnerability in both cases.

findstr /S /I “.Identity" *.cs

Other than above searches it is good idea to review the web.config file for potential clear text credentials.

Got more suggestions for search patters to identify potential authentication vulnerabilities? - Please, share!

Security Code Review – String Search Patterns For Finding Input Validation Vulnerabilities

alikl — Fri, 11 Jul 2008 14:24:53 GMT

Well defined set of search patterns helps significantly reduce time (cost) when performing security code inspections. This post focuses on input validation vulnerabilities commonly found in ASP.NET web applications.

SQL Injection and Cross Site Scripting (XSS) String search patterns

SQL Injections and XSS attacks are most common that exploit improper data access and lack of output encoding. Following are the how-to’s on finding these vulnerabilities:

Input Validation vulnerabilities String Search Patterns

To search and find security vulnerabilities you start asking questions or better yet create a list of the questions. Here is the example how - Generate Your Own Security Code Review Checklist Document Using Outlook 2007.

Use search utility similar to FindStr to perform your searches (look at Performing Text Searches). When Visual Studio is available then you can use it - Visual Studio 2005 As General Code Search Tool. Any other search tool is just fine. Following are the most common questions and search patterns.

Does the code rely on client-side validation?

If the code does not use Validators or Regex there is a potential vulnerability. Review each control how it is validated for type, length, range, string format. In the searches I assume there is no inline code and developers use code behind technique to separate markup from code.

ASP.NET pages

findstr /S /I ".Validator" *.aspx

User Controls

findstr /S /I ".Validator" *.ascx

Source code

findstr /S /I "Regex" *.cs

Is the code susceptible to canonicalization attacks?

Review that there is no external input involved in building paths and file names.

findstr /S /I “File" *.cs

findstr /S /I “Path" *.cs

Does the code validate data from all sources?

Using Cookies and QueryStrings poses a risk of the tampering threat (review STRIDE Explained to understand threats). If there is a use of Params property there is a chance for CSRF attack - Cross-Site Request Forgery Attack explained

Cookies

findstr /S /I “Cookies" *.*

Query Strings

findstr /S /I “QueryString" *.*

Params

findstr /S /I “Params" *.*

Does the code use MapPath?

If there is a usage of MapPath review that it does not use external input parameters and it is restricted to access only application file space. Make sure its third parameter set to false.

findstr /S /I “MapPath" *.*

How To Mitigate Input And Data Validation Vulnerabilities

Below are detailed step-by-step guidelines for writing code that is not vulnerable to SQL Injections and XSS attacks:

How To: Prevent Cross-Site Scripting in ASP.NET

How To: Protect From Injection Attacks in ASP.NET

How To: Protect From SQL Injection in ASP.NET

How To: Use Regular Expressions to Constrain Input in ASP.NET

Microsoft Anti-Cross Site Scripting Library V1.5

Share Your Practices

If you’ve got more search patterns to suggest – please do so! Let’s make the World [Wide Web] a more secure place together.

My Related Posts

patterns & practices Improving Web Services Security: Scenarios and Implementation Guidance for WCF - BETA Is Out

alikl — Thu, 05 Jun 2008 06:57:27 GMT

patterns & practices team has just released a beta version of WCF Security Guide on Codeplex. Download the guide at http://www.codeplex.com/WCFSecurityGuide.

Original announcement by J.D. Meier, the man behind the effort, is here - New Release: patterns & practices WCF Security Guide (BETA)

WCF Security - Input/Data Validation Using Schemas

alikl — Sun, 25 May 2008 17:52:48 GMT

WCF offers very flexible approach of Input and Data Validation based on XML Schemas. The approach is flexible since the validation rules are expressed in form of XML schema and can be changed at any time without recompiling the solution.

I followed the steps detailed in How To: Perform Message Validation with Schema Validation in WCF and ended up with another working sample (imagine that!).

It took me a bit to struggle with the schema thing and then enabling debugging info on the service side (remember, WCF is secure by default) to understand what's going on and why it fails time after time.

In the end me and WCF made friends and I'd thought it'd be good to share with you the Visual Studio project. Download it here from my SkyDrive and save yourself some time.

My related posts

WCF Security - Input/Data Validation Sample Visual Studio Project

Enjoy.

WCF Security - Input/Data Validation Sample Visual Studio Project

alikl — Sun, 25 May 2008 14:17:44 GMT

Input and Data Validation is one of the core security principles. WCF is no exception. To get most out of WCF in secure way one must implement proper Input and Data Validation.

I was following instructions on How To – Perform Input Validation in WCF compiled by patterns&practice team lead by JD Meier.

In a nutshell the process consists of creating 3 classes and tweaking a config file a "bit".

From the guide:

Step 4 – Create a Class That Implements the Validation Logic
Step 5 – Create a Class That Implements a Custom Endpoint Behavior
Step 6 – Create a Class That Implements a Custom Configuration Element
Step 7 – Add the Custom Behavior to the Configuration File
Step 8 – Create an Endpoint Behavior and Map It to Use the Custom Behavior
Step 9 – Configure the Service Endpoint to Use the Endpoint Behavior

I ended up with working sample built with Visual Studio 2008. I though it'd be good idea to share it to help you boost your productivity.

Grab the Visual Studio project on my SkyDrive here.

Enjoy

patterns & practices WCF Security Guidance Project - live on Codeplex

alikl — Wed, 02 Apr 2008 10:53:10 GMT

patterns & practices has recently released WCF Security Guidance Project. JD, the program manager behind the effort, has been blogging about it too.It is evolving project but the initial content is fantastic already. It has Application Scenarios, Video Index, but my favorites are How-To's:

Pure love.

Quickly Find And Fix Cross Site Scripting (XSS) Vulnerabilities In Your ASP.NET Application.

alikl — Mon, 17 Mar 2008 15:56:00 GMT

Want to quickly check your ASP.NET Web application for Cross Site Scripting (XSS) vulnerability?

It is pretty easy with the knowledge and tools you already have. This post describes how to quickly find and fix most of XSS vulnerabilities in your code.

Why XSS vulnerabilities are possible

XSS vulnerabilities are possible when un-sanitized data printed out on the page. From what I witness when I do security code inspections most cases can be summarized to two most common:

Using DataBinder.Eval function:

<%#DataBinder.Eval(Container.DataItem, "TEXT") %>

Assigning to Text property of the control:

Label1.Text = TextBox1.Text;

[Update 20.7.08] Assigning to Text property of the control:

<%=myStringGoesHere...

How to quickly find XSS vulnerabilities

Above patterns are easily identifiable using any strings search utility. I use Visual Studio 2005 As General Code Search Tool to find such vulnerabilities. When Visual Studio is not an option, just use FindStr, here is an example - Code Inspection - First Look For What To Look For.

Run your search for ".Eval(" and then for ".Text =". You might want to modify slightly it as some folks omit space before "=" or other minor changes.

Use searches similar to these:

findstr /S /I ".Text =" *.cs
findstr /S /I ".Eval(" *.aspx
findstr /S /I ".Eval(" *.ascx
[Update 20.7.08] findstr /S /I "<%=" *.aspx

Ran your search yet? What do you see? Scared?

How to quickly fix XSS vulnerabilities

The fix is pretty simple - just apply Html Encoding to both cases. The best is using freely available Microsoft Anti-Cross Site Scripting Library V1.5. Note that ASP.NET’s Server.HtmlEncode is not the safest one as it only encodes <,>,",& characters which is not sufficient to protect against all possible attacks.

My related posts

Securing IIS7 - Windows Server 2008 Security Guide

alikl — Thu, 28 Feb 2008 22:09:42 GMT

Windows Server 2008 Security Guide is out.

It covers many crucial aspects but my favorite of course is IIS7 chapter:

Chapter 6: Hardening Web Services

This chapter provides prescriptive guidance for hardening the Web Server role. The chapter discusses how the Web server role installs Microsoft® Internet Information Services (IIS) 7.0, which has been redesigned into forty modular components that you can choose to install as needed.

It points to the following resources:

Security Code Review – Use Visual Studio Bookmarks To Capture Security Findings

alikl — Thu, 24 Jan 2008 16:38:46 GMT

How to streamline the process of capturing security flaws during security code review? How to save time and avoid switching between the tools? How to stay focused?

In this post I will show my simple technique to capture security flaws using Bookmarks in Visual Studio.

Create bookmark folders. Hit Ctrl + K and then Ctrl + W to bring Bookmarks window up. Create 10 folders according to security frame categories:

Focus on one category. Grab security checklist document you created using Guidance Explorer. Choose one category from the security frame, Authentication for example, and inspect the code manually. Do not pay attention to anything else on your way but Authentication issues. One category a time.

Bookmark security bugs. Once you find security bug hit Ctrl + K and then Ctrl +K again. You just created the bookmark. Drag it into the appropriate folder in Bookmarks window. Move on. When you finish the inspection using your checklist you should have something like this:

Copy to the report in one run. Just run through the bookmarks and paste the findings to your final report. One run. Mechanical work. Done. Peace of mind.

My related posts

Chain Of Responsibility Design Pattern – Focus On Security, Performance, And Operations

alikl — Mon, 14 Jan 2008 18:50:19 GMT

The pattern is also called Intercepting Filter, Pipeline, AOP, and may be few more… I am confused by the name for this design pattern.

“Life is really simple, but we insist on making it complicated.” - Confucius

No matter how they call it I like the idea of decoupling actions while processing one after another. Here is the definition from data & object factory:

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Intercepting Filter visual from MSDN’s Discover the Design Patterns You're Already Using in the .NET Framework

.Net framework implements Chain Of Responsibility design pattern for many its internal mechanisms. My favorite is HttpModule. I like it so much I decided to build my own pipeline.

This post summarizes my steps I took to create my own simple implementation for this design pattern. I did not do any research purposely online and wanted to get my hands dirty without bias.

The goal

My goal was creating simple code that can be adopted and extended:

The code should be very simple
The code should provide pipeline infrastructure to invoke aspects/filters
The code should allow dynamic invocation of any arbitrary number of aspects
The code should include no optimization to stay simple
The code should demonstrate practical idea and not be state of the art, production ready to go one.

What I needed

Provide generic mechanism that will execute arbitrary logic – the Pipeline.
The logic is encapsulated in decoupled components – Aspects.
Aspects can be independently configured without rebuilding the application.

The design

Summary of steps

Step #1 – Create base classes and interfaces.
Step #2 – Create concrete implementation of specific Pipeline.
Step #3 – Modify config file.
Step #4 – Test the solution.

Following section describes each step in details

Step #1 – Create base classes and interfaces. I needed two bases classes - BasePipeline and IAspect. BasePipeline is responsible to perform generic actions of:

Consulting configuration file.
Loading the configured aspects.
And invoking them one by one.

private void LoadPipelineAspects()
{
    aspects = new List<IAspect>();

    Configuration config =

                  ConfigurationManager.OpenExeConfiguration(

                  ConfigurationUserLevel.None);

    string  piplineConfig =

            config.AppSettings.Settings[pipelineName].Value;

    string[] aspectNames = piplineConfig.Split(',');

    for (int i = 0; i < aspectNames.Length; i++)
    {

        Type t = Type.GetType(aspectNames[i]);

        IAspect aspect=(IAspect)Activator.CreateInstance(t);

        aspects.Add(aspect);

    }
}

IAspect interface serves as a contract between BasePipline and aspect's concrete implementation. Take a look at the design diagram. When the client invokes HandleRequest method on concrete Pipeline implementation it invokes underneath generic implementation of the method of its base - BasePipeline:

public virtual bool HandleRequest(object request) 
{

    foreach (IAspect item in aspects)
    {
        item.ProcessRequest(request);
    }
    return true;
}

Step #2 – Create concrete implementations. Concrete implementations of both types SimplePipeline and SimpleAspect are nothing fancy. SimplePipeline calls into its base but reserves the right to add any additions without interfering with any other concrete implementations:
```
public override bool HandleRequest(object request)
{
    base.HandleRequest(request);

    return true;
} 
```
To indicate what aspect is running I simply spit out aspect's name for aspect's ProcessRequest. That is the place where the whole logic should be performed - DB access, Web Services calls, request modifications etc :
```
public bool ProcessRequest(object request)
{
    Console.WriteLine("processing from SimpleAspect1");
    return true;
}
```

Step #3 – Modify config file. Config file - app.config or web.config in my case - holds the information about what aspects should be called for specific pipeline:
```
<appSettings>
 <add key =
"MyPipeline.SimplePipeline" 
 value ="MyPipeline.SimpleAspect1,MyPipeline.SimpleAspect2"/>
</appSettings>
```
The key is the type of the pipeline and the value is comma separated types of the aspects. When the concrete pipeline is instantiated by the client it already knows it type which serves to consult the config file and identify what aspects to load using reflection. This is how BasePipeline constructor looks like:
```
public BasePipeline()
{
    pipelineName = this.ToString();
    
    LoadPipelineAspects();

}
```
See Step #1 for LoadPipelineAspects() function implementation where reflection magic happens to dynamically load the aspects.

Step #4 – Test the solution. To test the solution follow these steps:
- Create Class library project and reference to the library where Pipeline base classes reside. Implement your own Pipeline while inheriting from BasePipeline.
- Implement few aspects that implement IAspect interface.
- Create simple Windows Console application, add reference to the libraries and add simple code similar to this to Main function:
```
MyPipeline.SimplePipeline sp = 
                        new MyPipeline.SimplePipeline();

sp.HandleRequest(null);
```
- In the config file add modifications as described in Step #3.
- Run the application.

Done.

Any time one needs to change the logic, add/remove aspects - it is just a matter of tweaking config file - that is it.

I've just copied and pasted existing aspects inside the configuration file and run the application again, here is what I get:

I think it is cool.

Focus on Security

From security perspective there are few things to keep in mind. When invoking assemblies with reflection there is immediate risk of luring attacks that result in spoofed assemblies. For more information how to get protected see my related post below - .Net Assembly Spoof Attack.

Focus on Performance

Reflection is considered as slow operation. Everything is relative. In case where reflection is used in performance critical application you should consider performance optimization for reflection. One such optimization is constructor caching as described in More Provider Goodieness

Focus on Operations

From operations perspective it seems ideal case. I witnessed few times the situation where the change was not an option since it required whole rebuild of the application - something that operations team was not happy with and put veto on it.

The trick is constantly asking yourself "What I am optimizing? Security, Performance, or Operations?"

My related posts

Download the sample from my SkyDrive:

Have fun.

Basic HttpModule Sample (Plus Bonus Case Study - How HttpModule Saved Mission Critical Project's Life)

alikl — Thu, 27 Dec 2007 01:09:30 GMT

This post to describe basic steps to write HttpModule and how it rescued mission critical application from not hitting the dead line.

HttpModule is the mechanism that facilitates implementing cross cutting logic for incoming ASP.NET requests. ASP.NET uses it extensively under the covers for its needs too - Session management, Authentication to mention a few. What I love most with HttpModules is that there is no need to alter the application itself - just implement IHttpModule interface and tweak web.config. That is all.

Steps to build HttpModule

Step 1 Create Class Library
Step 2 Implement IHttpModule Interface
Step 3 Configure ASP.NET application to use HttpModule
Step 4 Test the application

Next section describes each step in detail.

"no need to alter the application itself - just implement IHttpModule interface and tweak web.config"

Step 1 Create Class Library. Fire up Visual Studio. Click "New Project" dialog, click "Visual Studio Solutions" choose "Blank Solution" and create empty solution. Name it HttpModuleSample. Right click on the solution in "Solution Explorer" and then click "Add", "New Project...". Choose "Class Library" template and name it MyHttpModuleLib. Delete default Class1.cs. Add reference to System.Web assembly.

Step 2 Implement IHttpModule Interface. Add new class to the project and call it MyHttpModule. Add using System.Web declaration. Implement the IhttpModule interface just add :IHtpModule and let Visual Studio implement it explicitly. Register for any of ASP.NET pipeline events - BeginRequest for example - in Init(...) method. Set break point in the event handler.

Step 3 Configure ASP.NET application to use HttpModule. Right click on the solution in solution explorer and add new "ASP.NET Web Application" found under Web node in "Add New Project" dialog. Name it HttpModuleTestWeb. Open the application Web.Config file and add HttpModules node in case it is not already there: Configure MyHttpModuleLib project output path to HttpModuleTestWeb's bin folder. To do so right click on MyHttpModuleLib and choose properties, go to Build section and then to "Output path" in out put section: Build the solution. Ctrl+Shift+B.

Step 4 Test the application. Set HttpModuleTestWeb as start up project and hit F5. You should hit the break point set inside the HttpModule even before the Web Application's page was accessed:

Here I implement any logic I want to run before the page got hit. HttpModule serves as a filter or gatekeeper for incoming Http requests. Following case study explains how such approach saved mission critical application.

Case study

Critical mission application was to go live in few days. The schedule was tight. All functional and integration tests went well. The last one was load and stress tests. During the the load test turned out that one of the network components was crashing as a result of memory leak. The component was sending http headers. We decided to configure the component to send the data in Query Strings instead Http Headers [making story short...]. We needed to find the way to teach the application to look the data in Query Strings instead Http Headers. HttpModule to the rescue!! We developed simple HttpModule that was hijacking the request, scrapping the Query String and setting the data inside Http Headers, where the application was looking for it. Heaven. Worked like magic.

Caveats

Adding Http Headers in .Net is not straight forward since the collection is read only. Reflection to the rescue! Following code explains how to hack Http Headers collection to make it writable - http://forums.asp.net/p/979853/1250479.aspx#1250479. Then we needed to drop the extra Query String before it got to the application. My search landed directly to ScottGu's RewriteUrl post - http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx. What's left is make reflection run faster by caching type's constructor as described here - http://weblogs.asp.net/bradygaster/archive/2003/11/26/39952.aspx

My Related posts:

Sample VS2008 project can be found on my SkyDrive:

ASP.NET 3.5 Extensions: Basic Steps To Create Dynamic Data Web Application - Focus On Security and Performance

alikl — Tue, 18 Dec 2007 13:08:01 GMT

This post walks through the steps I've taken to create simple Dynamic Data Web Application. I just loved the development model for DTO [Data Transfer Object] and Input Validation options.

Summary of steps

Step 1 - Download and install ASP.NET Extensions.
Step 2 - Create New Dynamic Data Web Application in VS2008
Step 3 - Add "LINQ to SQL Classes" file to the project
Step 4 - Test the project
Step 5 - Create Model Class and add validation rules

Following are detailed explanations for each step.

Step 1 - Download and install ASP.NET Extensions. ASP.NET Extensions can be found here - http://asp.net/downloads/3.5-extensions/. I installed it on my Vista machine that has Visual Studio 2008 installed.

Step 2 - Create New Dynamic Data Web Application in VS2008. Open Visual Studio 2008 and choose "Dynamic Data Web Application" template found under Web node. Make sure that the project references System.Web.Extensions assembly version 3.6. If not then remove it and reference the assembly from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\ASP.NET 3.5 Extensions\System.Web.Extensions.dll".

Step 3 - Add "LINQ to SQL Classes" file to the project. Right click on the project and choose "Add"->"New Item..." and then choose "LINQ to SQL Classes" template from "Data" node. In server Explorer expand "Data Connections" node, expand desired database, and then expand "Tables" node. Highlight desired tables and then drag them onto "LINQ to SQL Classes" component [double click file with .dbml extension].

Step 4 - Test the project. Right click on default.aspx page and choose "View in Browser". The page should look similar to the picture below. Click on the tables names to see the actual values and master-child view.

Step 5 - Create Model Class and add validation rules. Adding validation rules can be accomplished using .Net attributes declaratively or using partial methods. Create new class. Add "using System.Web.DynamicData;" declaration. Delete the default constructor. Add partial class with the name of desired table, say "Item" or/and "Product".

Attribute based input validation. Add attribute to the class, for example to check range for ListPrice field/column and add the following declaration:
Partial method input validation. Add partial method for desired field change [intelliSense really rocks at this part] and then add validation logic:

Validation rules propagated to both client [for usability] and server [for security], this is how violation of input validation looks in it default view:

Heaven.

Focus on Security

I can create data driven web pages using GridView and DataSets. The drawback is that validation is not that straightforward. On other hand I can create custom collections and manually data bind it - the code is much nicer and cleaner and validation rules are easy to add but there is the need of writing extra code. In the case of Dynamic Data there is fantastic combination of design time productivity and also clean code where validation rules are applied directly to the model. Less room for mistake to introduce security vulnerability.

Focus on Performance

Ready to go templates that are generated with the default Dynamic Data projects already implement AJAX and paging. It reduces dramatically amount of data that round trips over the wire. Large HTML output - including ViewState - is one of the biggest performance vulnerabilities I've noticed recently. AJAX and paging is a great way to overcome this issue.

My related posts

Related materials

The post was inspired and based on David Ebbo's fantastic screencast
ASP.NET 3.5 Extensions Quickstarts
Keeping View State on the Server
Performance Threats

Alik Levin's : Security

ASP.NET Security Architecture Cheat Sheet For Very Busy Architects

Application Security Meeting

The Cheat Sheet

Complimentary questionnaire

Related Materials

Consulting And Security Reviews - How To Get Everyone Onboard

Who’s Involved and What Motivates Them?

Who Cares About Security?

A Proven Pattern for Security Participation

Speak the language people understand

Tackling the unexpected security defect

Optimize security according to the context (what’s-in-it-for-me in action)

Be consistent

Be effective

Practices

Driving for effective security reviews

Security Code Review – String Search Patterns For Authorization Vulnerabilities

Related posts

Security Code Review – String Search Patterns For Authentication Vulnerabilities

What to Search for and Why

Related posts

Security Code Review – String Search Patterns For Finding Input Validation Vulnerabilities

SQL Injection and Cross Site Scripting (XSS) String search patterns

Input Validation vulnerabilities String Search Patterns

Does the code rely on client-side validation?

Is the code susceptible to canonicalization attacks?

Does the code validate data from all sources?

Does the code use MapPath?

How To Mitigate Input And Data Validation Vulnerabilities

Share Your Practices

My Related Posts

patterns & practices Improving Web Services Security: Scenarios and Implementation Guidance for WCF - BETA Is Out

WCF Security - Input/Data Validation Using Schemas

My related posts

WCF Security - Input/Data Validation Sample Visual Studio Project

patterns & practices WCF Security Guidance Project - live on Codeplex

Quickly Find And Fix Cross Site Scripting (XSS) Vulnerabilities In Your ASP.NET Application.

Why XSS vulnerabilities are possible

How to quickly find XSS vulnerabilities

How to quickly fix XSS vulnerabilities

My related posts

Securing IIS7 - Windows Server 2008 Security Guide

Chapter 6: Hardening Web Services

Security Code Review – Use Visual Studio Bookmarks To Capture Security Findings

Chain Of Responsibility Design Pattern – Focus On Security, Performance, And Operations

Basic HttpModule Sample (Plus Bonus Case Study - How HttpModule Saved Mission Critical Project's Life)

ASP.NET 3.5 Extensions: Basic Steps To Create Dynamic Data Web Application - Focus On Security and Performance