Dan Sellers's WebLog : Security

Security Myth: Only Large Development Teams can Write Secure Code

dansellers — Wed, 20 Sep 2006 22:49:00 GMT

I would recommend that you share this post on the http://blogs.msdn.com/S4CD with anyone that automatically cite resources as an excuse for not writing secure code. This is an extremely well documented example of how a small team can developer secure code and also makes a good point how the smaller business are putting themselves at greater risk.

Well worth the reading!! http://blogs.msdn.com/s4cd/archive/2006/09/19/763109.aspx

IIS 6.0 and ASP.NET 2.0 Credentials--Part Two

dansellers — Fri, 25 Aug 2006 07:43:00 GMT

The ASP.NET User Principal (HTTPContext.User) clearly depends upon the Authentication Mechanism that you selected in IIS 6.0 "Authenication Tab" and if you use Integrated Windows Authentication then it is dependant on the IIS impersonation token that get handed off in the extension control block via the ASP.NET 2.0 ISAPI API. Part two of IIS 6.0 and ASP.NET 2.0 credentials is now complete at the S4CD blog site.. This now ties in ASP.NET Principal Object and how it relates to the the OS thread and the impersonate token.

IIS 6.0 and ASP.NET 2.0 Credentials

dansellers — Thu, 24 Aug 2006 21:34:00 GMT

The one area that many developers do not have good grasp at is how Authentication tokens from IIS 6.0 is passed to ASP.NET 2.0 and how these tokens can subsequently be used for Authorization in an ASP.NET 2.0 Web Application.

The one question that arises quite often is when I click on “Integrated Windows Authentication” in IIS 6.0 “Authentication tab” how does this information get passed to ASP.NET 2.0 and when it is passed to my Web Application how do I flow the client identity between different Services such as a Web Service or a database like SQL Server or what happens when I want to do impersonation?

I have created part one of a two part blog at my new security blog site: http://blogs.msdn.com/s4cd/archive/2006/08/24/718656.aspx

SQL Server 2005 Security for Developers Webcast for on-demand viewing is available

dansellers — Fri, 24 Mar 2006 09:26:00 GMT

The on-demand Webcast of SQL Server 2005 for Developers, conducted on March 22, 2006, by Rob Walters--Program Manager, SQL Server Security--and I, is now available for on-demand viewing.

Post Notes from this Webcast can be found at my blog.

Look forward to seeing everyone for next week webcast.

Regenerating Keys in SQL Server 2005

dansellers — Wed, 22 Mar 2006 23:54:00 GMT

In my latest Webcast on SQL Server 2005 Security one of the questions that came up was:

“If some fields of your table are encrypted and you are suspicious that the key has been revealed can you re-encrypt all the fields with the regenerated key”?

Currently, there is no easy way to manage a key lifetime due to the complexity of managing the binding of the keys with the data they are protecting.

Thus, the application writer needs to keep track of everything that is encrypted with any given key, and in case it is necessary to regenerate a key, here are a series of steps that will probably help on SQL Server 2005:

Create a temp key
Open the old and the temp key
Decrypt (old key) the data and replace it using the temp key
Close the old key
Create a new key with the same name
Open the new key
Decrypt (temp key) the data and replace it using the new key
Close both keys
Drop the temp key

Unfortunately, this can be potentially error-prone (i.e. potential data loss if any column was omitted or failed to be decrypted on steps 3 or 7).

We are currently looking at developing a tool that will gather the binding information and make this more of transparent solution.

Post Webcast’s Notes: Securing SQL Server 2005 for Developers

dansellers — Wed, 22 Mar 2006 22:59:00 GMT

This morning was a jammed filled session covering off a lot of changes made to Microsoft SQL Server 2005. Over the last few weeks we talk exclusively about Front End security issues such as Input trust and the creation of a Development and Design environment to better emulate your production environment. However, today we switched gears by examining the security enhancements made to SQL Server 2005.

A good place to start the talk on was with the Surface Configuration Tool. By default many features including xp_cmdshell, clr and even remote connections have been turned off in SQL Server 2005. Therefore, if you were to immediately start developing in SQL Server 2005 you might start experiences security errors when invoking some of these features. Thus, the Surface Configuration Tool is an excellent way to examine which features are disabled and also provides the ability to enable the particular features required. The SQL Server Surface Area Configuration tool is located under All Programs, Microsoft SQL Server 2005, Configuration Tools.

