Secure Code

This blog is moving! - New location http://www.aniltj.com/blog

Anil John — Mon, 09 May 2005 18:03:00 GMT

This blog is moving!

RSS Feed @ http://www.aniltj.com/blog/SyndicationService.asmx/GetRss

Upcoming Secure Coding Book by authors of Writing Secure Code!

Anil John — Fri, 10 Dec 2004 22:42:00 GMT

Came across an interesting comment on one of the lists that I am on.

It would appear that Michael Howard and David LeBlanc, the authors of Writing Secure Code, are working on a new book with John Viega (Building Secure Software) and David Wheeler which is scheduled to hit the shelves in about 6 months. According to LeBlanc, they specifically chose this set of authors to provide really good cross-platform coverage.

Looks like a must have book!

IEEE Security & Privacy: Building Security In

Anil John — Fri, 10 Dec 2004 22:30:00 GMT

Gary McGraw has a series of articles in IEEE Security & Privacy that address secure coding issues. As a service to the community, he has made the articles available to the community. The current article in the series ".... is on Penetration Testing. This article was co-authored by Brad Arkin (Symantec) and Scott Stender."

Previous articles in the series:
http://www.cigital.com/papers/download/bsi5-static.pdf
http://www.cigital.com/papers/download/misuse-bp.pdf
http://www.cigital.com/papers/download/risk-analysis.pdf
http://www.cigital.com/papers/download/j2oth-qxd.pdf
http://www.cigital.com/papers/download/software-security-gem.pdf
http://www.cigital.com/papers/download/bsi6-pentest.pdf

Check them out!

Presentation on Instrumenting .NET Code & Defense-in-Depth

Anil John — Tue, 07 Dec 2004 22:08:00 GMT

I just got back from the CMAP .NET User Group meeting during which I did 2 short presentations. At CMAP's December meetings we have a "10 Tips & Tricks for the Holidays" presentation format in which members do short 10-15 minute presentations on various topics. This year's topics ranged from my stuff to a demo of how to use client side script in ASP.NET. My topics were "Instrumenting .NET Code with Log4Net" and "Applying Defense-in-Depth to protecting admin sections of web sites".

During the instrumenting & logging presentation I mentioned that K. Scott Allen has a great write-up on Diagnostics and Logging in ASP.NET and that people should check it out to get a background on the "Why?" regarding instrumenting applications. Then I went into a short description of what Log4Net brought to the table and compared it to the PAG's Exception Management Block and the Logging Block. In addition, I also had an earlier blog entry about incorporating logging into a web application.

My Defense-in-Depth short presentation was an expansion of an earlier blog entry that I had made on this topic.

Browsing the Web and Reading E-mail Safely as an Administrator

Anil John — Fri, 19 Nov 2004 21:41:00 GMT

Michael Howard discusses how you can run as an administrator and access Internet data safely by dropping unnecessary administrative privileges when using any tool to access the Internet.

He has created an application called DropMyRights to help users who must run as an administrator run applications in a much-safer context—that of a non-administrator. It does this by taking the current user's token, removing various privileges and SIDs from the token, and then using that token to start another process, such as Internet Explorer or Outlook. This tool works just as well with Mozilla's Firefox, Eudora, or Lotus Notes e-mail.

Check out the article...

Security focused Issues - TechNet Magazine & MSDN Magazine

Anil John — Sat, 30 Oct 2004 22:26:00 GMT

The premier issue of TechNet Magazine is out and it is focused on Security. Sections include

Hacking: Fight Back
Cross-Platform Security
Security: Beyond the Basics

Check it out the full issue which is availabe for free online.

Of course, the current issue of MSDN Magazine is also focused on security. Topics include Attack Surface minimization, App Lockdown, Crypto and more. Check it out online as well.

Using Secret Questions & Blocking Brute Force Attacks

Anil John — Sun, 24 Oct 2004 20:33:00 GMT

Mark Burnett, who is the author of "Hacking the Code", has a couple of great articles posted to the OWASP site.

Both are must read articles!

Password Memorability and Security

Anil John — Thu, 14 Oct 2004 19:24:00 GMT

There has been much talk about what is considered a secure password. So it was a true pleasure for me to recently read a fascinating study on this topic that provided some hard numbers to back up the claims. The study was published in the current issue of IEEE Security and Privacy and is titled "Password Memorability and Security: Empirical Results" by Jeff Yan, Alan Blackwell, Ross Anderson and Alasdair Grant.

First some background. Per the article "Human memory for sequences is temporally limited, with a short term capacity of around seven, plus or minus two items. In addition, when humans do remember a sequence of items, those items be familiar chunks such as words or familiar symbols. Finally, human memory thrives on redundancy-we're much better at remembering information we can encode in multiple ways"

So what these folks did was have three separate test groups:

The control group were asked to choose a seven-character password with at least one nonletter
Second group chose passwords by closing their eyes and pointing randomly to a grid of numbers and letters
The third group was instructed to chose passwords based on mnemonic phrases and given examples of how to go about doing so

Then the testers ran the following types of attacks against the passwords:

Dictionary attacks: Simply use different dictionary files to crack the passwords
Permutation of words and numbers: For each word from a dictionary file, permute with 0, 1, 2 and 3 digits and also use common number substitutions such as 1 for an I and 5 for S etc.
User information attacks: Exploit user data that is collected from password files such as userid, full name etc
They also tried brute force attacks (Try all possible combination of keys) against passwords 6 characters long.

