- Joined
- Aug 25, 2001
- Location
- Ontario, Canada
Database abstraction, frameworks, and many other things will attempt to solve this problem, relying on them for all of your security is a poor decision. The best solution is whitelisting input (so that it only hits the SQL statement if it exactly matches what you whitelisted), otherwise, regular expression matching to ensure that what you are getting is what you expect to get. There's a pretty good slide deck here about it:
http://www.slideshare.net/billkarwin/sql-injection-myths-and-fallacies
It's best to assume that, at some point in its life, someone will try to attack any application. Building an accurate risk profile is impossible because I don't have any information to go on.. if it's a company with 10 people making pretzels, it's going to be very different than a Fortune 500 defense contractor. Needless to say, lots of options:
* A security guy, like me, doing a vulnerability assessment, for audit, compliance, or security lifecycle purposes
* Any employee, who decides that "security is so bad" or "they are so skilled" that they can hack anything they choose, and that's the first thing they see. Yes, they'll get repremanded if caught, but that won't stop them.
* A disgruntled employee, for any reason, really
* A contractor who's getting money on the side by selling the company directory to a headhunter
* That guy with the laptop in his car in the parking lot who broke into your wifi, who's looking to social engineer his way into the building, by adding his name to the employee list
* The botnet owner, who managed to infect one of the company laptops, and is connecting through it to post a message on the front page instructing all employees to install the virus.
* An attacker who has managed to get into the network by hacking a DMZ server. This is a juicy target, because it's likely that a lot of people use the same "work" password for their Intranet login and corporate domain login. Getting domain credentials from a custom-built intranet site is typically going to be way easier than getting it from the domain controllers.
* You get the idea...
http://www.slideshare.net/billkarwin/sql-injection-myths-and-fallacies
It's best to assume that, at some point in its life, someone will try to attack any application. Building an accurate risk profile is impossible because I don't have any information to go on.. if it's a company with 10 people making pretzels, it's going to be very different than a Fortune 500 defense contractor. Needless to say, lots of options:
* A security guy, like me, doing a vulnerability assessment, for audit, compliance, or security lifecycle purposes
* Any employee, who decides that "security is so bad" or "they are so skilled" that they can hack anything they choose, and that's the first thing they see. Yes, they'll get repremanded if caught, but that won't stop them.
* A disgruntled employee, for any reason, really
* A contractor who's getting money on the side by selling the company directory to a headhunter
* That guy with the laptop in his car in the parking lot who broke into your wifi, who's looking to social engineer his way into the building, by adding his name to the employee list
* The botnet owner, who managed to infect one of the company laptops, and is connecting through it to post a message on the front page instructing all employees to install the virus.
* An attacker who has managed to get into the network by hacking a DMZ server. This is a juicy target, because it's likely that a lot of people use the same "work" password for their Intranet login and corporate domain login. Getting domain credentials from a custom-built intranet site is typically going to be way easier than getting it from the domain controllers.
* You get the idea...