(My-)SQL permissions are pretty fine-grained, so I'd wager there shouldn't be any obvious security issues
Even with permission on the record level, it does not scale easy. If a user has irrestricted SELECT on a table, they can select any record on that table, even those not belonging to them. A salary table would be a bad one. If any user has ...
You could write some Python code to upload an SSH server binary and then run it, this will give you full SSH access under the privileges of the Apache user.
From there you can easily read the Python app's config files and connect to the database using the credentials from there, which will allow you to grab confidential data (no exploits needed here as the ...
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 ...
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 ...
Interesting question. In theory, this can be done securely. MS-SQL can secure the connection with encryption, authenticate the user, and provides fine-grained permissions and other security features like auditing.
In fact, it used to be common in intranet environments that thick clients would access a database directly, so the database security controls ...
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 ...
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 ...
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 188.8.131.52, “'--' as the ...
I've built both RESTful interfaces and provided customers with direct SQL access.
The problem here is that the question is fundamentally flawed:
Lots of the work backend developers do is providing CRUD access to
customers via HTTP, essentially mapping data from and to the internal
This is not, in my experience, a significant portion of ...
The most simple solution would be not to expose MySQL. Usually, MySQL server is accessed only from the same machine, in which case you can set it to listen only on a Unix socket, or on a loopback interface.
If it indeed needs to be accessed from other machines, these are generally just a few ones, in which case you can firewall the port from any host, but ...
A second order SQL injection is an injection where the payload is already stored in the database (instead of say being delivered in a GET parameter). In that sense it is somewhat similar to stored XSS (and ordinary "first order" SQL injection would be analogous to reflected XSS).
How does it work? Lets say you let users pick any username. So an attacker ...
Yes, it's sensitive information. It's a password hash leak.
Attackers will supply this information to a bruteforce application (there are some tailored just for MySQL) and retrieve the password.
Not only this, but the % on the host field means that if your MySQL port (3306 by default) is not firewalled, the attacker can access it as admin from anywhere.
The only piece of information that you could hope to "hide" is the sequence: since a database will allocate primary key values with a counter, people who see they key can make a guess as to when the corresponding user account was created. Apart from that, there is no other information that any obscuring scheme may actually hide. The attacker already knows ...
Realistically, no you cannot. AES is very resistant to known plaint text attacks like most block ciphers.
It's lucky you didn't lose any information and have the original database backup because your only real option would be to try brute force the encryption, which is likely to take longer than the length of the universe (unless you can greatly narrow down ...
Answering your question
mysql_query() doesn't support multiple queries as documented:
mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier.
Which means that DROP TABLE temp; -- is never executed.
It is although possible if you use ...
You say that performance should be "way better", except that now you've just given malicious actors complete authority to wreck the performance of your DB. Of course, they have to authenticate, but the "malicious" actor could also be a "naive, incompetent" legitimate user. What are you going to do when users start running outer joins on all ...
No, this is not a good idea!
As Lukas pointed out in an comment, you want to hash a password, never encrypt it!
With your schema, it would be possible to get the plaintext passwords from an database dump without any effort. Don't let that happen!
One easy way would be to use the method youtube and other websites use.
This is hashids (http://hashids.org).
With this method you can give links like: http://www.example.org/user/fce7db/edit while fce7db would equal to a number e.g.: 12
This has the advantage of performance in contrary to generating another random hash in the database, because you only ...
What does (@) and (@:=0x00) stand for in this payload?
@ - is the variable name
@:=0x00 - is the assignment of zero into this variable.
Note: := is the assignment-operator
Thanks for @Frank Cedeno and @strnk for their Q&A in the comments.
@Frank Cedeno - How /!12345sELecT/ becomes select?
@strnk - This is a MySQL-specific extension to SQL ...
It is not a problem if the attacker learns the salts. Salts are not meant to be secret. What is important for a salt is that it is unique for each hashed password instance (i.e. not only a unique salt per user, but the user's salt must be changed when the user changes his password).
If you think of your salt as something that may be shared between passwords,...
We know, but we do not have enough developers/testers to make it 100%
This is the real problem. Until you hire more people or reassign priorities, you're not safe. Stopping 99.9% of attackers means that your data has been compromised. Band-aid solutions are a bad thing, and they do not work. Don't waste time refactoring your SQL access pattern while ...
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.
The worst case scenario you have to protect against is an attacker which completely compromises your server and obtains your sourcecode, your config and a dump of your database. Keep that in mind.
This is the scenario in which a salt is supposed to protect your passwords. Remote brute-forcing is not impaired by a salt at all (which is pointless anyway on ...
No, it's not necessary. But please, read on.
Input sanitization is a horrible term that pretends you can wave a magic wand at data and make it "safe data". The problem is that the definition of "safe" changes when the data is interpreted by different pieces of software.
Data that may be safe to be embedded in an SQL query may not be safe for embedding in ...
The fragment AND 1=0 always evaluates to false and therefore the query always returns an empty set, e.g. if the SQL fragment in the application is
SELECT * FROM users WHERE username = '<placeholder>'
then I can turn this query to
SELECT * FROM users WHERE username = 'admin' AND 1=0 --'
when using admin' AND 1=0 -- as value for the placeholder.
This could be a reasonable approach in certain circumstances:
The customer gets read-only access.
They get read access to an entire database: it's either quasi-public data to all your customers, or it contains only their own data. In particular it must not contain user PII or data that's otherwise subject to regulatory controls.
You don't mind them reading ...
The primary reason not to use AES_* functions in MySQL is because they are using ECB block mode of operation, which is insecure.
Read more at:
Since MySQL 5.6.17 things have changed and MySQL supports CBC block mode, but it has to be enabled manually. Read http://mysqlserverteam.com/...
If it's not needed, it should be closed.
You can never be sure if there are no vulnerabilities in MySQL itself. Here is an example for a DOS attack (and it's not the only possible attack).
Allowing non-ip restricted remote access to MySQL
Allowing remote access to MySQL is not a vulnerability by itself, but there are scenarios where it ...
I see two options here:
Local Access Only
Configure MySQL Server to only listen on TCP port 3306 on 127.0.0.1 (localhost). This way an internal web server can still communicate with the database server.
Directly connecting to the database is server is no longer available but can be solved by SSH tunneling (as described in mk444's answer)
This can be ...