It looks like the HDC 2004 site is up and running, so now is a good time to mention this. I will be speaking at the first annual Heartland Developers Conference 2004 in Des Moines, Iowa on December 3. There are two tracks: .NET Today and .NET Tomorrow. My topic will be under the .NET Tomorrow track: SQL Server 2005 Service Broker.
If you are in Iowa, Minnestoa, Nebraska, North Dakota, or South Dakota, you won't want to miss this great opportunity to learn what's going on in .NET now and in the future. Registration is $18.00. Sign up at the link above.
I had the pleasure of attending Michele Leroux Bustamante's talk this past week on Web Services Security with a focus on WSE 2.0 at the NH .NET User Group meeting in Tyngsboro, MA. She covered some aspects of WS-Policy, WS-Trust, WS-SecureConversation, and other WS-Security friends as well as demonstrated real world problems in building secure web services and some good solutions using and extending WSE 2.0. Michele links to her examples off her blog post on this event.
Michele is an excellent speaker and presenter. If you ever have a chance to attend one of her talks at a conference or user group, don't hesitate to go. You will learn much and will be glad you went. This is the first time I had seen her speak, but I have always enjoyed her writing and looked forward to her talk here. She was on a whirlwind tour in the New England area this past week; first at Vermont (read Julie Lerman and Dave Burke's posts regarding her visit), then at SD East, and then our NH group.
These guys also attended the meeting: Sam Gentile, Duane LaFlotte, Patrick Hynds, Greg McKinley, and Jim Murphy (both Sam and Duane have great posts about Michele's visit as well).
I added a couple of other topics to my proposed list at Code Camp II:
Developing as a non-admin (chalk talk)
We have all heard we shouldn’t run as administrator on our computers. But, how do you develop software as a non-admin (i.e. normal/limited user)? It really is a lifestyle change. This interactive talk will discuss techniques and reasons for developing as a non-admin, as well as problems, solutions, and experiences developers have encountered as they have tried to develop software as a non-admin.
SQL Server 2005 Service Broker (presentation)
Service Broker is a framework built into SQL Service 2005 that greatly simplifies the creation of reliable, scalable, message-based, asynchronous, distributed database application. A service broker can manage business transactions, which in practice can last for hours, days or indefinitely and span databases. A Service Broker application consists of a set of services, queues, message formats, and dynamically created conversation. Any application that can make a connection to SQL Server or a web service can make use of a Service Broker application. This session will cover the basics of Service Broker and show the implementation of a Service Broker application.
Take a look at the other talks -- this is going to be a great conference weekend!
Prompted by Dinis Cruz's question on my CLR Hosting in Whidbey/2.0 post, I checked if it is now easier to create Partial-trust ASP.NET web sites in 2.0.
By default, ASP.NET sites run and are built as "Full Trust" sites. This means a web application has full access to the machine's resources. That may be OK if you are hosting the site on your own server (I would still caution running with "Full trust" on your own server as well!), but what if you are hosting your web application on a shared server such as at an ISP with multiple other companies and people you don't know hosting their site as well? If each ASP.NET web site is running with Full Trust (and using the same Windows user), one web application could read the files from another application's folder, i.e. web.config!
In ASP.NET 1.0, you could only run your web applications with Full Trust. In ASP.NET 1.1, this was fixed slightly by allowing web applications to run in partial-trust mode. The standard trust levels are "Full", "High", "Medium", "Low", and "Minimal". The problem with 1.1, though, was that you had to set this trust level at machine level, i.e. machine.config. And, of course, that would affect the entire machine. If you reset the level at the top, many web applications that were running correctly would probably start throwing exceptions as it does take some extra coding to get partial-trust sites to run correctly.
Update: Actually, as mentioned by Dinis, my results in ASP.NET 2.0 are very similar to what was already available in ASP.NET 1.1. You could set trust levels at web.config levels -- I was mistaken.
Tests still need to be done to determine if partial-trust assemblies are any more powerful in ASP.NET 2.0 than in ASP.NET 1.1, as one of the biggest problems with 1.1 was the lack of functionality in the "highest" partial trust application.
This past week, I had the opportunity to attend a couple of user group meetings, both of which featured Jeff Prosise as the speaker. Both meetings were sponsored by INETA. Jeff spoke to the Wednesday Boston .NET User Group meeting on Power ASP.NET 2.0 Programming. Christopher Bowen and Girish Bharadwaj give excellent summaries of this meeting. I enjoyed this meeting as well, but I particularly liked his Thursday New Hampshire .NET User Group meeting topic on Hacked! How Evil People Attack ASP.NET Web Sites.
Jeff is an excellent speaker as he doesn't get bogged down by PowerPoint slides, but instead speaks directly to the developer about the problems and solutions for writing good, secure code. Jeff presented on the topics of hidden field tampering, SQL injection, and cross-site scripting.
Hidden field tampering: I am surprised how many developers haven't heard of this by now, but as Jeff mentioned, he has seen recent cases where this was not guarded against on a site and was exploited. Basically, if you allow sensitive data to be displayed openly in hidden forms, and don't validate or verify the data coming back from the form, you could be affected by a hacker changing the expected value in the hidden field. It's an old trick: change the ticket amount for your flight from $1000.00 to $1.00 and post the form back to the web site, and you have a cheap (illegal, of course!) trip! The key is, as always, never trust input coming from the outside. Remember, trust, but verify. Of course, with ASP.NET, you should use the ViewState to hold encrypted encoded hidden form values, or better yet, don't pass any sensitive information back to your forms.
Update: As mentioned by Atilla in the comments, ViewState is not encrypted, but Base 64 encoded -- it can be viewed by a hacker. There is a hash value added to the ViewState before being sent back to the client. This is verified back on the server to determine if there was any tampering of data. Once again, though, it is best never to send sensitive information back to the client.
SQL Injection: This is one of those topics that easily prompts someone in the audience to suddenly jump up and run out of the room frantically calling their office to check if they have this problem! If a form field is not checked for input, and you use concatenation of SQL script in any way, you could be open to this exploit. For example, in many samples and other places, you see code similar to this:
sqlQuery = "select count(*) from users where username = '" + username + "' and password = '" + password + "'";
which looks like this when passed in to the database:
select count(*) from users where username = 'George' and password = 'letmein'
This can be exploited by inserting ' or 1=1 --, which changes the meaning:
select count(*) from users where username = '' or 1=1 (remember, -- is a comment, so everything after the 1 is ignored).
This will always evaluate to true. This is worse:
select count(*) from users where username = '' union select name from sysobjects where type = 'u' --
where this will return all table names within your database (SQL Server specific, but similar things can be done with Oracle, etc. as well). This can continue with call xp_cmdshell to delete a file (as Jeff demonstrated) or worse. I have seen it used to upload files, create users, and basically set up shop on your database server! The bottom line is to verify input, use SQLParameter to turn the input into strings rather than active SQL syntax, and run with a least-privileged user (non "SA"!) when calling into the database.
Cross-site scripting: This is one of those exploits that allows a hacker to steal cookies, session information, and other sensitive data. If not checked, a hacker could imbed a <script> tag in your input field or on a query string, and if the input is repeated back on the form after a postback, the hacker will now be able to call this form remotely and obtain sensitive information. A common technique using this exploit is "phishing". A user gets an email from a bank or other trusted entity and is asked to update their account. If a cookie was saved on the user's computer, the link will "appear" to go to the bank site, but instead will take a detour to grab the saved cookie using a <script> tag form post. One variation of phishing is to present a site that looks exactly like the bank site, asking for the user's account information. The solution to this is to, of course, validate user input, but to also use HtmlEncode around anything you retrieve and display on your web site.
Jeff mentioned that Microsoft is now using Validation Layers as one of the layers in an application. This sounds like a great idea! Essentially, all input and sometimes output from the database, should go through this layer for scrubbing and validating before it enters the rest of your business logic and data layers.
At the end of Jeff's presentation, someone asked for more resources on this topic. Here are a few that I know about and have used:
Building Secure Microsoft ASP.NET Applications by Microsoft Patterns and Practices Group
Improving Web Application Security: Threats And Countermeasures by Microsoft Patterns and Practices Group
Writing Secure Code, Second Edition by Michael Howard and David LeBlanc
Hacking the Code: Auditor's Guide to Writing Secure Code for the Web by Mark Burnett
Recently, I had the pleasure of looking at early beta versions of a new product that helps catch and log these kinds of exploits. Take a look at Peter Blum's Visual Input Security tool for ASP.NET web sites. Some highlights of the tool:
- Protects visible fields, hidden fields, query string parameters, and cookies
- Block access to pages that have received multiple attacks to slow the hacker down and reduce the resources used
- Log attacks in great detail. Also can log your site's exceptions and other errors. It can notify you through email.
- Security Analysis Report provides a full audit of each page's inputs and their security settings. It even recommends how to improve your security.
- Each field can have its own rules for allowing certain HTML tags or SQL-like statements.
- Provides tools to neutralize attacks that are not caught by validators.
- You can customize the rules for detecting attacks.
Overall, as Jeff concluded, you have to be prepared, informed, and ready for the security challenges you WILL face in developing ASP.NET web sites. Do all that you can to learn about these issues, and make sure your site is not open to these and many other exploits.
From Omri Gazitt:
In addition to the new Transfer and Enumeration specs, we published a whitepaper today providing an overview of the Web services architecture. It's a great place to start for folks who want to understand the architectural tenets that have guided our design, as well as how the individual specs fit together to form an architectural whole. We anticipate updating it occasionally to reflect the evolution of the architecture as it further matures.
Congrats to Felipe and to the many other folks who contributed to this paper!
This whitepaper is a great addition to the literature on web services and where it is going. I like that they will be updating it as the architecture moves along as well.
Jesper Johansson has started a new article series on The Great Debates: Pass Phrases vs. Passwords Part 1 of 3, continuing the debate on which method of secure authentication to use.
For a different spin, I recently heard about PassFaces. Last week, I attended the New England Information Security Group meeting in Waltham, MA at the Microsoft offices and heard someone from Real User talk about this interesting way of authenticating users. Below is a snippet of information from their site:
How The Passface™ System Works
| | Users start by getting to know a group of (typically 3 to 7) faces – their passfaces – which are assigned by the system at random from a large library of anonymous faces. This simple and intuitive initial familiarization process takes around 3 to 5 minutes for 5 passfaces. |
| | To authenticate a user, the system displays a 3 by 3 grid of faces containing one passface and 8 decoy faces positioned randomly within the grid.
|  |
| | The user responds by indicating the position of their passface in the grid. This challenge/ response is repeated with each of the user's remaining passfaces – each time presented in a grid with 8 more decoy faces. |
| | The user is authenticated once all their passfaces have been recognized successfully. |
I know several of us who attended were intrigued by this new method, but I also thought about the various ways this system may be overcome and compromised. Either way, its good to have some options.