Tag Info

Hot answers tagged

30

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 ...


28

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 ...


26

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 ...


25

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. Download ...


25

There isn't a good answer. But here are your possibilities: Tie the encryption key to your admin login (e.g. encrypt the the encryption key with your admin login). This is only marginally useful as it requires you to be logged in in order to encrypt/decrypt anything. But on the plus side, no one can encrypt/decrypt anything unless you're logged in (i.e. ...


24

"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 ...


22

Run only MySQL on the Server - If possible run only MySQL on the server and remove any unused services. Firewall - Limit access by IP address to only the servers / clients that require access. User Privileges - When creating users always give the minimum amount of privileges and expand as needed. Also try to avoid using '%' wildcard for hosts and instead ...


22

I am not aware of any published cryptanalysis on MySQL OLD_PASSWORD(), but it is so weak that it is kind of a joke. It could be given as an exercise during a cryptography course. Update: a cryptanalysis similar to the meet-in-the-middle described below was published in F. Muller and T. Peyrin "Cryptanalysis of T-Function-Based Hash Functions" in ...


20

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. ...


18

You've come to the right place. Welcome to IT security! is there any sql injection for this code? Yes 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]" /* AND ...


17

In PHP you cannot stack querys with a semicolon. However you can nest a query into another with parentheses (commonly called subqueries), e.g.: SELECT * FROM vulnerable_table WHERE id = (SELECT number from other_table) Using this technique (disregarding whether you output your SQL result or not) a keen attacker may extract all data from your database. ...


15

Summary. Yes, the issue is that, in some character encodings (like UTF-8), a single character is represented as multiple bytes. One way that some programmers try prevent SQL injection is to escape all single quotes in untrusted input, before inserting it into their SQL query. However, many standard quote-escaping functions are ignorant of the character ...


14

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 ...


13

Generally hashing and encryption are for two different things. The main distinction in your case is that hashing is one way, and encryption is two-way. That is, you can decrypt the password to get them in plain text, but you cannot "de-hash" something. If your system gets compromised and you are using encryption, the attacker will probably have all the ...


13

You should use prepared statements to prevent SQL injections. Take a look at this question. However, $_SERVER['REMOTE_ADDR'] should be a valid IP address as it comes from the server, as verified by the TCP handshake. See this question for an extended discussion on this.


13

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 ...


13

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: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation Edit: Since MySQL 5.6.17 things have changed and MySQL supports CBC block mode, but it has to be enabled manually. Read ...


13

You just need to store the configuration in a file that is only accessible to the user that PHP is running as. You can prevent a web user from accessing the file, but PHP has to be able to get to the credentials and no matter what you do, they will be effectively unprotected. Any secret you could give the application could be discovered, so there isn't any ...


13

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 ...


12

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 is a great tool for automating these ...


12

The MySQL root user is an account inside the database only. It is called root because it is the most privileged user on the database server, and has access to everything. The root user on Linux (or any other Unix) is a completely separate thing. The maximum privilege that a MySQL user can have is equal to the privilege that the MySQL daemon runs at. On most ...


12

If there is no external interface to the lookup table, then you probably don't need to scrub the data coming out of those tables for security reasons. But it might be easier to always scrub data you are presenting rather than adding exceptions. Also, if the data in the lookup tables is safe for HTML output, what happens when you switch to CSV output? Is it ...


11

To get started, you're probably going to want to focus on two things: Securing your web server Security your website That's really two different specialties, and I don't think I'm going to be able to dig up a single document describing both... the ardent security nerd would also point out that this assumes you're working in a secure network with decent ...


11

This is really a pretty stinking huge question. Based on your chosen tags it looks like you're asking for guidance on a LAMP stack, so we'll focus on that. There are already a number of related hardening questions posted, so for some additional insights check out these questions: MySQL Server Hardening Hardening Linux Server What are the best practices for ...


11

The mere fact your DB ran the quoted queries (throwing you the error reports) means you do have injection vulnerability in PHP code. Note, that some methods of inspecting DB tables structure involve running multiple queries with different parameters until DB throws an error and HTML page breaks. That means the failed queries are only tip of iceberg of all ...


11

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 ...


10

You forgot just one little thing: Password strength. Just 2 words which overweight whole your brilliant topic. There are indeed hundreds of topics on Stackoverflow telling you to use this or that hashing algorithm and random salts. And only very few explaining that with weak password all your eight-item-list protection, all extra secure ...


10

Regarding your sanitization function - while I can't produce an exploit for the exact example you provided, if we change your example to something like this: $sql = "UPDATE ipsum SET price=$str WHERE id=1337"; If a value of 10, otherColumn=1234 or maybe 10;-- was passed in for $str you could see problems. If you roll your own sanitization function and ...


10

That depends. In some web applications, syntactically incorrect SQL statements result in an error message which might get forwarded to the HTML output the visitor sees. This might give the attacker some information how the query looks. ("You have an error in your SQL query near 'myapp_tbl_users'."). To avoid this, configure your webserver to not output ...


9

You should never put the password in the code. In general your connection settings live outside the compiled application code; for C# that would generally be in an app.config XML file, encrypted if need be. But either way, if the application is able to make direct connections to the database, it has to know the password, and there is nothing you can do to ...



Only top voted, non community-wiki answers of a minimum length are eligible