re: Motorola Woes and the MPX220
That's good. Meanwhile I'm stuck with a hands-free kit that won't work with my MPX220 and they failed to do ANYTHING about it after repeated calls and messages.
« July 2005 | Main | September 2005 »
I just spent about 37 hours downloading the August Visual Studio 2005 CTP. It installed quickly and without issue. That’s a big step forward. It has one little, miniscule, tiny, insignificant bug though. The backspace key does not work. That’s not a problem though. I never make typing misteks.
Update:
Ok, I isolated this problem. If I select a word in the code editor and press backspace the word is removed but the backspace key is inop. The other keys work fine and if I reposition to another character, backspace comes back to life. It seems the IDE is still haunted. I tried this on an empty code page and it was even stranger… try it yourself.
August 5, 2005 • Vol.27 Issue 31
Page(s) 23 in print issue
I am still working on the next Hitchhiker’s Guide, so I thought I’d share a bit of the “Building Commands” chapter. Another motivation to focus on the Command object again (I visited it this time last year) is the alarming number of developers who are still rolling their own ad hoc queries. That is, they’re using concatenated queriesinserting parameters into the WHERE clause (and other unmentionable places). This practice makes it far easier to inject nasty SQL in places where it ought not be.
Preventing SQL Injection Attacks
I’m not going to give you the sequence of characters used to inject destructive or simply intrusive SQL into your queries. Suffice it to say that SQL injection is a very widely practiced and (sadly) a widely published technique that permits hackers to gain full access to your server and do what they will. There are several ways to protect your database, your company, and your career. All of these are fairly easy to implement, but let’s discuss some broader security guidelines that reduce the security risk frontal area of your server.
All data is guilty until proven innocent. OK, this sounds a bit paranoid and rings of a Homeland Security tactic, but that’s where the industry has evolved. As a rule of thumb, never permit unvalidated data from entering the system in the first place. Knowing where the data comes from is not enough. Hacking can result from human input or spurious data introduced by a “trusted” program that has perhaps been hacked. Remember that over 80% of all security breaches are from inside your firewallfrom your co-workers and those interlopers who have gained access to idle systems inside your buildings.
Avoid ad hoc or system-generated “dynamic” SQL either in your application or in a stored procedure. Concatenated SQL is the first route a SQL injection attacker will attempt; it’s the ground-level bedroom window left open to catch the summer breeze. These hacking attempts can be made as you capture a login ID or the “Product Wanted” search argument.
Always use a Command object in ADO classic or ADO.NET to manage SQL queries that accept input parameters from “untrusted” sources. Remember that ADO handles a litany of issues for you and makes it very difficult to inject anything untoward into the SQL that runs on the server.
Practice “least privilege” security. Set up specific accounts for your applications and users that grant only the specific rights they need. Given the credentials you’re using (those provided by the Windows login account, IIS, or those hard-coded in the application), hackers running injected SQL with those rights can’t do any damage or extract protected data. Don’t put all of your data eggs in one basket. Don’t create a single application login that has broad rights; remember to provide just enough rights to get the job done.
Use encryption for all sensitive data. Make sure that credit card numbers, social security numbers, or other private data is encrypted in place. Enable the SSL option in SQL Server to prevent hacking data feeds. Of course, enabling SSL won’t help if the server is not configured to support encryption.
Don’t depend on filtering algorithms that attempt to ferret out those keywords known to trigger SQL injection. Although this might work in some cases, they’re vulnerable to the seemingly infinite patience of hackers to figure out ways to bypass the filters.
Don’t reveal the secrets of your inner sanctum by dumping your exception messages to the user. The user is the person least able to fix the problem; a hacker is the person most likely to compromise your system with the inside information revealed by an Exception.ToString dump.
A tip: In your ASP.NET application, when an unhandled exception is generated, make sure only minimal help is offered to the hacker by setting the Debug attribute of the Compilation element (in the Web.config file) to false and setting the mode attribute of the CustomErrors element to On or Remote-Only. For example:
debug="false" The RemoteOnly setting ensures that users accessing the site from Localhost will get informative error messages, while those accessing the site from a remote location will receive generic error messages that reveal no useful information about the exception. Use the On setting to have all users, including local users, see the generic error messages. Never use the Off setting in a production environment.