Authentication has changed in SQL Server 2005 with the support of Windows Password Policies enforcements when creating SQL Server login accounts. This is an excellent way to enforce strong passwords and an expiration policy on passwords depending upon your security needs. This can be configured on a per-login basis as demonstrated with the script below:

create login foo with password='@#Hkjsdf#$#VDSVSQ@!',

CHECK_EXPIRATION=ON,CHECK_POLICY=ON

select * from sys.sql_logins

declare @name nchar(100)

SET @name ='foo'

SELECT LOGINPROPERTY( @name, 'PasswordLastSetTime' ) AS PasswordLastSetTime,

LOGINPROPERTY( @name, 'IsExpired' ) AS IsExpiried,

LOGINPROPERTY( @name, 'IsLocked' ) AS IsLocked,

LOGINPROPERTY( @name, 'IsMustChange' ) AS IsMustChange,

LOGINPROPERTY( @name, 'LockoutTime' ) AS LockoutTime,

LOGINPROPERTY( @name, 'BadPasswordCount' ) AS BadPasswordCount,

LOGINPROPERTY( @name, 'BadPasswordTime' ) AS BadPasswordTime,

LOGINPROPERTY( @name, 'HistoryLength' ) AS HistoryLength,

LOGINPROPERTY( @name, 'PasswordHash' ) AS PasswordHash

--cleanup

drop login foo

Schemas have been added as an abstract between the database and the owner of the objects. Therfore, by assigning objects to schema it is possible to drop users without rewriting your applications as the name resolution is no longer depend upon the user or principals names. We can continue to use the default schema of dbo similar to what we are used to in SQL Server 2000. However, if your application creates objects in the database and you want those objects to be created under the dbo schema then you must grant your application dbo privileges when connecting to the database. This will increase the attack surface of your application as well increasing the severity if your application is vulnerably to SQL Injection attacks. Schemas are also a nice mechanism to scope your permissions. For example, you can grant select permission on a schema. This will grant select permission to all the tables in that schema alone but not the other tables in other schemas.

Execute Content provides an excellent mechanism to have your modules such as functions, proc and triggers to run under a different user context then the caller of the module. The permissions that one can assign in SQL Server 2005 is very granular especially compared with SQL Server 2000, however, if you are unable to provide a single permission attribute to some database users then you can use execute content. Therefore, the proc can run under a privilege account that has certain permission such as truncate table, and the caller only has to be granted execute permission on the proc itself and not truncate table. Highlighted in the demo script below:

--This example will create 3 users

-- User1 will have a table MyTable

-- User2 will have a stored proc that select's the table

-- User3 will have execute permissions on User 2's stored proc

--This demo show the use of EXECUTE AS functionality

--Create our users

create login Login1 with password='(*&sdf87786sdf'

create login Login2 with password='(*&sdf87786sdf'

create login Login3 with password='(*&sdf87786sdf'

create database ExampleDB

use ExampleDB

--User 1 will have a table

create user User1 for login Login1 with default_schema=User1

create schema User1 authorization User1

--User 2 will have SELECT access and write a proc to access

create user User2 for login Login2 with default_schema=User2

create schema User2 authorization User2

--User 3 will have the right to exec the proc

create user User3 for login Login3 with default_schema=User3

create schema User3 authorization User3

grant create table to User1

grant create proc to User2

execute as login='Login1'

create table User1.MyTable

(ANumber int)

insert into MyTable values (1)

insert into MyTable values (2)

insert into MyTable values (3)

grant select on MyTable to User2

revert

execute as login='Login2'

--create a stored proc that will return the rows in our table

create proc ViewMyNumbers

BEGIN

select * from User1.MyTable

END

grant execute on ViewMyNumbers to User3

revert

execute as login='Login3'

--Can't access table directly

select * from User1.MyTable

--I can't execute the proc since I don't have permissions on the unlying table

exec User2.ViewMyNumbers

--What I can do is alter the proc and set it to "execute as owner"

revert

execute as login='Login2'

ALTER PROCEDURE ViewMyNumbers

WITH EXECUTE AS OWNER

BEGIN

select * from User1.MyTable

END

revert

execute as login='Login3'

--Still can't access table directly

select * from User1.MyTable

--Now I can access it and I didn't have to give User1

--any permissions on MyTable

exec User2.ViewMyNumbers

revert

