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 ...
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 ...
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 ...
Storing card numbers means you must comply with the requirements of PCI-DSS, or you risk fines and breach of your merchant account contract. PCI-DSS has an enormous set of requirements - some sensible, some onerous, some of questionable usefulness - and the cost of complying with it, and certifying that you've complied with it, can be very high.
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!
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,...
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 ...
"None of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner" are completely valid arguments. From a technical perspective (on the merits), they ought to end the discussion. But if you're arguing with folks who are not security experts, they may not be in a position to recognize good ...
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 ...
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 ...
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 ...
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.
You've come to the right place. Welcome to IT security!
is there any sql injection for this code?
if there is what is that Entry?
username: [any username from your website]" /*
password: sux0r")*/ OR ("1"="1
It will run this query:
SELECT * FROM `config`
WHERE `config_admin_username`="[any username from your website]" /*
The vast majority of web applications do not allow query stacking. With PHP/MySQL application can allow for query stacking if you use the mysqli::multi_query()or mysqli_multi_query() functions.
You can exploit these systems using sub-select, union-selects, blind sql injection, into outfile, or loadfile(). SQLMap and Havij are both tools that automate ...
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 ...
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 ...
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 ...
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 ...
The ‘high’ example is not exploitable. It's not a good approach (in modern code you would use parameterisation instead of calling mysql_real_escape_string, and stripslashes is a relic of an era of magical quotes that is thankfully over), but it is designed not to be immediately vulnerable.
(To SQL injection anyway. It is vulnerable to HTML-injection leading ...
Short answer: It's damn vulnerable.
Why? You are concatenating the values given by POST which come directly from what the user typed. Therefore, it is very simple to manipulate your query. Also, you are using mysql extension which is deprecated. You should be using mysqli or PDO to create prepared statements to protect against injection.
Here's a question ...
In addition to what Philipp said, keep in mind that SQL injection attacks are quite often done without knowing the structure of the DB, but once a vulnerability is exposed, it can be used to determine the structure.
For example, one of the first SQL injection string that was once taught used to be ';shutdown--
This makes an assumption that the data user ...