The first thing to do is grill your vendor about the security of their product. Ask them if they have processes in their development team to check for opportunities for SQL injection. Ask them if they've had their application systematically tested using one of the many source code scanners. Ask them if they've had a third party validate their application, or if they've had a penetration test done. These same things could be used for an internal development team to ensure code and applications that end up being published to the Internet, or internally(!), are protected from attacks of this nature.
While there isn't much press for SQL injection on internal web applications, think about how damaging those could be? Is there a web-based database internally that, if compromised or published on the Internet, would lead to damage to your reputation or, even, compromise your clients accounts? Its worth checking to see if your internal apps have SQL injection issues too.
This link I ran across might be helpful for people running IIS. Even if you have apps that you have no control over, you may be able to prevent SQL Injection through tuning IIS. How IIS can help with SQL Injection
As a side note, I've also used software-based application firewalls, like eEye SecureIIS, to help protect applications running on IIS.
What have you done that's worked to prevent issues with your IIS-hosted applications?
Chris
LABrat.com
No comments:
Post a Comment