Public data breaches in one form or another are more prevalent than ever these days, so it’s important to use a variety of tactics to keep hackers at bay. While a database on your network or in your application is safe enough on its own, when you connect perfectly secure web interface to a perfectly secure database you can, unfortunately, create the perfect attack vector. Add in a little notoriety from an advertising campaign and instantly you are on the radar of script kiddies, hackers and an endless storm of botnet networks that scour the internet perpetually looking for an opportunity to steal your data.
The beauty of the SQL injection attack is that hackers are using the inherent functionality of the database against itself. Fundamentally, a successful SQL injection attack is basically the result of an unprotected or “un-sanitized” question being asked of a database. As it is the very nature of a database to allow for the querying or “asking of properly formatted questions” to retrieve data, SQL injection is little more than a database doing what it is was built to do. The problem with this method is that you can access data that is never intended to be returned, as well as access stored functionality in the database that was never intended to be used by an over-the-internet interface.
So, how do we fix it? Well, that is not so easy. If it were easy, we would just install a tool or a patch and move on, like we did with NIMDA, a quick-spreading computer worm released back in 2001. This is no NIMDA and the “fix” is multi facetted. First, it requires training and awareness of the DBA and Web team of the vulnerabilities that exist in database driven content served up over the internet. Second, it requires a professional environment where it is acceptable to ask for help and/or training so that an employee is not made to feel inferior for not having the complex issue resolved. Next, management needs to support their coders with a professional development infrastructure that fosters a solid and practical implementation of secure coding principles. If you are using third party or outsourced development teams, considerable care should be given to understanding which controls, frameworks and methodologies are in place to ensure you get functionality and security in your apps. Finally, test your applications for negative and positive results from perspectives outside of the basic, intended functionality. Peer and third party review of all “go-live” code should happen as a normal QA function, at every major and minor revision.
If you’re looking for a secure diver to help alleviate your vulnerabilities, try the Progress DataDirect ODBC and JDBC drivers, which can reinforce your security measures by enabling you to automatically encrypt your server communications and reduce the risk of SQL injection. Have more questions? Ask us at @DataDirect_News!
View all posts from Jared Green on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.