SQL injection
- Thread starter brainusa
- Start date
DeltaMac
Tech
Here's a synopsis, which looks fairly detailed:
http://www.veracode.com/security/sql-injection
Wiki page:
http://en.wikipedia.org/wiki/SQL_injection
And, a good list of items to "fix" in your own SQL apps, that can help prevent injection: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
http://www.veracode.com/security/sql-injection
Wiki page:
http://en.wikipedia.org/wiki/SQL_injection
And, a good list of items to "fix" in your own SQL apps, that can help prevent injection: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
ElDiabloConCaca
U.S.D.A. Prime
To expany on DeltaMac's good answer with links, yes, SQL injection can be extremely dangerous. It all depends on how important the data in the database is to you, and what possible damage a hacker could do given unfettered access to the data in the database.
You can secure your database a couple of different ways -- for best security, use all of the below:
1) From whatever app is accessing the database, have that app connect with credentials that give that user just enough access to do what they need. In other words, you need to go back and re-take "Databases 101" if you use the root user account to execute all your queries on the server. An example would be a simple login from a web page that bounces against a database to check the login credentials. In this case, you're only READING from the database (not INSERTING or REPLACING), so using a SQL user account that has both read and write access would be quite foolish.
2) Sanitize all your SQL inputs. This means -- don't just take information from a form (or other user-inputs) and simply pass that into the server. ALWAYS check and sanitize the inputs. 90% of your code should be error-checking. If it's not, you need to scrap that code and start again. If you inherited the code, you need to immediately bring this to the attention of the lead developer and/or boss-man.
3) Use normal forms when designing your databases. The higher the normal form, the better (as a rule of thumb). If you don't know what a normal form is for a database, you need to learn, in-depth, what each level of normal forms encompasses before you start designing or querying against a database. You need to know atomicity, non-prime attributes, keys and foreign keys at the very minimum.
Of course, this all depends on what type of data you're working with. If you're making a database to store your wife's recipes, then security, scalability and conformity may not be of the utmost importance. If you're working on a database of user credentials to a financial institution, however, you need to know exactly what you're doing before doing anything.
Where, precisely, are you on the scale from "recipes" to "securely storing credit card information?" That may give us a better idea of what kind of knowledge you need before you proceed.
You can secure your database a couple of different ways -- for best security, use all of the below:
1) From whatever app is accessing the database, have that app connect with credentials that give that user just enough access to do what they need. In other words, you need to go back and re-take "Databases 101" if you use the root user account to execute all your queries on the server. An example would be a simple login from a web page that bounces against a database to check the login credentials. In this case, you're only READING from the database (not INSERTING or REPLACING), so using a SQL user account that has both read and write access would be quite foolish.
2) Sanitize all your SQL inputs. This means -- don't just take information from a form (or other user-inputs) and simply pass that into the server. ALWAYS check and sanitize the inputs. 90% of your code should be error-checking. If it's not, you need to scrap that code and start again. If you inherited the code, you need to immediately bring this to the attention of the lead developer and/or boss-man.
3) Use normal forms when designing your databases. The higher the normal form, the better (as a rule of thumb). If you don't know what a normal form is for a database, you need to learn, in-depth, what each level of normal forms encompasses before you start designing or querying against a database. You need to know atomicity, non-prime attributes, keys and foreign keys at the very minimum.
Of course, this all depends on what type of data you're working with. If you're making a database to store your wife's recipes, then security, scalability and conformity may not be of the utmost importance. If you're working on a database of user credentials to a financial institution, however, you need to know exactly what you're doing before doing anything.
Where, precisely, are you on the scale from "recipes" to "securely storing credit card information?" That may give us a better idea of what kind of knowledge you need before you proceed.