6
First, regarding what you have tried already:
header('Access-Control-Allow-Origin: https://www.example.com');
This will fail for a number of reasons:
This a client-level control that doesn't stop anyone from making requests to your endpoint anyway. This is, in fact, a flag for CORS in a browser, and isn't actually relevant to your use case. It would not ...
6
To be awfully honest, this function is just an arbitrary collection of more or less useless or harmful and sometimes even contradicting procedures, most of which has nothing to do with security at all. Now to the most important part.
SQL Injection
For prevent my website from sql injection i always use $db->real_esacpe_string()
Which is what you are ...
6
Generally, SQL Injections happens when an unsanitized variable is used within a query, regardless of whether there is an apostrophe or not.
In PHP you want to use prepared statements. This will transform your query into:
$sql = "UPDATE `users` SET
`user_age` = ?,
`user_sex` = ?,
`user_description` = ?,
`user_sound` = ?,
...
5
Presuming that prepared queries are easy to use and don't cause performance issues here, then you should just use prepared queries. All else being equal, I prefer to do things the secure way by default. In other words, instead of asking "Should I do this the secure way?" (which is what you are asking) try approaching from the opposite perspective: "Is ...
5
This code is vulnerable to LFI when running on Windows systems, because those systems will accept a path containing a directory traversal which uses backslashes (like \..\..\).
5
There is no binary answer to be 'GDPR compliant'. There are however some steps you can take to be compliant to some extend. Key element to the GDPR is that you need either explicit permission from your users (or visitors) to collect, store and use their data or another legal basis (such as required by law). The request to use their data must use clear ...
5
At least, the newline is not escaped, so, you can bypass it via /index.php?arg=%0Als (it should list all files from the current directory).
Also, there is a possibility to get a Full Path Disclosure passing arg as an array (/index.php?arg[]=1).
5
You are correct this implementation of constant-time string comparison will leak information about the length of some string that is being compared against an attacker controlled string.
However, if this is checking strings for authentication purposes, you never should be comparing raw strings. You would first hash (preferably with a salted key-...
4
If this can be considered an attack, how can one protect his website from such forged headers?
Forging requests that take a long time to process on the server is a common technique for a Denial-Of-Service (DOS) attack. This is why you always sanitise your input. Not just POST and GET values, but also the headers if you use them.
For the ...
4
Step one is to never store the password in the webroot. You allready got that covered. Good!
Step two is to not store the password in PHP code. Your code base should be free of secrets, be it in class constants or anything else. That let's you commit it to version control, make backups, share it, etc., without second thought.
Keeping the secrets out of the ...
4
The assert function will be called with one static parameter, the string is_string($entityId).
Thanks to the usage of single quotes, $entityId won't be interpolated, so an attacker won't be able to execute any PHP code.
4
In mysql you need a white space after comment marker. Just put one whitespace character after --.
select * from users where login='admin' -- now you can add comment
Generally add trash character after the whitespace against trim function. Like;
admin' -- xx
4
The editor is great for usability, but it should really be ignored when taking about security against XSS.
It's the sanitizer running on the server that needs to take care of ensuring security of injected HTML. No amount of fiddling in the browser is going to completely protect the user against unsanitized input if you need to mix in HTML (OTOH, if you just ...
3
The reason a javascript version is offered is because of nodejs, a server-side javascript interpreter.
It is not that javascript is not powerful enough to encrypt messages; it is that javascript (in the browser) is client-side. This means that XSS-injection or a web browser plugin could engineer your website to collect its data before the message is ...
3
Your idea on the domains is rather wrong. You need to understand one essential thing about a web server.
There is no such thing like "an access from a domain". It is not a "software" which is sending requests to endpoints but a client (which is usually a browser). A client may read some information from your server first, but it's unnecessary.
Long story ...
3
A few points:
Passwords should be hashed, not encrypted. Encryption is reversible; somebody who shouldn't have access but can see the app's source code can find the encrypted password and its encryption key, decrypt the password, and thereby gain access. Hashes are one-way; you can't turn a hash digest back into the text that was hashed.
You'll ideally ...
3
Just isolating filesystem access is not enough by itself to protect the rest of the system, and it's also notoriously hard to do right (chroot can be pretty easily escaped, SELinux is a pain in the arse to set up, etc). Among other potential means of attack you have:
IPC objects (semaphores, POSIX message queues, signals, etc). There's no easy way to ...
3
This is trying to exploit a remote code execution vulnerability in ThinkPHP. So yes, someone is attempting to attack.
Yes, although this specific one is specific for ThinkPHP, there are also regularly vulnerabilities for Django
Yes, this is very common for web apps. This is not the only type of request to attack and a succesful attacker might change the log ...
3
For passwords, bcrypt is a much better option that SHA-3. SHA-3 and bcrypt serve different purposes. BCrypt is a Key-Derivation Function, while SHA-3 is a regular hash. KDFs are deliberately more computationally intensive than standard has functions. The slower a hashing function is, the longer it takes to crack. This helps protect against offline attacks ...
3
Unsalted SHA3 is a terrible choise for password hashing. Go with bcrypt instead.
First, you want password hash functions to be slow so that brute forcing is slow. Bcrypt is designed to be slow. SHA3 is designed to be fast.
Second, you always want to use a salt. The salt forces the attacker to attack one password at a time instead of all at once. You want ...
3
I found out the answer from someone else. The error response with the link to ThinkPhp was the hint, the website was built using the ThinkPhP cms/framework.
A google search of ThinkPhp vulnerabilities shows that you can execute shell commands through the URL of the form
public/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&...
3
Because when you do this <"script src="ATTACKING IP:PORT443/phpbackdoor.php"></script>
The file isn't executed server side at all instead it is executed by the victim browser and of course it doesn't work its a PHP file.The browser looks for javascript in that,for example try and PHP echo "VALID JAVASCRIPT" and it will get executed by the browser....
2
Yes, this is an SQL injection attack but I noticed something.
In hexadecimal text:
6461726b31636f6465=dark1code, 6461726b32636f6465=dark2code, and so on.
I have also noticed the number 6461726b32636f6465 and 2121121121212.1 used together as 0x6461726b31636f6465--2121121121212.1 which is dark1code!!!!.
If you search for 0x6461726b31636f6465--...
2
Lots of good info in the other answers which include a lot of could happen reality and should be taken serious.
Not sure of your hosting setup, but let's say you're on whm server with other accounts and the function is used to get the content of /etc/passwd which includes lines like this for users on the system:
username:x:123:654::/home/username:/usr/...
2
Even now it seems to carry danger because of how PHP is still processing script from the 1st occurence of found file. So why did they keep the default as ;cgi.fix_pathinfo=1 then?
Because CGI is independent of PHP and have its own standard. CGI (Common Gateway Interface) is an interface that instructs the server on how to communicate data with applications, ...
2
I have personally come across this code just recently. I will try to write out what I remember and update as things come back to me. I will add the code and write in comments as I go.
//Turn off logging so that any errors don't catch peoples attention
@ini_set('error_log', NULL);
@ini_set('log_errors', 0);
//Set execution time low so that any endless loops ...
2
No, PHP code is always at least some part readable ASCII.
Typical obfuscation methods are to decode a piece of code and run that:
eval(gz_decompress(base64_decode("0Z074L7expJKXs...")));
But you would still see a PHP function name after <?php.
2
It sounds like you, as many before you have done, are trying to make it so only an "authorized" client can access your online API (presumably a web service). This, as you suspected, is impossible. You can take many steps to make it harder for somebody to write a functional unauthorized client (obfuscation, encrypting the tokens locally, blocking the use of ...
2
There are a couple of (possible) issues:
Everything that doesn't come from GET/POST is still a danger (possible sources may be files, emails, databases, etc).
SQL queries where you need to remove the quote or don't need a quote in the first place (eg in LIMIT, for id values (eg SELECT from x WHERE id = $_GET['x'])) or further transform the input (eg in IN).
...
2
Looks like your situation is quite unique, as, according to this answer, most web-servers won't let you to send 25000 fake languages, but only rather something around 2500.
Given your code is not optimal and having it changed this way
$supportedLocales = array_fill_keys($supportedLocales, 1);
foreach($userLangs as $lang)
{
if(isset($supportedLocales[$...
Only top voted, non community-wiki answers of a minimum length are eligible
