Previous Visual Studio versions had the ability to make a box selection in text editors by holding the ALT key down while selecting with the mouse. More than once, I used this to select a column full of "public" modifiers on member variables, hoping that I could paste or type something which would replace what I'd selected on the whole column. Alas; it was not so! As a result, I generally never used block selection.

However, Visual Studio 2010 now does what I'd always hoped it would! From "What's New in the Visual Studio 2010 Editor (link)":

Box Selection

In previous releases of Visual Studio, you could select a rectangular region of text by holding down the Alt key while selecting a region with the mouse. You could then copy or delete the selected text. VS 2010 adds the following new capabilities to the box selection feature:

• Text insertion: Type into a box selection to insert the new text on every selected line.

• Paste: Paste the contents of one box selection into another.

• Zero-length boxes: Make a vertical selection zero characters wide to create a multi-line insertion point for new or copied text.

You can use these capabilities to rapidly operate on groups of statements, such as changing access modifiers, setting fields, or adding comments. For more information, see How to: Select and Change Text.

All I can say is; Woo hoo! Okay; so very small things entertain me.

PHP is not my first choice when creating a web application, but I am frequently called upon to work with an existing app that was created in it. I know that there is no reason to think that PHP coders are any 'worse' than any others overall, but the realities are such that when my creative/marketing agency clients had to find someone to create a web app for their clients before they knew me, they took what they could find.

So, first; I can't recall the last PHP app I've worked on after someone else which did not have obvious SQL Injection vulnerabilities in it. Pretty much every SQL command is built by concatenating strings, and if we're lucky, some attempt is made to escape some of the input, some of the time. I can not count on one hand the number of times in the last year I've been asked to fix an error in an app that was discovered when someone typed in a value that had a single-quote in it. I've also seen too many apps that set a simple sesson cookie value (such as a cookie "Admin" with the value "1") to denote that someone has logged in to the CMS.

I can understand how it happens that someone is lazy or ignorant, and things like the above happen. But something I came across last week flabbergasted me. So much that I had to wonder; is there something I'm not seeing here?

More...

Regionerate is an open-source add-in for Visual Studio which enables developers to easily apply code layout rules in C# source. I've been using it for a few months now, and have found it to be incredibly useful, with only two issues; one not really even worth mentioning, but the other could be a problem for some.

First, though; what it does! From the Regionerate Introduction page:

Regionerate is an automated tool which helps you to preserve your code's layout over time. Regionerate lets you define regions in your code and determine the way members (fields, methods, properties etc.) should be placed inside them.

Regionerate is a zero-friction tool - when setting up, you can choose a Code Layout (the way you want your code to look) or just use the default Code Layout. From that moment on, Regionerate will make sure your code follows that Code Layout.

So, I can get pretty aggravated by the most simple things!

I was doing some coding in Visual Studio 2008, and suddenly found that Intellisense was not working on the StreamReader object instance I was coding. I verified that I had declared the object correctly; It was a very small and simple bit of code which read a text file line-by-line. Not only that, the code compiled and worked.

When you frequently code in VS, the Intellisense popup can become like an old friend. It pops up and disappears constantly as you type code. Even when you don't need it to know what members an object has, its constant flicker lets you know you are doing OK.

This is the code I was working with:

More...

I have read, very conservatively speaking, at least 200 books about web-based programming frameworks and languages. I won't even try to put a number on how many web pages/sites I've read on the topics. Through that time, I've seen mentions of the basic difference between GET and POST requests as relates to web applications. As a side-note, a few comments are usually made concerning the security implications. Many of those brief remarks are, IMHO, not especially helpful. In essence, those remarks often boil down to, "GET is less secure because the data is visible on the query string". I say 'not especially helpful' here, rather than, 'patently incorrect' because one could make a somewhat convoluted case that what the authors are talking about sort of means the same thing I'm about to write about. But I think it's too clear that they mean the statement literally - that the fact that a user can 'see' the query string is the cause for concern, as opposed to the fact that POST data is not visible in a web browser.

More...

So, the other day I check into a small online community that has a small forum area where, among other things, people will sometimes discuss web development issues. While there, someone gave this bit of advice, to paraphrase:

Oh, as long as it's an application you programmed yourself, it's not really a big deal for you to have to take care of those old SQL Injection vulnerabilities. You can probably just let it wait until you upgrade the programming to a newer technology

I was a bit flabbergasted that someone would say such a thing, but it just so happens that I have, on hand, logs that prove that the assumption backing up that feeling of security is not at all based on reality.

Injection Bait

A little while ago, I set a client's database-driven web site to report errors to me generated as a result of attempts to exploit SQL Injection vulnerabilities. Normally, this sort of thing is "background Internet noise" that isn't terribly worth looking into - like 'port scans' on your home router. But I wanted to see what sorts of things were being tried. Also, since I had created all the code behind this site from the ground-up, I actually was curious how much I might see targeted SQL Injection attacks. The answer? Twice a week, average.

