Tag Info

Hot answers tagged

6

PHP can only be exploited in the shellshock-case by using it in PHP-CGI mode due to the nature how CGI works. For PHP functions like system() and exec() it is not possible to influence the environment variables unless you set them yourself in PHP. That would then be in your example something like system("HTTP_SERVER=evil.example.org /path/to/script");


6

Posting a body such as this: realname%3DSisodiya%20Chhatrapalsinh%26email%3D%60rm%20-rf%20%2F%60%26comments%3DDo%20your%20own%20homework%26submit%3DSubmit


6

FastCGI communicates between the webserver and the CGI host using IPC rather than environment variables, so the main attack vector (the webserver setting environment variables for CGI) is gone. However, it is still possible for you to be attacked if your PHP script itself sets environment variables based on user input before executing bash.


5

There are a few things you can do to mitigate the risk: Try to upload the files to a path outside your webroot For example, if you host your site on /var/www/myserver/html, make your PHP upload script write files on /var/www/myserver/data. This way, a Local File Include will not work, as the sent files are outside the server root. Don't use Mime Type or ...


4

It could be due to a (previous) bad code or to avoid warnings/errors in responses. stripos returns the possition of second parameter in first one, starting indexes at 0, so in a bad code if (stripos($ua,'android')) the condition would be skipped as false in the case the string started with android. Correct solution would be using === and !==, but ...


4

If PHP is deployed using mod_php then this scenario is basically safe. As you say, PHP does not put untrusted data into environment variables the way CGI does. If PHP is deployed using CGI (which is a rare config) then it is vulnerable if the script makes any call to bash. It appears PHP system() uses /bin/sh - on Redhat distributions this tends to be bash, ...


3

One relatively easy approach to this would be to create a persistent cookie on the client's side after the first log in. The cookie should hold only the user's username and a generated key. During the next log in the server would verify the key against the same key stored in the database and if it doesn't match or the user doesn't have the cookie at all you ...


3

your best bet for this would be probably to look at the other OWASP ESAPI implementations to see how they've handled it, which should at least give you the approaches to look at, even if you then need to translate that over to PHP. In terms of information you could look at this post about the Java ESAPI implementation which is, AFAIK, the most mature one ...


3

If someone manages to catch a request like this it may be possible to resend the request numerous times in your five second frame. Now the question is how to prevent this. There are more options, the most simple one seems to be, that you add a unique ID to each command, and the recieving server stores them in a way (like a table) and executes your ...


3

No. The backdoor is not on this script. This piece of highly obfuscated code contains a program to allow the hacker to dynamically append any HTML or javascript by randomly calling a server located at 31.184.192.250 with one of the four hostnames "33db9538.com", "9507c4e8.com", "e5b57288.com", "54dfa1cb.com". The deobfuscated code looks something like this: ...


3

Because the index.php file is already being processed. When you attempt to inject a ?> tag into the file, you're actually injecting it into the page that will eventually be sent to the client.


3

I recognize this webshell, as I've dealt with it many times over my years in the shared hosting world. This is known as a webshell. This particular one, Filesman, has a slew of dangerous features one can execute. To name a few, they can view and download any file or directory in your webroot, change permissions (CHMOD) of files and directories, and open ...


2

The session is just a random generated token which is impractical to guess. There are many scenarios in which stealing sessions are possible such as Cross Site Scripting (XSS) or by sniffing the traffic if the attacker has access to a networkin node between client and server. To solve the XSS issue you need to not have validation issues. This means proper ...


2

I'm doubtful it can be exploited for php the same way as it is exploited in CGI. If you compare the output of: $ cat ./testing3.cgi #!/bin/bash echo "Content-type: text/plain" echo echo set To the output of: $ cat ./testing.php <?php system('set'); ?> The environment variables read into bash are very different. Particularly, no ...


2

