On the Laravel News site they've posted an article with some reminders about installing Laravel in a subfolder including "hiding" your .env file.

If you are new to Laravel you might not be familiar with its directory structure and the reasons why it’s setup the way it is. If you look at the main repository it’s setup like this, and the documentation covers what each of these folders handles.

What is important here is the “public” folder. That is the ONLY directory you want to be exposed through the web. Everything else should be outside of your web root, this way people can’t access any of your important files through the browser.

He gives an example of an instance where a site was in a subfolder and, just by changing the URL, he was able to locate (and view!) the .env file complete with sensitive information. The rest of the post gives instructions on installing it in a subfolder, moving around a few folders and updating the front controller to change the autoload and bootstrap locations.

In a new post to his site Mattias Geniar looks at an old security issue in PHP, opcache information leakage and how to mitigating the issue.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

He starts by talking about the vulnerability itself, that the PHP process doesn't validate the userid when fetching cached bytecode. This could result in information from other operations/scripts being exposed to other processes in a PHP-FPM pool. His solution? Upgrade PHP (the bug is fixed back in PHP 5.6.5) and set a few additional opcache ini settings to enforce the validation. Besides 5.6.29, it was also corrected in the PHP 7 releases (7.0.14 and 7.1.0). The post then talks about the potential exploit - an indirect local privilege escalation to root where the shared memory is read and access to outside information is possible.

The NetTuts.com site has a new tutorial posted today sharing some tips about working with sensitive data in your applications and steps to secure it.

In my previous article, I showed you how to protect your server from attacks and malicious software. This part will focus completely on the third layer of security - your application itself. So here, I will show you techniques that you can use to protect your application from attacks and intrusions.

There's three main topics covered here, each with a few subpoints and some code examples:

• Using a Database
• Use a Salt When Hashing
• POSIX: Drop Privileges When You Don't Need Them

Lorna Mitchell shares a quick code snippet she's worked up to make handling local-sensitive dates in PHP a bit easier (via the strftime function).

I needed dates like "Donderdag 23 Oktober", and I was sure PHP should know how to do this without me creating arrays for days of the week and months of the year. With some help from my friend (thanks Derick) I discovered that there is a date function in PHP that takes into account the locale of the script, called strftime.

Her code snippet shows how to set the correct local time (in her case, nl_NL with a UTF-8 encoding) and how to return a formatted string based on formatting characters (much like printf/sprintf).

The Zend Developer Zone has the latest two of their security tips posted today - numer #8 and #9 - in their "PHP Security Tips" series.

• In tip #8, they restate and reinforce a topic that's worth repeating - validating user input. They use the filter_var function as a simple, light way to start filtering your user's input.
• Tip #9 suggests that you keep anything sensitive, anything at all that needs to be kept away from prying eyes, outside of your document root of the site.

The Zend Developer Zone has the latest two of their security tips posted today - numer #8 and #9 - in their "PHP Security Tips" series.

• In tip #8, they restate and reinforce a topic that's worth repeating - validating user input. They use the filter_var function as a simple, light way to start filtering your user's input.
• Tip #9 suggests that you keep anything sensitive, anything at all that needs to be kept away from prying eyes, outside of your document root of the site.