I love the creative process of programming. In this blog I write about things related to programming that I find useful, interesting, funny, original, or just amazing!
Tuesday, April 16, 2013
How to quickly open Visual Studio project's properties
I used to do this by right-clicking the project in the Solution Explorer and scrolling all the way down the context menu to select Properties. This is really cumbersome. It turns out there is a much quicker way to do this: Just double-click the Properties node under the project in the Solution Explorer! And of course, there is a shortcut for that too: Alt+Enter !!! It works both in Visual Studio 2010 and 2012.
Happy coding!
Thursday, March 21, 2013
Learning Web App Security with Google Gruyere
I've been developing web applications for almost 10 years now, but I was rarely concerned with application security issues. To be sure, I am a defensive programmer, meaning that I do all kinds of checks on the inputs received by my functions, leaving very little to chance. But although I heard much about cross site scripting (XSS) and SQL injection, I didn't have a very clear understanding of these concepts. I relied on best practices (like parametrized database queries) and inherent ASP.NET features like request validation to take care of malicious inputs, be it form variables or query string parameters.
Yet I always had a gnawing feeling that I should get more understanding of web app vulnerabilities, attacks and defenses. So this month I started to look for way of how I can brush up on this important topic.
I found a couple of books, of which this one seems to collect a lot of praise from readers: The Web Application Hacker's Handbook (WAHH). I started to read the book, but I also wanted something more practical. I came across Open Web Application Security Project (OWASP) with its plenitude of resources and the famous OWASP Top 10 list of web app security flaws.
OWASP members also develop security software such as the security testing tool ZAP and the request intercepter proxy WebScarab. Both I really handy and easy to use.
OWASP has also produced WebGoat, a fictitious web application full of vulnerabilities that you can run and test locally on your PC. WebGoat has a number of lessons to teach about various security flaws that you can try to discover on your own with the help of some hints. Although a great resource, I found WebGoat somewhat lacking in the quality of their materials.
And then I stumbled upon Google Gruyere, which is a very elaborate web security code lab from Google Code University. It is much similar to WebGoat in that it gives you a sandbox to learn about and try to dicover security flaws in a Python web application that you can run either locally or online. It does a great job of explaining various security concepts and provides challenges to explore them in practice as well as guidance on how to guard against them. It is especially good at explaining the various flavors of XSS attacks, but it also provides a good foundation for understanding many other topics such as path traversal, denial of service and code execution. It touches upon but doesn't go into the details of SQL injection.
I've gone through the lab and thoroughly enjoyed the challenges and learned to use the tools like WebScarab and ZAP. I'd recommend it to anyone interested in web application security!
In parallel I did some security testing of the web applications that I've been involved with for the last year or so. I found that ASP.NET does a great job protecting ASP.NET applications from certain types of attacks out of the box. I found some minor flaws that are mostly due to relying too much on client side validation and forgetting to validate user input again on the server. A quite trivial example of this is being able to intercept a request and change the house number to a negative value. But I also discovered a more serious exploit using the same technique, which I will not describe here :)
The main lesson that I've drawn so far is that we should never trust input coming into our applications, be it through a web browser or a web API. Most security flaws in software result from sloppy programming. Web developers should be well aware of these issues and write their code defensively and test it thoroughly not only from the point of view of functionality but also security-wise.
To sum up, these have been very interesting and instructive few weeks. Web application security is a fascinating topic and I look forward to diving even deeper into it!
Happy coding!
Yet I always had a gnawing feeling that I should get more understanding of web app vulnerabilities, attacks and defenses. So this month I started to look for way of how I can brush up on this important topic.
I found a couple of books, of which this one seems to collect a lot of praise from readers: The Web Application Hacker's Handbook (WAHH). I started to read the book, but I also wanted something more practical. I came across Open Web Application Security Project (OWASP) with its plenitude of resources and the famous OWASP Top 10 list of web app security flaws.
OWASP members also develop security software such as the security testing tool ZAP and the request intercepter proxy WebScarab. Both I really handy and easy to use.
OWASP has also produced WebGoat, a fictitious web application full of vulnerabilities that you can run and test locally on your PC. WebGoat has a number of lessons to teach about various security flaws that you can try to discover on your own with the help of some hints. Although a great resource, I found WebGoat somewhat lacking in the quality of their materials.
And then I stumbled upon Google Gruyere, which is a very elaborate web security code lab from Google Code University. It is much similar to WebGoat in that it gives you a sandbox to learn about and try to dicover security flaws in a Python web application that you can run either locally or online. It does a great job of explaining various security concepts and provides challenges to explore them in practice as well as guidance on how to guard against them. It is especially good at explaining the various flavors of XSS attacks, but it also provides a good foundation for understanding many other topics such as path traversal, denial of service and code execution. It touches upon but doesn't go into the details of SQL injection.
I've gone through the lab and thoroughly enjoyed the challenges and learned to use the tools like WebScarab and ZAP. I'd recommend it to anyone interested in web application security!
In parallel I did some security testing of the web applications that I've been involved with for the last year or so. I found that ASP.NET does a great job protecting ASP.NET applications from certain types of attacks out of the box. I found some minor flaws that are mostly due to relying too much on client side validation and forgetting to validate user input again on the server. A quite trivial example of this is being able to intercept a request and change the house number to a negative value. But I also discovered a more serious exploit using the same technique, which I will not describe here :)
The main lesson that I've drawn so far is that we should never trust input coming into our applications, be it through a web browser or a web API. Most security flaws in software result from sloppy programming. Web developers should be well aware of these issues and write their code defensively and test it thoroughly not only from the point of view of functionality but also security-wise.
To sum up, these have been very interesting and instructive few weeks. Web application security is a fascinating topic and I look forward to diving even deeper into it!
Happy coding!
Thursday, March 14, 2013
ASP.NET debug="false" and line numbers in error stack trace
It's a good practice to always log run-time errors to a database table or a log file or both. It is also nice to have line numbers appear in the stack trace to be able to see where in your code the error appears. For some types of errors, e.g. for exceptions of type
In the past I had to deploy a debug build of the application and set
But what do we do if we really want more detailed error information in our logs? There appears to be a an easy way to do this. In the properties of your project, in the Build section, select your Release configuration, click Advanced and make sure that Debug Info is set to pdb-only. This is equivalent to setting this compiler option:
This will allow you to log error details like line numbers without significantly affecting the performance of your compiler-optimized release assemblies. Warning: if you do this, then also please make sure that you don't set
Happy coding!
NullReferenceException, this is especially relevant as there is no other way to determine what went wrong.In the past I had to deploy a debug build of the application and set
debug="true" within the compilation section of web.config, in order to be able to see the line numbers in error logs. But this is not a good idea, as this adversely affects application performance (see this blog from Scott Guthrie for more details and this blog for even more details). So please, always set debug="false" in production environments. Or, even better, set deployment retail="true" in your production machine.configBut what do we do if we really want more detailed error information in our logs? There appears to be a an easy way to do this. In the properties of your project, in the Build section, select your Release configuration, click Advanced and make sure that Debug Info is set to pdb-only. This is equivalent to setting this compiler option:
/debug:pdbonly in the compilerOptions attribute of the compiler element in web.config (for more details about this compiler option read this MSDN article and this blog article). This will emit your optimized release assemblies together with corresponding .pdb files containing all the information needed to reference files and line numbers in exception stack traces. You can then deploy the build output into your production environment.This will allow you to log error details like line numbers without significantly affecting the performance of your compiler-optimized release assemblies. Warning: if you do this, then also please make sure that you don't set
customErrors mode="off" so that you don't expose detailed exceptions to remote users (which is a wise thing to do from security standpoint!)Happy coding!
Monday, September 5, 2011
Stopwatch Class and Handy Static Methods of Enumerable
It's amazing how much there is to discover about .NET Framework! A couple of days ago I came across a neat little class called System.Diagnostics.Stopwatch, which was introduced in .NET 2.0! This class comes in handy when you want to measure how long certain operations take to execute. I used to work with endTime - startTime, which yiels a timespan, which than needs to be converted to milliseconds or something:
The Stopwatch class makes our life a bit easier:
Another handy little thing to know is that the System.Linq.Enumerable class has 3 very useful static methods:
Happy coding!
startTime = DateTime.Now; // do the processing endTime = DateTime.Now; long msElapsed = (endTime - startTime).Milliseconds / TimeSpan.TicksPerMillisecond;
The Stopwatch class makes our life a bit easier:
Stopwatch sw = new Stopwatch(); sw.Start(); // do the processing sw.Stop(); long msElapsed = sw.ElapsedMilliseconds;
Another handy little thing to know is that the System.Linq.Enumerable class has 3 very useful static methods:
Enumerable.Empty<T>() returns an empty set of class TEnumerable.Range(int start, int count) returns a range of count integers starting from startEnumerable.Repeat(TResult element, int count) returns a sequence of count objects of type TResultHappy coding!
Sunday, June 26, 2011
Oracle for a .NET Developer
Even though I've been developing data driven applications for some 8 years or so, you'd be surprised to learn that I had never actually developed against an Oracle database. I've worked mostly with SQL Server, but also occasionally with MS Access and MySQL. Yet Oracle had always been terra incognita for me, until early this month I got two different assignments at two different customers, and both of them involved an ASP.NET web application with an Oracle back end!
Not that I was very happy about that, but I decided to approach it in this spirit of "I can do it" and "live and learn". Well, it took me some extra time to figure out how to work with an Oracle client, how to set up an Oracle Express database on my laptop, how to work with Oracle development tools such as Oracle SQL Developer and Toad for Oracle. But in the end I got it working just fine and learned quite a bit in the process.
So if you are a .NET developer and have to program against an Oracle database, this is how you can set up your development environment:
Not that I was very happy about that, but I decided to approach it in this spirit of "I can do it" and "live and learn". Well, it took me some extra time to figure out how to work with an Oracle client, how to set up an Oracle Express database on my laptop, how to work with Oracle development tools such as Oracle SQL Developer and Toad for Oracle. But in the end I got it working just fine and learned quite a bit in the process.
So if you are a .NET developer and have to program against an Oracle database, this is how you can set up your development environment:
- If you like working with .NET Entity Framework and LINQ for your data access (and I think you should), do install the Oracle Data Access Components for Microsoft Entity Framework. At the moment it is in beta, but it works just fine! This install includes the Oracle Instant Client, Oracle Data Provider for .NET 4 and Oracle Developer Tools for Visual Studio.
- If you don't want to work with Entity Framework, just install the latest version of the Oracle client.
- Install the free Oracle Express database for your local development.
- Install the free Oracle SQL Developer tool, which can be compared to SQL Server Management Studio Express. You may also wish to try the licensed Toad for Oracle, which to my taste has just too many features.
- In Visual Studio, open the Server Explorer and add a data connection to your Oracle Database by using Oracle Data Provider for .NET. Then generate an entity model based on this connection.
- When setting up a connection string to an Oracle database in a test or production environment, I recommend using a full connection string without a reference to tnsnames.ora, which looks something like this:
Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MyHost)(PORT=MyPort)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=MyOracleSID)));User Id=myUsername;Password=myPassword;
Even though this may seem a bit cumbersome, I found that it's better to use such a connection string instead of relying on the tnsnames.ora file, especially if there are different versions of an Oracle client installed, each having its own tnsnames.ora file.
Because of time pressure, in this particular case I had to abandon my favorite approach to new things, which is reading a good book on the subject, in favor of the "trial & error" approach. But I hope that one day I'll read a good (and small!) book about Oracle in order to better understand concepts behind it.
Software Development without Source Control?
You'd think that every single company that does anything with software development would be using some form of source code control.
Not quite so. Just recently I spent a few days helping a customer that has 3 software developers and many different applications, both web and desktop apps. To my surprise they were not using any source control. I was quite shocked. At the end of each day, I had to upload my code to my web mail, just to be sure it doesn't get lost if my laptop crashes or gets stolen.
They explained that they almost never work on the same application with more than one developer and that their production environment always has the latest code deployed to it. Well, for web applications, because they are using ASP.NET Websites (as opposed to ASP.NET web applications) and they deploy all their source code into production environment, at least they have their source code relatively safe. But for desktop applications, this is obviously not the case, because a desktop app must first be compiled.
There are of course many advantages to using source code control. To name just a few:
Not quite so. Just recently I spent a few days helping a customer that has 3 software developers and many different applications, both web and desktop apps. To my surprise they were not using any source control. I was quite shocked. At the end of each day, I had to upload my code to my web mail, just to be sure it doesn't get lost if my laptop crashes or gets stolen.
They explained that they almost never work on the same application with more than one developer and that their production environment always has the latest code deployed to it. Well, for web applications, because they are using ASP.NET Websites (as opposed to ASP.NET web applications) and they deploy all their source code into production environment, at least they have their source code relatively safe. But for desktop applications, this is obviously not the case, because a desktop app must first be compiled.
There are of course many advantages to using source code control. To name just a few:
- Source code (which is one of the main assets of any software project) is safely stored and hopefully regularly backed up, so that it does not get lost.
- Every developer has access to the latest version of the source code, without having to copy files from one developer to another.
- Source control systems maintain a history of changes to the source code, so that it's always possible to see who, when and how changed the code. And often, if developers are disciplined enough to comment before checking-in their code, one can even deduce why certain changes were maid.
- Using source control, source code can be versioned and labeled, so that one can easily see what code is part of what version of the product.
- There are more advanced source control features that can greatly improve the software development cycle, such as branching and check-in policies.
Delta-N, the company that I work for, specializes in Microsoft TFS (Team Foundation Server), which is an excellent source control system, but is also much much more. We've already made an appointment with this particular customer to see if we can help them set up source control!
Friday, June 3, 2011
Use Linked Reports in SQL Server Reporting Services!
A couple of weeks ago I was asked to develop a number of reports in SQL Server Reporting Services 2005. Most of these reports display information from different websites that the client develops and hosts for their own clients, something like 25 different websites.
My client's original idea was to create a "template" report that can then be copied for each website separately. The problem with this approach is of course that if something needs to be changed, the change will have to be copied into all 25 reports.
My initial idea was to use a join in my sql queries to the Active Directory, so that based on the current user I could figure out which AD user groups the user belongs to and then, based on a naming convention, derive from the group names which websites the user should have access to. Well, that's sort of complicated. I couldn't even get a linked server to the Active Directory working, probably because of some permissions problems.
And then I decided to use my favourite approach: I found this pretty good book on the subject: http://www.amazon.com/Microsoft-Server-2005-Reporting-Services/dp/0072262397/, skimmed through its contents and found an elegant solution in one of the last chapters.
The idea is
- to have website as a parameter in your report;
- put the report in a hidden folder on the Report Server available only to users authorized to view the information across websites; we'll call it the base report;
- create a folder for each website and set permissions on each folder;
- from the base report create a linked report for each website in the corresponding website folder
- in the linked report, go to the parameters configuration page, set the default value of our website parameter to the desired value and choose not to prompt the user for the parameter value.
To sum up, we now have a base report available to the cross-site admins and a website-specific linked report available to the website admins. If the report needs to be changed, in most cases we'll only need to update the base report!
Another useful best practice that I learned from the book is to create a template report containing the basic layout: the header, the footer, the logo, page numbering, etc. Then we can place this template .rdl report into the visual studio folder where Report Designer stores its templates (for VS2005, it can be C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ProjectItems\ReportProject) . After that, when we add a new report to our Visual Studio report project, the template will appear in the list of installed templates for us to choose from. When we create a new report based on the template, we'll get all the formatting and features from the template and can then proceed to modify the report as desired:


Happy coding!
Subscribe to:
Posts (Atom)
