Textbook security
-
:~ This morning I found a piece of code
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
The software had passed a big security check earlier last year... Shall I cry and get burned, silence and chuckle.
Talk to your boss. If that POS got through a security audit then the whole audit is flawed and there may be much worse stuff in there. Presumably, you hold security checks for a reason - that you need to be at least reasonably secure - but someone has not done their job at all well, and needs "education" on his or her role in the company. Or a P45.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
Pascal Ganaye wrote:
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
Just request the testing team to type
1;drop table USERin the textbox and watch all the fun. :-DWP Apps - Color Search | Arctic | XKCD | Sound Meter | Speed Dial
If it's SQL Server, this might even be better:
EXEC sp_MSforeachtable @command1 = "DROP TABLE ?"
Which drops ALL tables :-) (PS: found it on a quick google and have no desire to test this...)
-
Talk to your boss. If that POS got through a security audit then the whole audit is flawed and there may be much worse stuff in there. Presumably, you hold security checks for a reason - that you need to be at least reasonably secure - but someone has not done their job at all well, and needs "education" on his or her role in the company. Or a P45.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
You're all right. I made an email to management.
-
:~ This morning I found a piece of code
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
The software had passed a big security check earlier last year... Shall I cry and get burned, silence and chuckle.
If that's anywhere where a malicious user can get at it, i.e. a public system or a system available to all employees, then imo it's serious enough that you should raise it even if it causes some significant inconvenience for you to go through the process. Not only is it a huge data security hole in the application, but it shows significant failings on the part of the security auditors. If they were external you might even have a good case for getting some money back on the basis that they didn't do the job you paid them for, and if they were internal then they clearly need discipline and/or training for not doing their job to a professional standard. There's bad code everywhere which is amusing to look at and that's fine. But when it goes to the level of SQL injection vulnerabilities then someone needs to fix it and make sure it doesn't happen again.
-
:~ This morning I found a piece of code
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
The software had passed a big security check earlier last year... Shall I cry and get burned, silence and chuckle.
-
When I saw this post, I was looking for that very XKCD you beat me! :)
-
:~ This morning I found a piece of code
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
The software had passed a big security check earlier last year... Shall I cry and get burned, silence and chuckle.
OK so this is very wrong in every sense BUT: this SQL wont work if you look closely! you have a double quote at the end of the textbox (\") and not at the start, just a random '/' this will never work. (or are you making this up for a troll response)? alternativly, the last quote is fake or left because you doctored the SQL for us mere mortals, and potentially your after a number only. so "SELECT * FROM USER WHERE USER="+textBox1.Text; this is for only a number (as any string will make the SQL fail) so only a number will work, and the textbox will have to have been validated to only accept a number and therefore you wont have a problem as you cant SQL inject with only a number! i recon you are either trolling, or have not looked close at this, as if you even had 1 char in this SQL it will fall over. You my friend are a FAIL.... sorry! (P.S.... never ever write SQL's like this...)
-
OK so this is very wrong in every sense BUT: this SQL wont work if you look closely! you have a double quote at the end of the textbox (\") and not at the start, just a random '/' this will never work. (or are you making this up for a troll response)? alternativly, the last quote is fake or left because you doctored the SQL for us mere mortals, and potentially your after a number only. so "SELECT * FROM USER WHERE USER="+textBox1.Text; this is for only a number (as any string will make the SQL fail) so only a number will work, and the textbox will have to have been validated to only accept a number and therefore you wont have a problem as you cant SQL inject with only a number! i recon you are either trolling, or have not looked close at this, as if you even had 1 char in this SQL it will fall over. You my friend are a FAIL.... sorry! (P.S.... never ever write SQL's like this...)
Also User is a keyword in SQL, so you can't just select * from User, you have to select * from [User] (World, please stop naming tables with reserved words)
-
Also User is a keyword in SQL, so you can't just select * from User, you have to select * from [User] (World, please stop naming tables with reserved words)
Good spot, i didnt even pick up on that (My Fail)... (would have needed a 'dbo.' too.)!
-
:~ This morning I found a piece of code
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
The software had passed a big security check earlier last year... Shall I cry and get burned, silence and chuckle.
Well that was last year, or hasn't been modified until now?
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
:~ This morning I found a piece of code
sql = "SELECT * FROM USER WHERE USER=\"+textBox1.Text+"\"";
The software had passed a big security check earlier last year... Shall I cry and get burned, silence and chuckle.
