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


45

The current general best practices for authentication are in the NIST SP 800-63-3 Digital Identity Guidelines standards, especially in SP-63B Authentication and Lifecycle Management. These NIST standards are an easy read for developers, and besides telling you what to do, it also talks about why you want to do certain things. (If you want more details than ...


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.


13

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. */ $...


9

The salt isn't supposed to be secret. Its purpose is to be different for every password, so the hashed database can't be attacked with rainbow tables. The other parameters you mention aren't supposed to be secret either. So you can store all this information in the same database, which is how most applications do it. The database table that contain the ...


9

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


7

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


5

This is a software engineer here. I will answer from that point of view. My local network has many devices on it running simple web servers You should really try to see if you can use SSO (Single Sign On). Before telling some detail, SSO is basically not storing passwords in your app. You will rely on a third secure party, like Active Directory. After ...


5

Yes and no. First the no: As you have realized, if any data you put in an app that you send to a client can be extracted from it. You can take steps to make it harder to find the password (obfuscation, encryption, etc) but as a general rule of thumb, never put anything in the app that isn't supposed to be public. So how do you protect your database ...


5

I am not sure where you intend to place this login screen but I assume that you will rewrite part of the servers to add a login page. I do not really understand what is "the server" written in Python you are referring to. Anyway, do not reinvent how to store the passwords. There are methods for that and since you mention Python, a good starting point may be ...


4

The main aspects to consider in this case are defense-in-depth and security by design. As you rightly point out, adding layers after layers of firewalls and port forwards does increase complexity but does not defend against attacks on its own. A successful attack is a function of time and effort, therefore anything can be compromised. Having this in mind ...


4

A scenario with three different applications If you have three different applications in most cases they should not all have full access to the database in the first place, just the data each needs. If they all need the same data, that is already a setup that reeks of misusing the database as a synchronization mechanism. If that's the database's main ...


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

TLDRTLDR Don't do this! TLDR TDE is irrelevant for this question. Don't do this (index encrypted substrings of encrypted strings). Don't index encrypted values generally. If you are going to do this anyways, use an HMAC or other MAC algorithm to generate the encrypted values to be used in the index(es). If you're feeling really lucky, consider using a ...


3

Since you're confident that the SQL vulnerability exists based on your Burp results, I'm going to assume that you got that error message from your web client. Either your input has a type attribute set to email, either there's a JavaScript snippet which checks that your input matches an email address format. The easiest way to bypass both of these checks ...


3

First of all, let me say that your scenario is quite bad. Storing copies of personal information on an unsecured laptop that people could rob rings a number of bells, and my first instinct would be to ask why do you really need to do that?? It may be possible to handle it on a better way. And even if budget restrictions are a concern, do note that they need ...


3

Storing encryption keys next to encrypted data is always a security risk, even if the encryption keys are hashed. Now if I understood correctly, the reason for storing the encryption keys is to check that the user can decrypt the data (since the key is hashed, you wouldn't be able to reverse the hash to decrypt the data). But for this purpose you can use an ...


3

Assuming the value stored in the agents.password field is the MD5 hash of the password, the code as shown is correct: sends the database the (login, password) pair asks it to find a matching entry where agents.ID == login and agents.password = MD5(password) and return the value of the agents.password field if the returned value is empty: return an error (I'...


3

The short answer is: Just don't. The long answer is: It depends on the rest of the system. As ram0nvaldez said, you have to decrypt the data to work with it. Some level of decrypted in-memory is necessary. But! Are you storing your cached DoB data in a Redis cache? Redis writes its cache data out to disk on a regular basis to facilitate fast restarts. ...


2

The problem with SQL injection is not how the data are stored in the database but that statements in the query language are code and data combined into a string these statements are often constructed by manually combining strings of code with strings of untrusted data improper validation of the untrusted data leads to interpretation of these data as code, ...


2

It depends. Objects are Secret If the data being uploaded with those GUID is considered secret, then you do not want users to share the same GUID. For that reason, you want to include another identifier in your primary key to make sure that each customer has its own set of GUIDs. In other words, as Conor mentioned in his comment, every user would be able ...


2

Two very common situations: no one thought about it that was not the original design, but scope creep or "temporary measures" meant that the final product exceeded the plans for review, so it wasn't on anyone's radar As a single developer, you hold all the moving parts in your head and you touch every part of the system. You could think about the impacts ...


2

I guess it all depends on your thread model and szenario. I am reading between the lines that you are afraid of what will happen if an attacker gets access to the table containing the 2FA secrets, for example by a leaked backup or SQL injection. If this is the case, you can encrypt the secrets with a systemwide key, that is loaded into your application ...


2

I just wanna ask if my PHP code is secure enough This question cannot be answered. A security assessment is very complex and bases on a thorough risk assessment. Secure for what? What kind of attacks are you foreseeing? DOS? I don't see any protection from what you've shown here (might be implemented somewhere else) SQL injection? You're using ...


2

I can see a couple downsides: Remote access This is the most basic one. If the attacker gets the credentials for any user of the database, it will have remote access. Not as improbable as you think. Remember that config.php.bak, vars.php.old, and so on, that someone left over? Guess what happens when the attacker uses dirbuster and grabs those... ...


2

I'm continuing the theme of @schoeder's questions and answering the questions that you didn't ask. First though let's answer your questions. You don't want to sign records. You want to figure out who is responsible for the manual edits to your database. The most direct answer to your question is that you want an audit trail. Many databases have ...


2

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


1

There are several aspects which lead to insecure software, data leaks etc. The main requirement for any business task is always that it has to work since otherwise it would be useless. Security comes only second and in no way should security requirements impact the actual use too much. Add to this insecure defaults and the complexity of the software stack ...


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