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 ...
53
You say that you don't have a choice, but that's not true. You could write all the code you need yourself. Or you could pay a trusted professional to write the code for you. Or you could could pay a security firm to audit the code before you use it. Or you could accept the risk, and implement other security controls to mitigate the risks. For example, if you ...
35
I will first address the generic part of your question, and then the specific PHP part.
Don't trust obscure PHP libraries that nobody uses!
It is just the usual gain/risk question. If the risk is low, you can do anything and use obscure (or even broken) libraries. That means that neither the platform nor the result of the final application are mission ...
26
As a general rule, you should restrict user input as much as possible, but not more. A field designed to hold the name of towns don't need unrestricted length. But if you cap the length at 25 thinking no names can be longer, you will upset the Welsh.
Shorter input lengths means less space for payloads if you are worried about e.g. SQLi or XSS. It could ...
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.
17
If you only need to verify the email when the user provides it, then hash it, like vidarlo suggests, in the same way you would hash a password. No need for encryption here. The flip side with this approach is that you can never recover the email, even if you really need it (e.g. to contact your users in case of a compromies, as suggested in comments).
If ...
14
The best measure to do this is to store such file on a directory outside the web root.
Basically, all of the solutions 'solve' the problem, in making the password file not available. Their differences stem on the kind of configuration error that needs to happen for it to break.
Surprisingly, such misconfigurations do happen from time to time, (e.g. when ...
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.
*/
$...
12
The advice is basically a mapping of trust principles one has in the "real" world into the world of software development:
Don't blindly trust someone but check the reputation. It is better to trust somebody who is also trusted already for a while by many others because in this case it is less likely that the trust gets abused. For software development this ...
11
Do you really need the users e-mail address?
If you store e-mail address as hash(e-mail + salt):salt you can trivially verify the e-mail address supplied by the user. If the user requests a password reset, simply verify that the e-mail address matches, and send the e-mail to the user supplied e-mail.
If you want to allow lookups in the database based on e-...
9
You are correct that you do no need to worry about PHP code being injected. The echo command just echoes stuff - it does not execute it.
The JS is more problematic, though. Your code may be vulnerable to XSS. The client controls the user agent, and the attacker controls the client. You are giving an attacker the ability to inject arbitrary HTML and JS code ...
9
It depends on what you want to protect against.
You mentioned that you have a Regular Expression used to validate input. That can be good, but depends ultimately on how your regular expression is formed. If your RegEx looks like this, you'll likely be fine:
{\"name\":\"(.+?)\",\ ?\"age\":(\d+?)}
If your RegEx looks like this on the other hand...
({.+})
...
9
Overview
Modern hashing methods (which password_hash uses) are intentionally slow to make it impossible to do exactly what you are trying to do. Most are even resistant against parallelization with a GPU.
So if your goal is to speed up running through a 1 GB password list against a modern password algorithm, there is only one answer: there is no way to do so ...
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 ...
9
If you can't see obvious patterns, that does not make it cryptographically secure! See also my answer to this question on our sibling site: What does it mean for a random number generator to be cryptographically secure?
At the risk of stating the obvious, rand() and mt_rand() are NOT SECURE for security purposes. Do NOT use them for things like shuffling a ...
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
An alternative to existing answers: put the emails on a separate machine & application and store only the hashes in your main application DB.
Use the hash for verifying the emails.
When you need to send an email your application will communicate with this other service passing on the hash + email message and the other application will send the email.
...
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... strange. My guess is that you are right in that this is some sort of protection mechanism, but it doesn't look like a very stable one. A better approach would be to block files with .php or similar extensions, and on top of that turn off PHP execution in that folder.
So can this be exploited, and if so, how? I am not sure, but here are a few ...
5
tl/dr: Whether or not you have a reflected XSS vulnerability depends
on the exact method you use to append the data. Therefore you should
specifically check your chosen method to make sure it is safe. Modern
javascript frameworks typically take care of these things automatically for you, but jQuery
doesn't, so attention to detail is critical.
You don't ...
5
Solution: upload the file as hidden, for example: .shell.php and call the file directly.
4
First of all, I assume that you are the owner of the website disclosing the phpinfo, and you ask this for academic purposes.
To achieve what you said, I would do the following :
Create an invisible iframe (0px x 0px)
Store cookies in var x by parsing the iframe content through contentDocument getter/setter
Create an invisible <img/> (0px x 0px) with ...
4
Whirlpool itself is a cryptographically-secure hash function like SHA-512 and has no known weaknesses that would be relevant to hashing secrets. However, using it directly for password hashing is a bad idea because it is fast, allowing an attacker to guess many passwords per second. This is not unique to the Whirlpool hash. A memory-hard KDF like Argon2 ...
4
Your website may be vulnerable to a reflected XSS attack (It depends upon how you are setting that value and how the data is interpreted). For example, imagine if I access the following URL:
mysite.com?p="></a><script>malicious_code()</script><a href="
If your site converts this:
<a href="secondurl.com">Link </a>
into ...
4
Microtime() is an incremental value, not a source of random values (quite the opposite). Using this as a source of randomness causes the output to be... More predictable. It drastically reduces the key space of your hash method to a range that can be guessed reasonably well.
Your colleague generates their hash using md5(random()), you md5(microtime()). To ...
3
This is not strictly an Nginx problem, but rather is an issue with old versions of PHP. It has been fixed for quite a long while (I'm not sure exactly what version, but it certainly isn't a concern with PHP 7.0). The answers to this question:
https://serverfault.com/q/627903/377662
Explain the underlying issue and solution in detail. The short answer is ...
3
Use password-hash (https://www.php.net/manual/en/function.password-hash.php) which will continually use the most secure method as PHP continues to release new versions. Asking users to update passwords isn't a huge issue. Whirlpool doesn't have any known cryptographic flaws, but there are certainly better algorithms to use. Source: https://www.novatec-gmbh....
3
In an arbitrary sense a database is a file - in Unix systems it definitely is. I'm not sure why however, if you want to store anything in a file that you don't want accessible, you aren't storing it outside of web root. Doing that immediately renders bullet point one and two useless (plus there is no such thing as security through obscurity).
Bullet point 4 ...
3
It's malicious. Everything about logos and stuff is misdirection. What it's really doing is taking the base64 string, decoding it, some other tricks for obfuscation, then running it through create_function and calling the function (which is the same as just evaling it).
For reference, here's a deobfuscated version of pre_term_name, showing that it's ...
answered Aug 22 '19 at 21:31
Joseph Sible-Reinstate Monica
5,3782 gold badges14 silver badges28 bronze badges
3
One way to protect against timing attacks when querying an indexed database field, would be to hash the value server-side. It's similar to how an attacker can't login if they obtained hashes of a password because the server still applies the hash before checking the database.
The original code (from the question above) has a number of issues, as marstato's ...
Only top voted, non community-wiki answers of a minimum length are eligible
