Hot answers tagged

6

No. PHP will parse the php file looking for either <?php, <? or <?= (depending on the value of short_tags) However, outputting <?php to the screen would not execute code. It would need to have been evaluated (eg. saved to a .php file in the server that you then run). This form is probably vulnerable to XSS, though.


5

The short answer No. This is not safe, and should not be done. In fact, this is the last one of OWASP Top 10: A10. Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims ...


5

OK, so the first issue is: do you need these rolls to be reproducible and predictable? That is, do you need to be able to fast-forward to the 10000th roll or rewind to the 20th, and get the same result? If you don't need that feature, then why not use a cryptographically secure random number generator instead? This way, neither you nor an attacker can ...


3

As @schroeder recommended, you should share the key between applications/servers using Public Key Infrastructure (PKI). It's not recommended that you implement this yourself. There is a great article called Choosing the Right Cryptography Library for Your PHP Project. This is worth taking a look at. It recommends the following libraries: Halite Libsodium ...


3

First of all, make sure that your webserver knows that it has to interpret PNG file as PHP. You need to add this to your .htaccess file. AddHandler application/x-httpd-php .png or AddHandler application/x-httpd-php5 .png Otherwise, it won't execute the PHP code. Second, there's a syntax error in your curl request. You're missing a quote. Try this: ...


3

As this question mentions, a single random unguessable token per session is sufficient. When you start generating tokens per-page or per-form, you're simply limiting the impact of a CSRF token being leaked. Singular token leakage cases are relatively rare bugs, but XSS is obviously a common vector. In certain cases it does indeed make sense to have a ...


3

To hook into @UTF-8's comment, using PHP_Parser, you can fairly easily generate a list of default PHP functions not actually used by your application which you can then store in the disabled_functions configuration option: <?php require 'vendor/autoload.php'; use PhpParser\Node; use PhpParser\NodeTraverser; use PhpParser\ParserFactory; use ...


3

This looks like your run of the mill script-kiddie backdoor PHP script. The attacker likely has very little experience as they've just downloaded it from another site, they didn't even write it themselves. All they did was update some configuration. Well, the IP address is an IPv6 address, which relatively few people are using. Looks like it's likely ...


3

Current versions of PHP detect and prevent newline injections in the header function, see How to avoid HTTP Header Injection (new lines characters). In older versions pf PHP you could probably do something like login.php?redirect=%0D%0A%0D%0A<script>... Which would break out of the header and result in Location: <script>... And your ...


2

Your main problem is identifying who are your "real" customers. As the code is open, its easy for anyone to emulate a client. So, how can you do it? You can use asymmetric encryption. As the keys are not inside the code, there is no way they can "emulate" those keys. Each server will have its own keys. If encryption is too much for the client (and the ...


2

To add to what others have said : If you have a set of known URL's to redirect to (that you could map to an identifier), it would be much better to allow only known identifiers in the "redirect" parameter value. Then you can map the identifier to your safe, known, URL. Thanks to such a technique "all your troubles" go away. Of course if the value of ...


2

It is indeed way too simplistic. You can bypass it using a backslash character. Example of a way to bypass it on my IIS server: http://example.com/index.php?doc=..\/index.php It checks for "../" while, in order to make it "safer", it should check for ".." or don't allow any dots at all and make sure it's only included in the extension of the file requested. ...


2

You can use Suhosin extension which allows you to whitelist functions that you want to allow. See Suhosin's suhosin.executor.func.whitelist configuration option. suhosin.executor.func.whitelist Comma separated whitelist of functions that are allowed to be called. If the whitelist is empty the blacklist is evaluated, otherwise calling a function ...


2

This is a Norton Security/Safeweb false positive. Their threat scanning engine is flawed when handling reponses from these 'hacked' URLs, which in vulnerable systems can do damage. The problem is that they interpret the response incorrectly, so sites that have no PHP/WordPress etc get flagged in error. This is hugely damaging to customer goodwill of course. ...


1

You shouldn't show exceptions to users, and it does have a slight impact on security. I'm assuming that you disabled exceptions, and are now worried about the data that is leaked via the screenshot: Leaked Username Usernames aren't generally considered sensitive information. You may still want to keep it secret as defense in depth, to make some attacks ...


1

What you want in effect to know that the contents of a request is trusted. For this you would need to trust the remote application and to do this you would somehow verify that the application is exactly your application. This is called remote attestation. But, unfortunately this is impossible unless you lock down everything from start. For this you would ...


1

Files ending in .png will not execute php code even if they contain php code. You can however execute this code either through a LFI or by uploading a .htaccess file which will add a php handler for .png or in the case of Apache you could use a double file extansion, ie: phppng.php.phppng.


1

Input Filtering & Bypassing Filters are always great as an additional layer of security, but they shouldn't be your only line of defense, because generally, filters are missing context, thus making 100% secure filtering impossible. For example, your filter doesn't know anything about the underlying OS. Does it accept \ as directory separator? If so, ...


1

Let me answer with a few observations, and comments. I will begin with the "whodunit" approach of aiding in determining who, what, when, where, and how. What - a file you found on your system When - what date was it found How - how was it uploaded Who - who uploaded it You already know the file because you found it. Let's call this file: malicious.php. ...


1

Kudos for finding it quickly, it looks like you're doing something right. But you're also doing a lot of things wrong. The most obvious one is that directories within your document root are writeable by the webserver UID. It would help to know what you are trying to achieve by "tracing the origin" of the script. Certainly you should be looking for the ...


1

The first vulnerability I can think of is to pass a full URL as an argument that will redirect the user to a fake copy of the site (login.php?redirect=http://malicious.com) Aside from that, I'm sure there are several ways to prevent the redirection from happening and displaying instead malicious HTML/JavaScript. As a general rule, any URL parameter should ...



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