Of course, the WWW request logs contain lots of probing requests looking for certain popular web applications which have/have had SQL and other vulnerabilities. I swear I still occasionally catch sight of that now ages-old, telltale string of N's from Code Red in there, too... But these particular messages I was setting myself up to get were actual web application exceptions, caught when input fields have been tampered with to contain specially malformed values.

More...

Encryption is the art of making a message or other data safe for delivery over a medium where it may be intercepted by an unintended party. I say art because at least it often seems that way. It can be a very complex topic, made moreso by an often confusing array of (dis)information from mainstream media, technical media, software/hardware vendors, (quasi-)security experts, and white/gray/black hat crackers. I encourage developers who are attempting to understand encyption enough to implement systems which use it to read as much as they can on the topic, but with an extremely critical eye. I will attempt to share some information from my own experiences here, in a very small series of articles on the topic.

Today, I will cover some broad theory and general dos and don'ts. In the near future, I will share some more detailed information regarding actual implementation in code. Finally, I will share a library I developed for .NET developers to encapsulate some encryption code which does not always behave as one might intuitively expect.More...

In my day-to-day programming work, one of the most frequent - and least exciting - things I do is create data object classes. These classes use the data access layer code to interact with the persistent storage mechanism, and then present a nice, neat object-oriented package to the presentation layer for databinding and any other operations. Business rule logic can easily be created within these to enforce whatever must be enforced, again taking some of the weight off the presentation layer (whether Windows Forms or a Web Application).

However, it is quite, well, boring to create all that code. Fields in a data store must have matching representations created in private member variables and public property accessors. Functions for adding, updating and deleting records must be created, with the requisite creation of Parameter objects for each field at issue. Constructors to load new records, existing records, and collections of records must be created, again linking the data in the data store with the data in the object. It's a lot of 'plumbing' to do, and it creates a temptation to avoid using good, N-tier practices, and just access the data directly within the presentation layer code. You would never do that, would you? I used to consider it all the time, until I developed the original version of the DataClassBuilder.

More...

Continuing my series on the SANS/CWE list of 2009's Top 25 Most Dangerous Programming Errors (link), I will cover three of the errors that involve apparently well-intentioned behaviors on the part of programmers, which nevertheless can end up in disaster. Specifically, Use of a Broken or Risky Cryptographic Algorithm (link), Use of Insufficiently Random Values (link) and Client-Side Enforcement of Server-Side Security (link).

It is unfortunately fairly common that persons in many professions, certainly including I.T. related ones, will operate from assumptions which are only half-correct. Most I.T. workers will agree with the statement that "computer security is an important topic". But from there, ideas, training and opinions fly in many directions, and unfortunately many of those directions are dangerous. You may have heard the statement, "Security by Obscurity is No Security at All". Literally speaking, this statement is wholly untrue; The whole basis of a good password, for example, is extreme obscurity. The idea is that a password is something so obscure, that no one could possibly ever guess it. So obscure, in fact, that if you didn't know it yourself, you would not be able to guess it.

However, passwords are really the only place the statement fails in relation to security. Although security is often seen as an issue for Information Security (I.S.) teams and administrators, it starts with application developers. (hence this series in the first place). The problem is, many novice - and frightfully too many experienced - programmers will take serious shortcuts when building in security to their applications. Often, developers will believe they have found some truly obscure method to protect data that won't be able to be cracked, without realizing that the best encryption schemes, for example, actually are those which are fully known, and thereby are constantly and thoroughly tested. Other times, a developer will implement a security mechanism imperfectly, being unaware of what is important in the algorithm working to protect the data.

More...

A couple of days ago, I put up a post about the SANS/CWE list of 2009's Top 25 Most Dangerous Programming Errors, and noted I would cover some of the items individually.

Today, I will briefly cover a couple that are somewhat related, in regards to the title of this entry. What I hope to get across is this; When you release an application (desktop or Web/Intranet), a programmer must always remember that malicious users will get access to the client side code. As a result, they can - and will - exploit whatever holes have been left. My goal with this article is to add something to the 'blogosphere that describes why these issues are important for programmers to consider at all times. If you are not a programmer, and never intend to be, perhaps this will be rather boring! Heck - even if you are, it may still be boring.

So the items which apply here are; Improper Input Validation, Improper Encoding or Escaping of Output, Failure to Preserve SQL Query Structure (aka 'SQL Injection') and Error Message Information Leak. All of these errors create a gold mine for people who want to use your hard work for their own nefarious purposes. These are very common and easily-made errors by inexperienced programmers, especially because these errors can be made in relatively simple web site code, where less-experienced programmers might more often find themselves creating something that will be available to be accessed by those seeking 'low-hanging fruit' to exploit. A common misconception is, "I'm not exactly creating another Amazon.com or a national bank's online-banking system; Who is going to try to hack my web site?" The answer to that question; Anyone looking for a group of users to exploit, a web server to send e-mail spam from, or a free place to host illegal content.

More...