SQL Server now provides build DDL statements and functions for encrypting and decrypting data inside the database and not necessary in manage code anymore. Encryption has never really been difficult but rather the management of the keys becomes the overwhelming issue. Therefore, SQL Server 2005 supports key management solution including the ability to manage the protection of the keys through a password that must be supplied by an application or an user. Or the protection of all keys in a database can be rooted under the Database Master key which is protected by default of the Service Master Key using the DPAPI for the instance of the SQL Server. I would highly recommend that you visit this excellent blog on certificates and Keys in SQL Server 2005. Demo script is provided below:

--Encrypt content demo

USE Master

--Create Database, Users, Schemas, Table Object--

Create Database AccountsDB

Use AccountsDB

--create two logins that will be used

--logins for two consultants in a investors office

Create login Sheila with password='Capucci4!'

Create login Jon with password='Capucci4!'

--create users with Default schema

Create user Sheila with DEFAULT_SCHEMA=Fin

Create User Jon with DEFAULT_SCHEMA=Fin

Create SCHEMA Fin Authorization Sheila

--Create Table to client table

Create table Fin.Clients (Id int, clientname nvarchar(30),

investor varchar(20),

SIN varbinary(100), Portfolio varbinary(100))

--Assign permission to table

grant select, insert on Fin.Clients to Sheila

grant select, insert on Fin.Clients to Jon

--Now create a certificate for each consultant

Create certificate SheilaCert

authorization Sheila with subject='SheilaCert'

--Notice error, we need to create a database master key first

CREATE MASTER KEY ENCRYPTION BY PASSWORD ='Capucci4!'

--Now lets create the certificates

Create certificate SheilaCert

Authorization Sheila with subject = 'SheilaCert'

Create Certificate JonCert

Authorization Jon with subject = 'JonCert'

--create symmetric keys for each of the consultants

CREATE SYMMETRIC KEY SheilaKey AUTHORIZATION Sheila

WITH ALGORITHM = TRIPLE_DES

ENCRYPTION BY CERTIFICATE SheilaCert;

CREATE SYMMETRIC KEY JonKey AUTHORIZATION JON

WITH ALGORITHM = TRIPLE_DES

ENCRYPTION BY CERTIFICATE JonCert;

--View the list of the keys in the database

Select * from sys.symmetric_keys

--SIMULATE CONNECTING AS SHEILA--

--Login and Insert Client Data--

Execute As login='Sheila'

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

--open your symmetric key for usage

OPEN SYMMETRIC KEY SheilaKey

DECRYPTION BY CERTIFICATE SheilaCert;

--use the key to insert investor's client records

--including encrypted values into the table

insert into Fin.Clients values (1,'Neo','Sheila',

encryptByKey(Key_GUID('SheilaKey'),'111-111-111'),

encryptByKey(Key_GUID('SheilaKey'),'$150,000,000'))

insert into Fin.Clients values (2,'Smith','Sheila',

encryptByKey(Key_GUID('SheilaKey'),'222-222-222'),

encryptByKey(Key_GUID('SheilaKey'),'$200,000'))

--close all open keys

close all symmetric keys

--logging out of sheila's context

REVERT

--SIMULATE CONNECTING AS JON--

execute as login ='Jon'

--open your symmetric key for usage

OPEN SYMMETRIC KEY JonKey

DECRYPTION BY CERTIFICATE JonCert;

insert into Fin.Clients values (3,'WhiteRabbit','Jon',

encryptByKey(Key_GUID('JonKey'),'333-333-333'),

encryptByKey(Key_GUID('JonKey'),'$50,000'))

insert into Fin.Clients values (4,'Trinity','Jon',

encryptByKey(Key_GUID('JonKey'),'444-444-444'),

encryptByKey(Key_GUID('JonKey'),'$300'))

--close all open keys

close all symmetric keys

--simulate logging out of Jon's context

REVERT

--TEST THE RESULTS--

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

Select * from Fin.Clients

Execute As login='Sheila'

--open the relevant keys for usage

OPEN SYMMETRIC KEY SheilaKey

DECRYPTION BY CERTIFICATE SheilaCert;

--Select from the table including decrypting

select id, clientname, investor,

convert(varchar,decryptbykey(SIN)) as SIN,

convert(varchar,decryptbykey(Portfolio)) as Portfolio

from Fin.Clients

--simulate logging out

Close all symmetric keys

REVERT

Execute As login='Jon'

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

