321
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, ...
167
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
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 ...
10
Problems should be addressed at the root and not (insufficiently) taped over.
The root of the problem in your case (SQL injection) is that unexpected and unverified user input can be injected as SQL instructions into your SQL statements. This is due to concatenating strings with SQL instructions together with untrusted user input and treating the result as ...
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 ...
7
You've misread the injection, specifically this part:
""=""
This isn't checking if the Name is an equal sign, but rather if an empty string is equal to an empty string. It's effectively the same thing as 1=1 (and they could have used 1=1 just as well here), and is therefore the equivalent of TRUE. So this clause:
Name = "" OR ""=""
Is the same as Name="...
7
Restricted user accounts
Sanitizing such a query securely may be very, very hard and you should expect that you might have failed in some way which allows the users to execute arbitrary sql.
A possible mitigation for this would be severely restricted user accounts - you need to ensure that the connection under which these queries are executed is run under ...
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
This is a pretty basic scan attack that can determine a couple of things on your system without much effort.
Is your system running MySQL
Will your system parse the SQL statement and return a value.
If your server responds appropriately to the command, the attacker knows that they can manipulate your database and potential exploit your system. Uh oh.
The ...
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.
-...
4
In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record."
So, the attacker's own password thing is unlikely. There are technical defences that could stop it, such as deterministic "salt" (instead of hashing just the password, ...
3
Consider this query:
SELECT * FROM users WHERE username='$username' AND password='$password';
Assume single qoutes are escaped, but the escape character \ is not. Then, use user\ as username and an SQL expression (OR 1=1 --) as password:
SELECT * FROM users WHERE username='user\' AND password=' OR 1=1 -- ';
Now, the database searches for a user with the ...
Only top voted, non community-wiki answers of a minimum length are eligible
