New SQL security finds web.config hole

Yesterday, I was reading the MSDN FLASH email newsletter and saw a listing for another SQL injection article. Since one of Wayne's sites was recently hacked, I thought I would read it. The article is clear and gives explicit steps to take. Since I had only done one of the three things (SQL stored procs), I thought I would mess with the last one: execute permissions only.

Wayne pointed me to a stored proc to grant permissions to a user. Since users and roles are one of those areas that after you have them set up correctly, you don't mess with them, I stumbled my way through creating a user. I ran the stored proc (which will have to be run after every .netTiers generation), modified my sql connection in web.config and tried my pet project site. I get an error about SELECT statements and permissions. .netTiers was supposed to be configured in web.config to use stored procs but apparently not. So I change the file, build, and still get the error. Someone, somewhere is caching something. Close everything done. Reopen. Change web.config and checkin with comment. Test again and it works.

This is a really bad way to find a problem. It's getting to the point that I need someone to check my security changes so this type of thing isn't missed.

Comments

Popular posts from this blog

Simple WP7 Mango App for Background Tasks, Toast, and Tiles: Code Explanation

Yet once more into the breech (of altered programming logic)

Error : /ScriptResource.axd : Invalid viewstate.