--open the relevant keys for usage

OPEN SYMMETRIC KEY JonKey

DECRYPTION BY CERTIFICATE JonCert;

--Select from the table including decrypting

select id, clientname, investor,

convert(varchar,decryptbykey(SIN)) as SIN,

convert(varchar,decryptbykey(Portfolio)) as Portfolio

from Fin.Clients

--simulate logging out

Close all symmetric keys

REVERT

Note: It is also possible to achieve row level security without encryption as depicted in this article. I also recommend you check out this blog entry as well for a tool to assist with row level security.

With impersonate capabilities, you can now flow a single SQL context to the middle tier in the connection object, however, as part of the Command object you can now pass the end user –ASP.NET Principal Object which is derived from the HttpContext.User—to the database and have your middle account impersonate the end user. This provides the ability to flow just a single context in the connection object to ensure connection pooling for performance and by impersonating the end user and having the middle tier account context switch to the end use in the database auditing now be achieved at the database level. As shown in the illustration below:

--*****IMPERSONALIZATION DEMO*******

--*****WHO AM I******

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

--******Create Login Account SQLUser and Dan******

USE Master

Create login SQLUser with password='Capucci4!' --Middle Tier Account

Create login Dan with password='Capucci4!' --User to Impersonate

--*****Create Both Users in Database******

Use AdventureWorks

Create user SQLUser with DEFAULT_SCHEMA=HumanResources

Create user Dan with DEFAULT_SCHEMA=HumanResources

--*****Grant Permission to Middle Tier Account*****

Grant Select on HumanResources.Employee to SQLUser

Grant Select on HumanResources.Employee to Dan

--*****Allow SQLUser to Impersonate Dan******

GRANT IMPERSONATE ON USER:: Dan TO SQLUser

--*****Login as MiddleTier Account*****

--*****Connect to AdventureWorks Database*****

--*****Through the SQLConnection Object*******

Use AdventureWorks

Execute As Login='SQLUser'

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

--****Auditing Under SQLUser****************

Select EmployeeID, LoginID, SickLeaveHours

FROM HumanResources.Employee

Where SickLeaveHours > 75

--****Pass End User account ie.Dan--HttpContext.User—in

--****the command object***********

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

Declare @username varchar(25)

Set @username='Dan'

Execute as User=@username;

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

--****Auditing Under Dan****************

Select EmployeeID, LoginID, SickLeaveHours

FROM HumanResources.Employee

Where SickLeaveHours > 75

--*****Now reverted back to MiddleTier Account for

--*****connection pooling benefits******

REVERT

--****Now we are back as Middle Tier Acount********

SELECT SUSER_NAME() as LoginName, USER_NAME() as DBUserName;

On a final note, SQL Server 2005 releases a Community Technical Preview (CTP) of Service Pack 1 which can be downloaded here.

IOSEC and Anti-Cross Site Scripting Tool

dansellers — Sun, 19 Mar 2006 22:59:00 GMT

Recently, Microsoft released the latest update to Anti-Cross Site Scripting tool which is part of a bigger plan known as the Microsoft IOSEC—an internal library.

The IOSEC library currently implements encoding protection against XSS attacks conducted through vectors such as HTML, URLs, JavaScript, HtmlAttributes and Visual Basic Script. The Anti-Cross Site Scripting Library currently provides protection for a subset of those vectors. Read the latest entry by Kevin Lam--who recently co-presented with me on last week Security’s webcast.

Code Scanning Tools' WebCast for on-demand viewing is available

dansellers — Fri, 17 Mar 2006 04:00:00 GMT

The on-demand version of the Visual Studio 2005 and Code Scanning Tools, conducted on March 15, 2006,by Kevin Lam and I, is now available for on-demand viewing.

Look forward to seeing everyone for next week webcast.

Webcast's Post Notes: Visual Studio 2005 and Code Scanning Tools

dansellers — Thu, 16 Mar 2006 04:35:00 GMT

In today’s webcast we had the opportunity to explore the buffer overrun attack in depth which is considered one of the worst vulnerabilities that exist. Any code that is written in C or C++ --without proper security code reviews--on any platform is susceptible to buffer overrun. It is becoming easier and easier to create shell code to pass as a parameter to our C or C++ code. For example, Kevin Lam --lead author of Assessing Network Security book--showed everyone the http://metasploit.com/shellcode.html web site.