Yes, it's not C/C++ language; however, perl, PHP, ruby and java are descendents that carry on various C language conventions. By not having %n, php gets rid of part of the problem, but it still has %x which can be exploitable under certain circumstances. Basically, printf() and its variants can allow control of the format string if you don't specify it. ...


2

Why not just use an existing token-based authentication method like Kerberos and build off of it? So the user authenticates normally and receives a kerberos token. Then, you go to the API server, say "Hey I got this token!" The API server verifies it, and sends a copy of the encrypted data to the user, who can decrypt the keys on their machine? Seems ...


2

The two main risks of a system such as this are: SQL Injection XSS The risk of SQL Injection is mitigated by the use of parameterised queries. This ensures that data values inserted into the database can only be interpreted as data and not by part of the query by an attacker escaping out of the context. XSS is prevented by correct output escaping. This ...


1

Your code looks good and there doesn't appear to be anything you need to be worried about. A side note or two: I would consider adding trim() to your variable to clean any white space. I am a little curious why you use if(!empty){}if(empty){} instead of an if(!empty){}else{}


1

Set <form> accept-charset Attribute using UTF-8 Sanitize all the html / xml special characters and replace them with their escaped version. Display the code within the <pre> tags


1

You escape the output by replacing "special" characters with their HTML character entities. In PHP, you can do this using htmlspecialchars(), for example. I suggest using the ENT_QUOTES flag to ensure all types of quotes get encoded.


1

You seem to talk about two different things: retrieving mail and encrypting mail. From reading the question I think encryption is not what this is about. So for now I forget about it. When you login to Hotmail or Gmail via your browser, you use your login. It looks like you have more email addresses and possibly popboxes. Now it depends on how you setup ...


1

The two encryptions are equivalent. You can add a wrapper to use one approach as a drop-in replacement of the other: /** * Uses the one-parameter method as if it was the 2-parameter one. */ function buhlencrypt($keya, $data) { global $key; $key = $keya; return encrypt($data); } /** * Uses the two-parameter method as if it was the one-parameter. */ ...


1

The IP addresses seem to belong to a plethora pf european ISPs/data centers: inetnum: 83.31.0.0 - 83.31.255.255 netname: NEOSTRADA-ADSL descr: Neostrada Plus descr: Warszawa country: PL inetnum: 178.217.184.0 - 178.217.191.255 netname: HOSTEAM-1 descr: HOSTEAM S.C. country: PL ...


1

This simple PHP file offers a shellshock security hole: shock.php <?php # in some configurations (CGI) your webserver does the following for you: foreach ($_ENV as $k => $v) putenv("$k=$v"); # execute something with bash echo shell_exec("bash -c 'echo hello from bash!'"); To execute the attack wget --header="X-Exploit: () { :; }; echo Hacked" -q ...


1

From my testing it does seem possible to exploit via PHP using mod_php if certain conditions are present. /bin/sh would by symlinked to /bin/bash. The PHP app would set an Environment variable from a user-controlled HTTP variable using putenv(). Somewhere in the PHP script, there is a subsequent call to a command exec function that will then load that ...


1

Sorry, I do not get the part on your concern with timing attacks. As long as the passwords are properly hashed and the comparison is done on the hashes, your application should be safe from this kind of side channel attack. Whether a database call has been made or not (2s vs 1s) does not leak any information on your password. It is always good to validate ...


1

mod_fcgi itself is not vulnerable: it talks to Apache through interprocess communication rather than the environment variables of traditional CGI. Any CGI scripts run through mod_fcgi can still be vulnerable if 1) they can be coerced into setting environment variables and 2) invoke bash (say, through a system() call or backtick interpolation).


1

Some things to consider: make sure you set the domain/path of the cookie so that only your domain (and no sub-domains can read it) You seem to be using HTTP rather than HTTPS. This makes your cookie subject to eavesdropping. Consider using a HTTPS session and a cookie using the secure attribute. 90 days is a long time to hold such a session open. The ...



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