91
The last dash basically protects the trailing space. If you exploit SQL injection in a browser (e.g. via the URL), some browsers remove trailing space characters. Some prominent SQL flavors explicitly require the Space after Dash-Dash to treat the sequence as the start of a comment, so attackers often add a character after the Space to protect it against ...
67
The problem of SQL injection is essentially the mixing of logic and data, where what should be data is treated as logic. Prepared statements and parameterized queries actually solve this issue at the source by completely separating logic from data, so injection becomes nearly impossible. The string escape function doesn't actually solve the problem, but it ...
25
I think the main question here is why string escaping is not as good as the other methods.
The answer is that some edge cases allow injections to slip through even though they are escaped. Stack Overflow has several examples here.
14
While you can stay safe protecting against SQLi escaping user input, it's important to note that it may not always be enough. In this terrible example, quotes are never needed to perform a successful SQL Injection, despite the escape:
<?php
/*
This is an example of bad practice due to several reasons.
This code shall never be used in production.
*/
$...
10
Because you're doing the same amount of work for better security
A common trope mentioned against PHP is mysqli_real_escape_string() (look at how long it is! Can't they be consistent with nomenclature?), but most people don't realize that the PHP API is merely calling the MySQL API. And what is it doing?
This function creates a legal SQL string for use in ...
8
One good reason not to use mysql_real_escape_string: it is deprecated
mysql_real_escape_string
(PHP 4 >= 4.3.0, PHP 5)
mysql_real_escape_string — Escapes special characters in a string for
use in an SQL statement
Warning
This extension was deprecated in PHP 5.5.0, and it was removed in PHP
7.0.0. Instead, the MySQLi or PDO_MySQL ...
6
Some good answers already, and I going to provide a few further clarifications:
Escaping
mysql_real_escape_string can be used securely. The advice with escaping is that you use the escaping function suitable for your database. You need a slightly different function for each database. Most of the subtle security problems come from people using their own ...
6
Nothing is ever impossible.
But SQL injection vulnerabilities have gone down with ORMs and query builders which prevent the most common mistakes. In my experience, applications which use a secure(ish) by default template engine also have fewer XSS issues.
But the main problems are:
Input sanitation will never solve all issues as you can't sanitize the ...
4
This isn't even remotely close to safe. There are any number of gotchas:
As pointed out by Anders in a comment, this can be easily bypassed by injecting in \'. This works because it escapes your backslash, turning it into a literal backslash and causing the single quote to become unescaped. Moreover, this is actually a very common thing to attempt ...
4
This can be both, but the main responsibility for such problems is design.
Independent on design, if developer is not forced to create a code that is vulnerable to SQL injection, but still creates it, it is an implementation problem. It means, developer either does not understand the problem, or understand but doesn't want to create a code that is resistant ...
3
An additional, non-InfoSec argument, is that parameters potentially allow for faster queries and less memory usage.
Using parameters, the data and query are separate, which especially matters when inserting very large strings and binary fields (the entire string needs to get processed by the escape function (which extends it and might require the entire ...
3
The issue with the biometrics is that the data being generated depends heavily on the sensor used to capture the data. I have biometrics recorded on my iPhone, my Android and my bank. As all three uses different sensors, the data they all have on record is wildly different.
Even if someone steals the data from one of my phones, that data cannot be used to ...
3
You will not be able to do much without one of the two:
change code
export the entire site in HTML
SQL Injection usually cannot be prevented on old code unless you rewrite it. Yes, there are WAF (Web Application Firewall) around, and they can mitigate the majority of the attacks, but if something escapes the WAF, the site is fully exposed.
Migrating to a ...
3
Injections like SQL injection, XSS, etc are possible due to the possible combination of code and data within the same string and because developers construct such strings using untrusted and insufficiently validated user input.
The possibility to mix code and data inside the same string is deep in the design of SQL, HTML+Javascript, ... This is similar to ...
3
Yes, your filtering on userinput2 is insufficient, the use of a single quote is not necessary for exploitation with that syntax. I didn't analyse the code any further. "Blacklisting" characters is not a reliable defense against SQL injection. You should alter the code to use parameterized queries instead.
3
You can use any expression that evaluates to true, it doesn't have to be 1=1, I don't think SQL contains a literal value for true according to this.
1=1 is the easiest for me to write and I got used to it.
3
It's just a simple string used to test the SQL statement. There's no requirement to use 1=1 exactly. Like you say 5>3 would work in the exact same way.
Unfortunately 1=1 is so common that it triggers protection code. Weakly protected code could be vulnerable to SQL injection and fail the or 1=1; test. So it does make sense to vary sometimes.
3
When $id is a variable which is obtained from user input, then this is a textbook example of an SQL injection.
Your code will work if the $id is a numeric string like 42. But imagine what will happen if someone enters this string as their id:
' OR 1 = 1 --
Then the SQL query sent to the database will read:
SELECT id, username FROM users WHERE id='' OR 1 = 1 ...
3
In general the answer to “is it possible” will almost always be yes.
In the case you describe: is it practical that something malicious would be stored in the database? It seems unlikely, and wouldn’t be the first explanation I’d choose for the circumstances.
If you are particularly concerned then lookup historic vulnerabilities in the software, a typical ...
2
Given a competent software architect, I would say the biggest issue tends to be implementation, and more specifically individuals that lack knowledge and training about secure coding best practice.
To qualify this short answer, I will contrast with design and show that design covers a broad space, some design is prescribed and defined by others, the rest, ...
2
The standard method for verifying "Blind" SQL injection attacks is the WAITFOR Flow Control element.
WAITFOR DELAY '00:00:5'; - for example, this will wait 5 seconds before returning. Assuming the operation is synchronous with the code, if you see a 5 second delay before a response, you can verify that the injection is working.
You can read more on Blind ...
2
First of MariaDB is supported through MySQL engine in SQLmap so the parameter you have there --dbms "MariaDB" is wrong. There are different reasons that each of your three commands are not working.
First one does not include an injection point.
Second the suffix you use is wrong as it misses the double quote that closes the escaped quote from the ...
2
Think about where the injected string is going. It's being concatenated into a SQL query at a point that is wrapped in string delimiters. String delimiters always need to be paired; if they aren't then the DB engine will detect an unclosed string and reject the query rather than execute it.
An example:
Original SQL "template", before concatenation: SELECT *...
2
I'm sorry to inform you that while you're using parameterized queries (which is great) your authentication checks are severely flawed. Sending the redirect header does not halt the execution, so any code that occurs after the redirect will still execute. You can validate this yourself by using a web agent that can ignore redirects such as curl.
2
Even if an attacker breaches the server database, and obtains the userid (u), verifier (v), and salt (s) for a client, the attacker would not be able to use this information to login as that client.
See https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol. Step 4 is where the client computes the client session key, as follows:
S_c = pow(B - k * ...
2
Parameterized queries solve this problem as it separates the parsing of the query from the handling of user supplied data.
2
If you control the sort direction, then this might be exploitable by replacing it with a desc union select <other query>. I have not tried it though.
See this post.
You will have to specify the exact number of columns of the original query, which you can find out by looking at the SQL error. In case that you don't have that information, you can find ...
2
There's an app for that. See https://owasp.org/www-project-juice-shop/
It's a project designed to break all the rules, so you can study it. You can try and find all the problems, not only sql-injection.
2
Since this is an assignment, you need to learn more of the underlying function. You have a big helper in that the server is returning detailed error information, in the security world this is a big no-no.
There are numerous SQL sub dialects, but in general what you need to do is:
Break the standard processing
You've already done this with the insert of the ...
1
Unless you can map out what might be legitimate queries in URLs a WAF will be a disaster (this should only allow you to mitigate the disaster, not prevent it, and will still require a lot of effort - expect to have to write a custom regex for each parameter in every URL).
You won't be able to run it on a modern PHP install without a MySQL shim (e.g.).
...
Only top voted, non community-wiki answers of a minimum length are eligible