In our Security November’s Webcasts we explored other common attacks such as:

SQL Injection
Cross Site Scripting
Canonical representation

But the underlying theme to prevent all of these types of attacks is validation our input, by checking and constraining all users’s input before passing the value to our resources. We should never pass user input directly into our code path and if we also ensure that our code runs as least privilege (hence the topic of our last two talks) then many of these attacks will become history.

Why was today’s webcast relevant to manage code? Because, a lot of us write manage code that p/invoke into Native code. Therefore, your manage code can be the path to vulnerabilities that may exist in native code.

In the second half of today’s presentation we explored code scanning tools such as:

PREfast
Application Verifier –standalone version download
FxCop

Each tool has their own pros and cons but the one thing that is common between all them of these tools by Microsoft or all other vendors is they are not a silver bullet. Code scanning tools have to limit the number of false positive to a minimal therefore; they will catch a lot of the low hanging fruit but miss a lot of the subtle security vulnerabilities. Code scanning tools on average will pick up about 50% of the security vulnerabilities in your applications and furthermore these tools can not verify a poor design that can lead to other security vulnerabilities. Therefore, your application is not designed with security in mind then code scanning tools will be of no value in these areas. I refer you to Michael Howard blog entry on his thoughts on code scanning tools.

Code Scanning tools need to become part of our security development lifecycle and not a replacement for proper security testing. Even with the best code scanning tools we will still need to do proper security code reviews, threat modeling and penetration testing.

The skill testing question today--is very open ended, but I have a list of few things I am looking for—is what are the cons with just using code scanning tools alone for securing your applications? I have three books “Writing Secure Code Edition 2” for the first three people that email me the correct answer through my blog.

Below is the snippet to the buffer overrun attack written in C:

/* ownMe.c : Buffer Overflow Demonstration
// Compile command from command-line: cl /Zi /GS- ownMe.c
// Command to execute: ownMe
// Works for: XP SP2 Tablet PC Version
// Additional instructions: For all three demos follow instructions then
// compile and run. The lines of code mantioned below are in main().
// Demo1 (No overflow): Uncomment line SayHello(Name); Comment other two lines
// Demo2 (Overflow and process crashes): Uncomment line SayHello(LongName); Comment other two lines
*/

#include "stdio.h"
#include "string.h"

char Name[] = "Mats Sundin";

char LongName[] =
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";

/*
*
*/
void SayHello(char * Name)
{
char NameBuffer[256];
strcpy(NameBuffer,Name);
printf("Hello %s",NameBuffer);
}

void main(void) {

SayHello(Name);
//SayHello(LongName);

}

Ops!!! SecurePasswordTextBox Update now Available

dansellers — Tue, 14 Mar 2006 22:07:00 GMT

After last week WebCast--in which I talked about the new System.Security.SecureString class as well as the cool SecurePasswordTextBox that Paul Glavs wrote--he experienced an sudden increase in downloads. You can read about it here!

Recently, Paul has updated his tool and can now be downloaded.

Great tool and thanks for sharing it with everyone Paul!

ASP.NET 2.0 and the new HTTP-only property

dansellers — Tue, 14 Mar 2006 06:17:00 GMT

To minimize the threat of Cross Site scripting attacks ASP.NET 1.1 introduced the ValidateRequest="true" on the @ Pages element. Recently, Microsoft improved the HttpUtility.HtmlEncode with the new Anti-XSS tool. But another subtle and equally important addition in ASP.NET 2.0 is the HTTP-only option. HTTP-only is a flag that you can append to cookies and helps to reduce harvesting attacks to steal authentication or other valuable cookies. HTTP-only is now a property that can be set on the HttpCookie class.

This property is already set by default for Authentication and Sessions cookies in ASP.NET 2.0 but not for manually issued cookies. Therefore, you should consider enabling this option for your manually issued cookies as well. This option can be enabled in web.config by modifying the httpCookies element as in the example below:

When an HttpOnly cookie is received by a compliant browser such as Internet Explorer Service Pack 1, it is inaccessible to client-side script. But this does not prevent an attacker with access to the network channel from accessing the cookie directly.

Note that in ASP.NET 1.1 the System.Net.Cookie class does not support the HttpOnly property. Therefore, to add an HttpOnly attribute to the cookie you could add the following code to your application's Application_EndRequest event handler in Global.asax:

protected void Application_EndRequest(Object sender, EventArgs e)

