904
The way I demonstrate it to complete non-techies is with a simple analogy.
Imagine you're a robot in a warehouse full of boxes. Your job is to fetch a box from somewhere in the warehouse, and put it on the conveyor belt. Robots need to be told what to do, so your programmer has given you a set of instructions on a paper form, which people can fill out and ...
452
There is no general fix for SQLi because there is no fix for human stupidity. There are established techniques which are easy to use and which fix the problems (especially parameter binding) but one still has to use these techniques. And many developers are simply not aware of security problems. Most care that the application works at all and don't care ...
322
You should implement input validation as a defense-in-depth method. So input validation should not be your primary defense against SQL injection, that should be prepared statements. As an additional defense you should restrict the allowed inputs.
This should never ever restrict functionality. If there is a legitimate use case to have apostrophes in input, ...
272
Because it's not a problem.
When was the last time a company with a SQL injection vulnerability got hauled up in court, and slapped with a big fine for being reckless with user data, and the directors' warned, fined or locked up for negligence?
When was the last time a company lost a big contract because their company website login page didn't validate ...
178
Here's an idea for an analogy that I think is fairly accurate while generally understandable:
A bank requires two forms of ID to get a loan: a driver's license and a birth certificate. Bank employees Alice and Bob are lazy in different ways: Alice always stamps "driver's license verified" without checking, while Bob always stamps "birth certificate ...
168
Keyword filtering for SQLi is not a good technique. There are too many ways to bypass it.
Crazy things like sel/**/ect might work, for instance. Or playing games with substr(). And then there's EXEC('SEL' + 'ECT 1').
There are many guides on how to bypass common filtering techniques.
But then you might ask if there is a superset of things to filter for (...
118
No. Removing spaces would not prevent SQL injection, as there are many other ways to make the parser process your input. Lets look at an example. Imagine that you had a url which used user supplied input unsafely in a query:
http://example/index.php?id=1 => SELECT * from page where id = 1
In your example the attacker would use spaces:
http://example/index....
117
SQL injection is still around because the software world still doesn't understand that programmatic generation of tree-structured values (like queries or markup) should be done by constructing syntax trees as first-class objects, not by concatenating strings that represent fragments of a language.
There has been a bit of progress in recent years with the ...
107
No. You might be confusing SQL injection with data injection; read-only tables do not prevent SQL injection and at best do only a little to limit its impact.
SQL injection simply means the ability to inject SQL code. While read-only tables may limit the ability to inject data into the table, they don't impact the ability to:
Read from other databases or ...
106
NO
Since every SQL injection is (by definition) valid SQL and since SQL is a context-free language (source), there is (again, by definition) no regex capable of matching an SQL injection, and trying to do so would probably give result similar to this.
As said by pretty much every comment, use the right tool for the job. In this case it's a prepared ...
90
One of the easiest ways to illustrate the problem behind SQL-injection is to use an image like this. The problem is the receiving ends ability to seperate data from command.
90
Without context, I'm going to presume that the author is referring to input fields in a client application. The easiest example to use would be a form in an HTML page in a web application, though what I'm about to describe is effective for virtually any type of client application.
Given this context, the answer is no, there is no maximum input field length ...
86
No, there is no length that is too short to be exploitable (at least in some situations).
A length-filter is not a valid protection against SQL injection, and prepared statements really are the only proper defense.
A length filter is however a good measure as defense in depth (as are integer filters, alphanum filters, etc). There are many situations where ...
83
This is the result of someone trying to exploit an SQL injection on your site. Someone tried to detect if your website was vulnerable to a union-based injection. For all the records that you see, it doesn't seem to have worked.
You should check your access and error-logs for the affected timespan to see if any further requests were made.
One suspicious ...
80
Don't spend lots of time on workarounds or half fixes. Every minute you spend trying to implement anything suggested here is a minute you could have spent implementing prepared statements. That is the only true solution.
If you have an SQLi vulnerability, the attacker will probably win in the end no matter what you do to try to slow her down. So be aware ...
74
You can make a UNION SELECT here. The only problem is to match the columns from messages, but you can guess those by adding columns until it fits:
SELECT * FROM messages WHERE unread = 1 LIMIT
1 UNION SELECT mail,password,1,1,1 FROM users
Just keep adding ,1 until you get the correct column count. Also, you need to match the column type. Try null ...
65
The only correct way is to use prepared statements.
If you disguise error messages, it a bit harder, but won't stop attackers.
You can restrict the rights, but all rights granted to the user could gained by the attacker. It is also possible to execute shell commands from an SQL-Injection in some cases.
Renaming tables won't help you. The tool sqlmap will ...
63
Here's a real-world non-technical analogy.
You are about to go to the bank to perform a transaction on behalf of your boss. Your boss gave you an envelope with instructions for the cashier.
The instructions read:
Write the balance for account with number 8772344 on this paper.
Signed,
Boss
You leave the envelope out of your sight for a few minutes while ...
63
This is most likely a blind SQL injection, testing whether you're vulnerable to SQL Injection by checking whether your server takes the specified time or more to reply to the request. This is not actually doing any data edit nor exposing anything; it's just checking whether you're vulnerable.
It's also worth noting that this specifically targets MySQL ...
59
One explanation I haven't seen here is that many financial institutions are tightly integrated with older systems and are bound to the limitations of those systems.
The irony of this is that I have seen systems that were built to be compatible to older systems but now the older systems are gone and the policy still must exist for compatibility with the ...
56
From the documentation:
From a -- sequence to the end of the line. In MySQL, the -- (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.8.2.4, “'--' as the ...
56
Technically, this is completely possible (though doing so also renders the database useless):
.+ Will indeed detect any possible SQLi.
However, it will also detect any attempt to do normal queries(or any text at all), rendering the database completely useless.
You could equally say that turning the database off protects from SQLi. It's true, but it also ...
55
When testing, it is very easy to test for what you expect to happen. For example, when filling in a "name" field in a database you will probably choose something you are familiar with, like "John Doe". This works, and your application seems to work fine.
Then, one day, someone names their child Robert'); DROP TABLE Students; -- (little Bobby Tables).
Of ...
52
Think about it this way
On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. If ...
51
There are a number of ways of testing an application for vulnerabilities such as SQL Injection. The tests break down into three different methodologies:
Blind Injection:
MySQL example:
http://localhost/test.php?id=sleep(30)
If this SQL statement is interpreted by the database then it will take 30 seconds for the page to load.
Error Messages:
http://...
49
Guarantee of 100% safe from SQL injection? Not going to get it (from me).
In principle, your database (or library in your language that is interacting with the db) could implement prepared statements with bound parameters in an unsafe way susceptible to some sort of advanced attack, say exploiting buffer overflows or having null-terminating characters in ...
48
We're in 2016! SQL injections are a thing of the past unless you use insecure code.
Whatever language you use, if you want to prevent any and all SQL injections, use prepared statements or any other type of data binding.
Prepared statements separate the query from the data, making it impossible for the data to affect the query.
To directly answer your ...
47
End users should never get to see the gory details of your environment.
Instead it is more professional to show a generic 'Sorry something went wrong' page. At least visitors can see that you have a real error handling mechanism present on your website.
However those errors should be written to the mysql error log and should also trigger a notification by ...
47
Do you trust all of your authenticated users completely? Including that they won't have their accounts compromised by attackers? It's bad if an attacker gets access to an account, but far worse if they can then leverage that to steal the rest of your database.
For your second point, the example you've used would not be vulnerable. However, take care with ...
43
If you're really explaining to your grandmother, use writing a paper check as an example. (In the USA) back in the day, you'd write the dollar amount numerically in one field, then you'd write the same thing in words. For example in one field, you'd write "100.00" and in the second, longer field, you'd write "One hundred dollars and zero cents". If you ...
Only top voted, non community-wiki answers of a minimum length are eligible
