![]() |
![]() |
|
August 23, 2006WTF? Can some .NET guru help me out?Recently I had to figure out some VB.NET code and port it to C#. I am not much of a VB guy, but I figured I could understand some basic stuff. I am having some difficulties, and was hoping someone could explain the brain dead issue I am having. Here is the VB.NET code:
Here is the C# code I am trying:
You would THINK that key_aes128 would be the same. They are CLOSE.... but not actually the same. Anyone know what the heck I am doing wrong? It SHOULD result in the exact same string. August 17, 2006Leveraging powerful data validation in SQL Server 2005I am so pleased with deciding to go with SQL Server 2005 Express for a recent project. I recently learned about an extremely powerful feature that makes data validation in the database a breeze. Whenever you use input from an untrusted source, it needs to be validated. Especially if it comes from or can be accessed by the user. The best way to handle this is to put an input sentry at any trust boundary, as it crosses from an untrusted to trusted border. Ultimately, the last line of defense will be the database, as that is where the final storage ends up... at least for our application. You can easily apply CHECK constraints on fields in the database. But that is a very rudimentary method of validating the input, since you can typically only do basic checks. Enter the fact that in SQL Server 2005, you can now enable CLR in the database, and write user-based functions in your favorite .NET language. And more importantly, you can CALL these functions AS constraints on fields in the database. This is really impressive stuff. In my case, I wrote a generic regular expression validation function that allows me to do the deepest of validation checks on the data before its inserted. If the data fails the regex validation, the record will not be committed. I decided to screencast the authoring of this powerful regular expression validation method. Feel free to use it yourself on your SQL Server 2005 databases. You can view the screencast here. And remember... always assume that input is malicious until proven to be safe. August 14, 2006Engineering secure code in small teamsI've been pretty quiet here lately as I take on an interesting project that is consuming a lot of my time. In the month of August, I have been working on "Project Anvil", an open and transparent experience where I am blogging the construction of a strong authentication server for small business... all built on the Windows stack with the smallest of teams... just me. Why this is interesting is that I am showing how you can design more secure systems WITHOUT needing complex teams to accomplish the goals. One of the key reasons I am doing this is that I am tired of seeing micro and small ISVs (independent software vendors) complain that they cannot build a business based on quality software because they don't have the same large teams and development resources of companies like Microsoft or IBM. I shake my head when I listen to whining about how they are too small to build secure software and how that in an effort to put food on the table, they can't architect software that runs safely on our platforms of today. And I am tired of watching startups write crappy software because some VC or angel screams "get version 1 out, and worry about making it work later". If this interests you, please consider following my progress on the Project Anvil blog. I would recommend you start from the first post, and read it in sequence. And please, feel free to comment and criticize. Challenge me, and my assumptions. I would love the opportunity to learn from your experiences as I share mine. August 08, 2006Work around for "Threat Analysis & Modeling v2" tool least privilege install bugSo with help from Dan Sellers and Talhah Mir over at Microsoft, I finally figured out and fixed a problem I have been having with Microsoft's latest version of the "Threat Analysis & Modeling v2" tool. It seems that a good portion of the comboboxes in the application were "blank". And it was making it impossible to complete production threat models since all the critical components needed weren't available. Ends up, its an issue with installing the tool in a least privilege environment. And a rather funny one at that. The tool itself was written properly to handle least privilege by loading the data needed in the comboboxes from an AppLists.xml file, located in <user home directory>\Application Data\Microsoft\TAM\Temp\. Problem was, it EXPECTS that the user installed it and has the file. In my case, I installed the tool with an administrator account, expecting it to work for both domain and nondomain limited user accounts on my laptop. There WAS a proper AppLists.xml located in that admin's directory. However, on the least privilege accounts, a default empty one was created when the original XML file could not be found. The result... all the blank comboboxes I was seeing. The fix was simply to copy the properly populated AppLists.xml file from the admin account into the least privilege account. Walla. It all works now. August 01, 2006A Process for Performing Security Code ReviewsSo in this month's IEEE Security and Privacy magazine Michael Howard wrote an interesting article on "A Process for Performing Security Code Reviews". It's worth the read. His insights on how to prioritize what code to review first is something I think we all can learn from. I've never seen a calculation for bug density like that before. I wonder how effective that has been in the Microsoft code base? Happy reading! Security Model Analysis of Windows VistaMatthew Conover, a security researcher over at Symantec, has published a new paper on the "Analysis of the Windows Vista Security Model". His paper provides an in-depth technical assessment of the security improvements implemented in Windows Vista, focusing primarily on the areas of User Account Protection and User Interface Privilege Isolation. The paper discusses these features and touches on several of their shortcomings as viewed by Symantec. It then demonstrates how it is possible to combine these attacks to gain full control over the machine from low integrity, low privilege process. Similar to their last paper on the Vista attack surface, they seem to continue to reference older builds and offer opinions on pieces that are still being tweaked. With that said however, I found that this paper does offer some insight and critical thinking about privilege elevation in Vista. You might be interested in checking it out. Happy reading. |
![]() ![]()
My 5 Favorite Books
Writing Secure Code
Secure Programming Cookbook Security Engineering Secure Coding Principles & Practice Inside the Security Mind ![]()
My 5 Favorite Papers
Smashing the Stack
Penetration Studies Covert Channel Analysis of Trusted Systems DoD Trusted Computer System Evaluation Criteria NSA Security Recommendation Guides ![]()
Archives
September 2006
August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002 August 2002 July 2002 ![]() |
|