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, ...
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 (...
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 ...
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 ...
27
It's clearly wrong in the context of injection attacks - either your database layer is processing strings correctly or it doesn't. Since apostrophes are valid in names and free text, blocking them entirely will break the application, and blocking them selectively wouldn't fix the injection problems.
But strict input validation is good practice on general ...
21
I'm wondering if it is possible to detect 100% of the possible SQLi attacks using a simple regex.
The very fact that you're asking the question this way shows you're thinking about the problem incorrectly.
SQL injection is not a vulnerability in data. It's a vulnerability in application code that handles that data.
For example: right now I'm typing a "SQL ...
17
TL;DR No, your friend is not right. INSERT, UPDATE, DELETE and DROP TABLE aren't the be-all and end-all of SQL risks connected to SQL injection.
The very simplest thing I could do with that query is ask repeatedly for a user by the name of SLEEP(3600) (or john' OR SLEEP(3600)=') and, voila, denial of service (as soon as the available connection pool is ...
17
Step 1) Parameterize your SQL.
Step 2) Ensure you are using the SQL DB Connection library to set values for your parameters, not just setting them inline. This is the actual defense against SQL injection.
Step 3) Don't do query building in SQL. That way lies madness.
Step 4) add a config switch to propagate the error all the way back to the user. Turn it ...
12
Prepared statements (parameterized queries) are great just make sure you implement it correctly. I've seen "prepared statement" implementations that were every bit as vulnerable. For discussion of implementation details I recommend stack overflow.
Also nothing wrong with defense in depth (input validation in this case) but do it well...rejecting all ...
11
I'm not a security person. I'm a programmer who has to maintain secure code. This is what I call a "brittle" practice. Entry points are scattered all over a typical project. Finding and sanitizing all of them is a lot of work to address only a single problem, a lot of careful maintenance and hassle to ensure it remains effective as the code changes, and full ...
8
As you said yourself, if you're using parameterised queries, then the single quotes isn't a problem. In this case, you can reject their advice. If doing so, highlight the fact that you are using parameterised queries and that this aids usability as well (using your previous examples).
8
If you're 100% sure you always prevent SQL injection everywhere, this indeed is nonsense.
However, SQL injection is one of the most common security risks, and even if you're sure you've properly written your application to use parameters, a sloppy DBA might execute a query that's at risk for second-order SQL injection. It might not even be stored anywhere, ...
8
No. First of all, there are several evil things you can do with SQL injections which don't require the use of the SELECT keyword, like the infamous universal password ' OR '1' = '1 or the common username Robert'); DROP TABLE Students;--. Also, "select" is a very common word in the English language which might appear in completely benign ways in all kinds of ...
6
There are some details which I would have wanted for a better understanding, but I'm assuming that you are trying to send malicious SQLi in a search parameter.
Let me use an example that you are searching for the term 'shoes'
The web request for that might be: www.example.com/search.php?tag=shoes
The SQL query for that request might use LIKE. I have used ...
6
While I do not know the specifics of your application, I follow your argument.
There are fields which do not need to contain certain characters. With those fields, you could use input validation to filter single quotes (and double quotes, and whatever else).
If your escaping didn’t work correctly, input validation might be a mitigation strategy, but using ...
6
I assume that it is a MySQL database.
1749 (is greater that 0) and nQtm (valid alias - "variable name" for derived table) were chosen randomly by sqlmap. The problem with sleep(N) is that SQL database evaluates it to 0 and hence post=1 AND 0 will be evaluated to zero (FALSE : 1 AND 0 = 0) too. Value 1749 gets interpreted by SQL database as TRUE (similar ...
5
This looks like a simple scan for vulnerabilities.
The SQL UNION operator requires the second query to return the same number of columns as the first, so the attacker will iterate trying increasingly larger unions. If you look you probably have 48 hits counting up by one each time, not the same attempt with 48 columns multiple times.
If one of those ...
5
According to the MySQL documentation, MySQL requires at least one whitespace character after the double dash for it to be registered as a comment.
4
Still a threat? Of course! It's one of the most exploited vulnerabilities out there! Just take a look on the SQL Injection Wall of Shame and see for yourself.
I don't think SQL Injection will ever become extinct. It arises from the fact that humans are writing programs, and humans are not perfect. And as long as we write code, with the deadline arriving at ...
4
No, the error does not indicate SQL injection.
String or binary data would be truncated.
This means that the data you try to insert is too big for the column. If the column is of type CHAR(10), you can store 10 bytes in it. If you try to store 20 bytes in it, you get this error. This can happen even if the data is correctly handled and the page is not ...
4
The query in question probably looks something like this:
SELECT * FROM users WHERE user = '$user' AND pass = '$pass'
The $user and $pass variables are likely sanitized by either removing or escaping " and/or '. That's why a standard attack of ' or '1'='1 or similar is not working.
With your injection, you will get the following query:
SELECT * FROM ...
4
The database is stored on the server. This means that the server is the thing which gets directly harmed during successful SQL injection (there may be secondary effects on the client, but the server is harmed first).
Therefore, SQL injection is a server-side attack first and foremost.
4
It's not an SQL injection, and shouldn't be directly exploitable as one, since you've used a named parameter (:sendTo) instead of directly concatenating strings.
However, it is indeed exploitable, because an attacker can simply change the ID number and cause your server to spam other accounts with emails.
Also, cases like this one, where the client sends ...
4
If this is the result of a genuine Penetration Test, then they should be able to provide you with a value to submit that proves that this is an exploitable issue. If they cant then I would suggest asking for a proper penetration test, where they prove this is exploitable.
If however this is the result of a generic Vulnerability Scan then I would expect ...
4
Anonymity on a LAN is a bit of an odd question but here are some points to address which I feel may aid in your quest.
Firstly if you are on the LAN plugging in your laptop via an Ethernet port, I know where you are. Your physical being would easily be identifiable by anyone choosing to look.
For the sake of discussion let us assume a nice easy scenario, ...
4
The obvious risk is information disclosure e.g.
where 0=1 UNION ALL select secret_data from somewhere_else or a myriad of other ways.
Depending on server configuration, the same select may allow to (for example) access the filesystem e.g. union select "someinterestingcode" into outfile '/var/www/backdoor.php' or something like that.
Sanitizing arbitrary ...
4
In mysql you need a white space after comment marker. Just put one whitespace character after --.
select * from users where login='admin' -- now you can add comment
Generally add trash character after the whitespace against trim function. Like;
admin' -- xx
4
It would appear that they were primarily testing to see if you were vulnerable. The reason I say this is that the bottom three inputs don't actually reach out to any tables, and are purely testing whether they can get an input back from the server via an injection attack.
My guess is that they were targeting the information_schema schema in the top inputs ...
4
Quote Xenos
Can you find such exploit for MySQL? The USE syntax seems very "poor"
for such injection
Lets track down how USE works in MySQL and which files MySQL in the source code needs to access.
---
**Query #1**
SET PROFILING = 1;
There are no results to be displayed.
---
**Query #2**
USE test;
There are no results to be displayed.
-...
Only top voted, non community-wiki answers of a minimum length are eligible
