Author |
Topic |
december
Starting Member
5 Posts |
Posted - 2006-08-09 : 12:13:22
|
Hello,I came into work the other day to find out that someone had "hacked" into our websites via SQL injection. Well this is what I believe anyways because they added a new row in one of my tables which was a snippet of code that redirected my pages.How can I stop this from happening again? I believe they went threw a search bar I have. Besides erasing the search completely.thank you,d |
|
mwjdavidson
Aged Yak Warrior
735 Posts |
Posted - 2006-08-09 : 12:26:54
|
Restrict database access to parametised stored procs wherever possible.Mark |
|
|
december
Starting Member
5 Posts |
Posted - 2006-08-09 : 12:38:58
|
Could you dummy that down for me? SQL is one of my weak points. |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2006-08-09 : 12:51:49
|
http://weblogs.sqlteam.com/jeffs/archive/2006/07/21/10728.aspxGo with the flow & have fun! Else fight the flow blog thingie: http://weblogs.sqlteam.com/mladenp |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-09 : 15:04:28
|
quote: Originally posted by december Could you dummy that down for me? SQL is one of my weak points.
wow. You need to hire someone who knows what they are doing then. -ec |
|
|
december
Starting Member
5 Posts |
Posted - 2006-08-09 : 15:13:26
|
Im here trying to get some help. so please keep your stupid comments to yourself. |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-09 : 15:16:25
|
quote: Originally posted by december Im here trying to get some help. so please keep your stupid comments to yourself.
if SQL is your weak point, then you will have trouble securing your system. There is nothing I can do about that.Your best bet is to hire someone who is not weak at SQL in order to fix your problem.I find this to be excellent advice and I doubt anyone else on this forum will disagree with me.-ec |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-09 : 15:22:54
|
quote: Originally posted by mwjdavidson Restrict database access to parametised stored procs wherever possible.Mark
This means that all access to data is done through stored procedures that you pass arguments to. These arguments are parsed and things like '--' and single quotes are escaped so someone cannot easiliy inject their own code.google a bit and you will find ways to make your applicaiton more secure. Here is a link with some good info and examples http://www.unixwiz.net/techtips/sql-injection.html-ec |
|
|
Srinika
Master Smack Fu Yak Hacker
1378 Posts |
Posted - 2006-08-09 : 15:29:18
|
quote: Originally posted by december ..... keep your stupid comments to yourself.
december,U seems to have a good future and good attitude towards getting help. Srinika |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-09 : 15:33:46
|
quote: Originally posted by Srinika
quote: Originally posted by december ..... keep your stupid comments to yourself.
december,U seems to have a good future and good attitude towards getting help. Srinika
Maybe I was a little harsh in what I said, or maybe the tone was a little off.The main issue though is if your database was attacked in this way, then all of the data in your system is now comprimised. Hopefully december doesn't have SSNs or credit cards or medical records or something like that in the db.-ec |
|
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2006-08-09 : 16:31:01
|
quote: Originally posted by eyechart
quote: Originally posted by mwjdavidson Restrict database access to parametised stored procs wherever possible.Mark
This means that all access to data is done through stored procedures that you pass arguments to. These arguments are parsed and things like '--' and single quotes are escaped so someone cannot easiliy inject their own code.google a bit and you will find ways to make your applicaiton more secure. Here is a link with some good info and examples http://www.unixwiz.net/techtips/sql-injection.html
Actually .. you don't need stored procedures to use parameters, and parameters are not parsed or escaped.- Jeff |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-09 : 17:22:22
|
quote: Originally posted by jsmith8858Actually .. you don't need stored procedures to use parameters, and parameters are not parsed or escaped.- Jeff
right, I was trying to translate what was said earlier as was requested by the original poster. There are many ways to protect against SQL injection and using stored procedures that accept specific arguments and whose values are scrutinized prior to execution is one way. Checking the arguments that have been passed to your sproc and escaping out any single quotes is probably a pretty smart thing to do. Obviously, this is not handled automatically for you. You need to code things like this. -ec |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-09 : 17:25:21
|
this has probably been posted here before, but here is a demo of some sql injection techniques to gain access to a "secured" website. http://youtube.com/watch?v=MJNJjh4jORY-ec |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2006-08-09 : 17:28:43
|
December: sql injection isn't too hard to stop and there are a few simple things you can do. First of all make sure that all sql server special characters are replaced with their html equivalent (I assume this is a web app), like ', %, #. Also make sure that all you HTML form fields have tha MAXLENGTH property set (this can be hacked but makes it a little less easy). Both of these things needs to be done in your web-app *before* you send it to the database. And finally, as several others have suggested, never use inline sql in you web application. Wrap everything you do inside stored procedures and make sure that you use proper datatypes for all parameters. Making procedures for everything can be timeconsuming but it's worth it in the long run.Oh, and one other thing: make sure that the database user in the connection-string only has permissions in the database you are using, I'm praying that it's not a system administrator account (God forbid!).--Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2006-08-09 : 17:35:06
|
Awesome video btw!--Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
|
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2006-08-09 : 21:46:23
|
quote: Checking the arguments that have been passed to your sproc and escaping out any single quotes is probably a pretty smart thing to do. Obviously, this is not handled automatically for you. You need to code things like this.
Why do you need to escape single quotes for a parameter? Unless you are concatenating a big sql string and executing it directly, there is no reason to do this.- Jeff |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2006-08-09 : 23:33:35
|
quote: Originally posted by december Im here trying to get some help. so please keep your stupid comments to yourself.
Do you think calling people stupid will encourage them to help you?CODO ERGO SUM |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-08-10 : 01:56:40
|
quote: Originally posted by jsmith8858Why do you need to escape single quotes for a parameter? Unless you are concatenating a big sql string and executing it directly, there is no reason to do this.
ok. |
|
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2006-08-10 : 10:26:08
|
Sorry, i am not trying to troll or pick a fight, I just get frustrated when people don't really understand *why* SQL injection happens, like the guy who posted here a few weeks back who was making a list of all SQL keywords so that he could "protect" his code. Most SQL injection happens because people don't understand it, and they think it is a major effort to write their code in a way that prevents it, when it is actually amazingly easy.I have two blog posts about this (more or less):Use parameters: http://weblogs.sqlteam.com/jeffs/archive/2006/07/21/10728.aspxSQL Injectionable? http://weblogs.sqlteam.com/jeffs/archive/2006/04/21/9651.aspx- Jeff |
|
|
LoztInSpace
Aged Yak Warrior
940 Posts |
Posted - 2006-08-11 : 00:28:13
|
Nicely said jsmith8858 & eyechart.Without wishing to sound harsh on Lumbago, disregard his comments about replacing characters. You need never touch your data - just use the appropriate interfaces - i.e. bind your variables in prepared statements at the client end. If you find your self writing SQL = SQL + " and ID=" + myID STOP!As for eyechart's comments about getting someone who knows what they are doing - right on. I took my car to the mechanic the other day to get it serviced. He told me he knew all about paintwork and uphostery but when he said "that engine thingie and the mechanical stuff is one of my weak points" it made me think if I was talking to the right guy for the job..... |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2006-08-11 : 02:41:46
|
I have always used malicious character replacement as a method of protecting my app agains sql injection and I still belive that it works quite well. I have read numerous articles about it in the past and my apps have never been hacked. That doesn't mean that this is the only way and I agree that parameterising is better but I found it to be more of a hassle. I always use stored procedures with carefully chosen datatypes/lengths aswell so I belive I have been well protected.But since you are all preching about parameterising; can character replacement be hacked? I'm asking out of curiosity and not to be a smarta$$...'cause if it can I need to do some serious modifications --Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
|
|
Previous Page&nsp;
Next Page
|