Amazon AWS, Azure, Editorials, Security, SQL Server

SQL Injection – More tools…

It’s incredible to me when you sit and watch the injection attempts against your public web properties.  I realize that most are bot-oriented attempts, that there aren’t people sitting at the other end of most of those connections (no one types that stuff in, give me a break)… but still, someone felt that was a better use of their time than writing the next killer app.

ANYWAY…

Make sure you’re looking up a bit from your work with things like SQL injection.  There are good, solid tools that can be used to leverage your time and energy to protect against these vulnerabilities.  I still believe that you need to check your code, have good practices in place and know exactly how information is being captured, processed, filtered, all of that.  Those are just good, common sense things (there are many resources on SSWUG.org about injection, including video and written materials).  

It’s incredibly important though to make sure you’re up to speed on the tools you have that are external to your systems.  These are things like firewalls, AI-based smarts that look for injection attacks and more.  

With Azure, there are threat detection tools that can recognize and attack and alert you.  Let you know what’s up and that you need to pay some attention.  This is incredibly important information to have coming to you, and can let you respond and block, respond and repair, whatever needs to be done.

Here’s a look at the threat detection technology

With AWS, you have options as well.  The most obvious is the use of the Web Application Firewall.  This lets you set up rules and Web ACLs that will protect your systems.  The great thing is that they block the request in the first place – not allowing the code to even touch your servers.  We have this in place, along with having enabled logging. 

Interestingly, our applications and the pages on the site are not the most attacked features, but rather functions of .NET and other things that have had vulnerabilities exploited in the wild before (not from us, from the general population of .NET sites).  So, the bots hit every site they can to see if they can exploit those.  I was surprised to see so many “legacy” injection attempts.  

Here’s a look at the Web Application Firewall

None of this is an advertisement for either solution.  The key here is that there are technologies beyond checking code, forms, inputs and storage processes.  It’s critical to keep on top of options, be aware of tools and be plugged into the new tools that come out as well.  

If you don’t, they’ll win.  They’ll work around your protections or find something you didn’t know was out there or find a new entry point or… It’s just a constant fight to make sure you have it covered to the best of your abilities.