Archive for September, 2011
A mix of hospitality, camaraderie, and FREE SQL goodness all were the ingredients to this SQL Saturday.
Bolstered by the half dozen or so Colorado speakers this event was held in the small suburb of South Jordan at Neumont University. Presentations offered were SQL security, SSIS, SSAS, and more. A bonus for me was the code camp put on the lower level (which I happened to sneak down a couple times to catch between sessions).
One of the things about the SQL community that is so great is their willingness to share and welcome you with open arms. The speakers were generous with their time and even stayed after their presentations to help people with problems they were facing.
I also wasn’t too surprised at the number of people that told me that this was their first SQL event. This seems to be par for about every SQL Saturday I’ve gone to. But this is actually a good thing as I met a fellow Coloradoan last year at the Denver SQL Server Saturday. He was now a presenter at this SQL Saturday sharing his knowledge and giving back. That is awesome!
Another thing that bears mentioning is the sponsors (without whom none of this would be possible). I happened to listen in on a conversation with one of the sponsors of the event and realized that, yes, they are there to make a buck, but they also bring the community together with their willingness to take part in events like this. It was interesting to hear that they are seldom thanked by the attendees of SQL Saturday or the user groups they might be sponsoring. So next time you get free food or swag please thank the sponsors. They are people just like everyone else that would love to hear your appreciation (even if you don’t buy their product).
Outside of all the excellent speakers and SQL knowledge being shared the after-party really summed up what the Salt Lake City SQL Saturday was all about. Community. Tjay Belt (website | twitter) and Randy Knight (website | twitter) staked out and dished out an excellent spread up in the Uinta National Forest (15-20 min drive from the event).
I think this ended up being a very wise choice in venue as there was zero cell coverage and people weren’t checking twitter every 2 minutes (I would’ve been guilty of this had I had service too).
Life just doesn’t get any better than sitting around a campfire talking about SQL Server, life, and getting to know each other. This was a great bonding experience even for us from Colorado who already knew each other.
So a HUGE thank you again for anyone that reads this that helped put on SQL Saturday #94. I am a SQL Saturday addict, and because of events like these it is no surprise why.
Share and Enjoy
So I recently inherited some additional sites to manage. Unfortunately some of them were running Classic ASP via IIS5 with a back-end Access (aaargh!) database.
Still, I really wasn’t too concerned about anything other than the age of the server and software. After searching Secunia there’s only one known vulnerability (hack to bypass logging).
But, since this was inherited code I’d better follow up with some due diligence so I fired up Acunetix (there’s a free version too) and ran a scan against all forms on the new sites.
Immediately during my scanning multiple cross-site scripting alerts went up. After a quick stroll through the database I found script tags the security tool had injected into the database.
Busting out Notepad++ I started going through the code and I start discovering stuff like this (and I’m spit-balling here):
Sql = “INSERT INTO tblForms (name, address, phone) VALUES (‘”+var1+”,”+var2+”,”+var3+”‘)”;
With Var1, Var2, and Var3 having no sanitation whatsoever!
Not even a Server.HtmlEncode call on the variables (converting the script tags to HTML entities in an attempt to be safer).
The SQL injection potential was obvious by the code as well.
So I dusted off my old ASP reference and (of course) added the proper sanitation.
But that raised the question: “Why is this a recurring theme with web-based forms?”
It was obvious whomever made this had no clue how to clean the data going to the back-end, or that it was even a concern. Couple this with the common theme of “it’s just a form, you can throw it together in 5 min” and it’s a recipe for trouble evidenced by all the SQL Injection hacks of late.
So here’s my advice (for what it’s worth):
- Wash your forms. Give them a 3 look rule, try to break them, see if you can dump garbage in them.
- Do regular security audits on forms (especially ones you change or inherit)
- Sanitize in the database too (for example: use type-safe parameters instead of a dynamic SQL string).
- Monitor your server. This is actually your best defense against known (or unknown) attacks.
- Last of all don’t let users pressure you into whipping forms out in 5 minutes (unless you’re really sure of what you’re doing).
Share and Enjoy