Pick up and read the article itself for the details and the numbers, but the conclusions are interesting. The permuted dictionary attack was the most successful and the brute force attack successfully cracked all six-character passwords.

They also confirmed the two folk beliefs that "... user have difficulty remembering random passwords and that passwords based on mnemonic phrases are harder to guess than naively selected passwords." They have also debunked the folk beliefs that "... random passwords are better than passwords based on mnemonic phrases. Each appeared to be as strong as the other" and that "... passwords based on mnemonic phrases are harder to remember than naively selected passwords. In fact, each type is as easy to remember as the other".

Some of the key take-aways were:

"... security can be significantly improved by educating users to select mnemonic passwords
Size of the password matters
Entropy per character matters, so instruct users to choose passwords containing numbers and special characters as well as letters."

So what does this mean for me? Well from now on, my password selection page is going to have the following (Some of the content is adapted from the directions that were given to the mnemonic group in the test):

Choosing a good password is critical to maintaining the security of this system. To construct a good password, create a simple sentence of 8 to 9 words and choose letters from the words to make up a password. You might take the initial or final letters; you should put some letters in upper case to make the password harder to guess; and at least one number and special character should be inserted as well. An example is the phrase "It's 12 noon and I am hungry" which can be used to create the password "I's12n&Iah". All passwords will be checked to make sure that the following complexity requirements are met:
- Must be at least 9 characters
- Must contain at least one lower case letter, one upper case letter, one digit and one special character
- Valid special characters are - @#'$%^&+=

The key point here is not to just to show them the 3 above bullet items but to provide explicit guidance on how a password should be chosen to meet the outlined complexity criteria.

Oh yes, as a bonus here is a regex that will enforce the above complexity requirement:

^.*(?=.{9,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#'$%^&+=]).*$

Authentication/Authorization and Defense in Depth

Anil John — Sat, 09 Oct 2004 17:39:00 GMT

It has been interesting to me to see the recent ASP.NET vulnerability play out. One of the main factors that came into focus for me was that most developers do not seem to consider the principal of Defense in Depth when it comes to writing privileged code.

Since an example speaks much louder than lectures, lets take the following case..

My web site is as follows:

\webroot
- web.config
\Camelot
- ProtectedPage.aspx

My web.config has the following:

As you can see above, the web application is configured such that the only users who have access to the protected directory "Camelot" are members of the group "KnightsRoundTable".

The problem is that most people leave it at that.. That is NOT Enough!

At this point you are basically exposed when your authorization module is somehow bypassed. So let us take a look at some things you can do to apply the principle of Defense in Depth to ProtectedPage.aspx.

1) Restrict which users can call your code

One of the easiest ways to do this is to annotate your classes and methods with declarative principal permission demands to control which users can call your classes and class members. In the above example, I would do the following:

[System.Security.Permissions.PrincipalPermission
(System.Security.Permissions.SecurityAction.Demand,Role=@"KnightsRoundTable")]
public class ProtectedPage: System.Web.UI.Page
{

}

If anyone who is not in the KnightsRoundTable group tries to call this page, they will get the following error:

Security Exception
Exception Details: System.Security.SecurityException: Request for principal permission failed.

And if you've done right thing and set up a Default Redirect page for errors, they will not get a stack trace and will be redirected to a generic error page.

2) Protect against spoofed post backs.

void Page_Init (Object sender, EventArgs e)
{
if (User.Identity.IsAuthenticated)
ViewStateUserKey = User.Identity.Name;
}

What this does is key the view state to an individual using a unique value of your choice. This option, which is only available in ASP.NET 1.1, is the Page.ViewStateUserKey. This needs to be applied in Page_Init because the key has to be provided to ASP.NET before view state is loaded.

3) Redirect if user is not authenticated

The third thing that I do in a protected page simply make sure that a user is authenticated before they are allowed to view any content.

private void Page_Load(object sender, System.EventArgs e)
{
if (!User.Identity.IsAuthenticated)
Response.Redirect("~/GoodBye.aspx",true);
}

The key point here is that I am not simply depending on just one thing here to protect this page but a layered defense. Hopefully if one thing fails, the others will protect the page.

Oh, did I mention that I also extensively instrument my applications such that when someone does try to access a protected page, I log that activity and if the content of that page is sensitive enough, I may also send real time notification of attempted break-ins to an admin?

Paranoid? Perhaps. But I also sleep a whole lot more soundly :-)

Enforcing Password Complexity

Anil John — Thu, 23 Sep 2004 22:18:00 GMT

There has been some discussion of late about passwords vs. pass phrases and how long a password should be. I won't add to the mix except to say that I am a believer when it comes to complex passwords. Heck, my 4 year old is required to use a userid and password to log into his session on his computer :-)

I've recently been working on some things that require me to make sure that the passwords that are used are sufficiently complex. Here is what I am using right now:

Must be at least 10 characters
Must contain at least one one lower case letter, one upper case letter, one digit and one special character
Valid special characters are - @#$%^&+=

The regex that I am using to enforce this is:

^.*(?=.{10,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%^&+=]).*$

As you can see in the regex, the list of special characters is configurable...