New SQL Server Show Posted
SelectViews #105: Login Audits, Accidental DBA Quick Performance Checks, SQL Injection and Upcoming Events. Also, Find Out About Noise and News in the DB World and the 60-Second SQL Server Tip of the Day.
> Watch The Show
Featured Article(s)
New Data Source Controls in ASP.NET
ASP.NET 2.0 and beyond comes in with a bundle of new data source controls which you can use to implement CRUD (Create, Read, Update, and Delete) operations in your applications with the least amount of code. You can use these controls to declaratively bind data in your applications. You use the ObjectDataSource control to bind data to the data controls from generic business objects. The AccessDataSource, SQLDataSource, and XMLDataSource controls are used to bind data to the ASP.NET data controls from Access, SQL Server Database, or XML data sources, respectively. This article takes a quick look at the new data source controls introduced as part of ASP.NET. It also discusses how you can work with the controls to leverage their awesome power in your applications.
SQL Injection Version X
One of the things I’ve continuously been hearing of late as we work with different people that have fallen prey to the injection attacks happening is that they’re already filtering for words – filtering for INSERT, SELECT and other keywords associated with SQL statements. Since this is the case it’s not clear how information is getting injected into their installation of SQL Server, since it should prevent the access… right?
At first blush, sure. But, here at SSWUG, we capture these attempts and log them. Then we can go back and inspect them carefully on test databases and systems and see what’s going on. Of course we’ve been targeted as well in this onslaught of injection issues, only to be logged so we can see what’s being attempted. I think I’ve learned a few different things from what’s happening.
First, the reason the attacks are working well, before people can filter, is because they’re not sustained attempts. They come to the site, try a few things within a matter of a couple of seconds and are gone. Kind of hard/impossible to react to that in any human way. This means too that you’re less likely to see this in your logs – it’s only a couple of hits, then it’s gone. Hard to track.
Second, these are not what you may be thinking of for injection attacks. In fact, they’re quite different and the approach is "out there" compared to the more simple attacks where someone is trying commands. These appear to be passed for processing and then interpretation using an approach that CASTs a long binary string into a VARCHAR, then executes that variable. This gets around ALL Of those keyword checks you’ve been relying on so heavily.
I’m putting together an article on this so you can see specifics and what’s happening. I hope to have it live on the site early next week after I make certain that I can outline the oddities accurately.
On the one-hand, it’s fascinating. On the other, it’s sad.
Featured White Paper(s)
Optimizing your SQL Server Infrastructure: Good Ideas, Bad Ideas
In the first chapter of the eBook SQL Server Infrastructure Optimization, “Traditional Challenges and Their Impact,” the auth… (read more)
Data Deduplication and Disk-to-Disk Backup Systems: Technical Considerations
What You Need to Know—and Ask—Before Implementing a Data Deduplication Solution Author: Heidi Biggar, Analyst, Ent… (read more)