{

string authCookie = FormsAuthentication.FormsCookieName;

foreach (string sCookie in Response.Cookies)

{

if (sCookie.Equals(authCookie))

{

Response.Cookies[sCookie].Path += ";HttpOnly";

}

Least Privilege Development in Microsoft Windows Vista

dansellers — Fri, 10 Mar 2006 22:05:00 GMT

In my last Webcast on Least Privilege I eluded to the fact that this was going to change with the release of Windows Vista. In fact it is going to change significantly.

Here is a white paper that provides an understanding of User Account Protection (UAP) in Windows Vista. The paper was written a few months ago but is still very relevant.

Thoughts on Security Analogies

dansellers — Fri, 10 Mar 2006 21:22:00 GMT

I thought I would share Michael Howard's recent blog on "Security Analogies are Wrong". I agree with Michael take on Security Analogies as I hear them all the time but I thought his post was hilarous as he turns the tables with his counter analogy:

If cars operated in an environment like the Internet, they would…

Be driven by people with little regard safe automobile operation.
Have their windshields shot out every 60 secs.
Once you have bullet-proof glass, the bad guys place nails at freeway off-ramps next to signs like, “free coffee this way”

and someone is always trying to steal your keys
and pull out your sparkplugs
and siphon your gas

Talking of gas, you fill up at a Shell station, only to realize the gas really isn’t gas, it’s vegetable oil and sand
Oh, that gas station isn’t a Shell station, it certainly looked like one, but they took your credit card details anyway
As this all goes on, you can’t see the adversary
And the adversaries are sharing new weapons with each other

Microsoft Threat Analysis & Modeling tool v 2.0 (Beta 2)

dansellers — Fri, 10 Mar 2006 12:11:00 GMT

Today Microsoft released Beta 2 of the second version of the Threat Modeling and Analysis Tool for download. Microsoft has been using the Threat Modeling methodology as part of our Security Development Lifecycle for a few years now.

Threat Modeling is a security-based analysis of an application to find “anti-scenarios”. This is probably one the biggest reason I like threat modeling as it makes the Application Architects and Developers look at their applications in a different way. By examining the “anti-scenarios” we will look at our applications more from a hacker's point of view which is outside-in approach versus our standard thinking of looking at an application from an inside-out perspective. This difference in mind set makes it easier to explore the potential attacks against our applications.

Now this does lead to some problems as it is hard to unlearn what we have been taught for a long time about examining our applications usually from Quality Assurance's point of view. Therefore, threat modeling can be difficult for Application Architects and Developers to master, compared to most Info Sec people.

The new Threat modeling and analysis tool, however, focuses more on the threats then the attacks. As an Application Architect or Developer of a system we have a better understanding of what is considered important and thus potential threats. By understanding the threats better this will have tendency to uncover the different attacks our application may face.

With this new approach Application Architects and Developers now view their application from the defender's point of view which lends itself to making it more natural for all stakeholders to effectively participate in the threat modeling process.

Along with automatically identifying threats, the tool can produce valuable security artifacts such as:

Data access control matrix
Component access control matrix
Subject-object matrix
Data Flow
Call Flow
Trust Flow
Attack Surface
Focused reports

If you have not looked at threat modeling before, I highly suggest that you do as it is an excellent practice to examine application from a security perspective and not strictly a Quality Assurance point of view.

Answer to the Trivial Question

dansellers — Thu, 09 Mar 2006 20:02:00 GMT

The answer to the trivial question from my blog based upon the March 8, 2006 WebCasts “Least Privilege Development and New System.Security Features” is below:

Question:

The KeyInfo element can consist of either a <KeyName/> or a <RetrievalMethod/> child element. What is the purpose of each element and what are the differences between the two elements?

Answer:

Both elements are used to provide additional information about KeyInfo:

KeyName - is a string identifying a key pair [key identifier]. Something along the lines of <!ELEMENT KeyName (#PCDATA)>

RetrievalMethod - on the other hand retrieval method is a reference to a remote source that can be used to gather information about the KeyInfo.

For instance, signatures in a document may use a key verified by a certificate chain appearing once in a document or remotely outside the document; where each signature's KeyInfo can reference this chain using a single RetrievalMethod.

Difference:

One element is a string that has the potential to indirectly identify a key while the other is used as direct reference.

We now have our three winners. Thank you everyone for attending the Webcast and look forward to seeing you next week.