News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Reddit.com:
Composer files being indexed by Google
December 10, 2014 @ 11:36:55

In an interesting thread on the /r/php subreddit on Reddit.com, a user noticed that Google is indexing Composer files that are in the document root of PHP applications. These files, like "composer.json" and "composer.lock" can provide detailed information about which packages and libraries are in use in the application (information disclosure).

The problem is that these files are placed in the web root of the application and not in a folder one level up, a recommended practice. The post links to a Google search that shows an example of current sites with the issue.

Another comment in the same post also reminds users not to have things like their ".git" files in the document root either as they can provide valuable information to would be attackers about your application's code. Things can be done to prevent direct access to these files in the web server configuration but it's far better to restructure the application to have them in a parent directory of the actual web root.

0 comments voice your opinion now!
composer files composerlock composerjson index google search engine security

Link: http://www.reddit.com/r/PHP/comments/2ourf7/composer_files_being_indexed_by_google/

SitePoint PHP Blog:
Installing and Securing Jenkins
December 01, 2014 @ 13:09:43

The SitePoint PHP blog has posted the first part of a new series of articles showing you how to use (and secure) Jenkins, the popular continuous integration tool, to bring more quality to your PHP-based applications.

Earlier this year, I wrote an article about PHP-CI, which you can use as a continuous integration tool for your PHP projects. Within this article I indicated I still liked Jenkins the most as a CI tool. Time to dive into Jenkins and see how we can set this up for our PHP project.

In this first part of the series helps you get Jenkins installed via a package and configure it on the server. He then gets into the steps to secure the installation: configuring users, turning off signups and the type of security to set up (they choose matrix-based). He wraps up the article with a look at installing some useful plugins and using a template to use as a base for setting up your projects.

0 comments voice your opinion now!
series part1 jenkins qualityassurance qa install security tutorial

Link: http://www.sitepoint.com/installing-securing-jenkins/

PHP.net:
PHP 5.4.35, 5.5.19 and 5.6.3 Released
November 14, 2014 @ 12:08:25

Several new versions of the PHP language have been released, including several bugfixes and security-related issues (including CVE-2014-3710. Updates are available for all current major versions:

Upgrading is recommended, especially if you're making use of the fileinfo functionality. You can get these latest versions from the main downloads page (or the Windows.php.net). You can find out about the other changes in these releases in the Changelog

0 comments voice your opinion now!
language release security update php54 php55 php56 fileinfo

Link: http://php.net/archive/2014.php#id2014-11-13-3

Pádraic Brady:
Security Oriented PSR Proposed to PHP-FIG
November 11, 2014 @ 11:56:42

Pádraic Brady has a new post to his site today talking about a security-oriented PSR that's being proposed to the PHP-FIG group (by Lukas Smith). The proposal suggests the creation of a security policy to be used by members of the PHP-FIG and a way to make sharing security issues more standardized.

Lukas Kahwe Smith recently brought forward an idea to PHP-FIG with two broad objectives for a new PSR: To write a security policy that could be adopted by members; and proposal to make sharing security vulnerabilities more common and standardised. He has invited interested people to express their interest in joining a separate mailing list to discuss the details: https://groups.google.com/forum/#!topic/php-fig/45AIj5bPHJ4. Larry Garfield of Drupal and Korvan Szanto of concrete5 CMS have offered to sponsor the proposal.

He talks some about security policies in general - what they are, why they're a good idea and what Lukas is proposing for PHP projects. He also briefly covers the publishing of vulnerability data, the different options for publishing them and how the standardization of it could be integrated with current tools (Composer anyone)?

0 comments voice your opinion now!
phpfig security standard reporting proposal discussion

Link: http://blog.astrumfutura.com/2014/11/security-oriented-psr-proposed-to-php-fig/

Three Devs & A Maybe Podcast:
I Want You Back
November 10, 2014 @ 09:19:34

The Three Devs and a Maybe podcast is back with their latest episode hosted by Michael Budd, Fraser Hart, Lewis Cains and Edd Mann. In episode #48, "I Want You Back", they talk about a wide range of topics including currency, git and passwords.

Two weeks in the making, we are finally back with another podcast installment. This week we touch upon the Unix philosophy, client drama, and shiny new MacBook Pros. We then move on to discuss the security concerns that have arisen from the introduction of contactless payment systems. Leading on from this we talk about the YubiKey and how it can be used to provide two-factor authentication, for services such as LastPass. Finally, we close with how 'tombstoning' your code trumps the dreaded commenting out every time.

You can listen to this latest episode either through the in-page player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed to get the latest episodes as their released!

0 comments voice your opinion now!
threedevsandamaybe podcast ep48 security yubikey git currency

Link: http://threedevsandamaybe.com/i-want-you-back/

Stanislav Malyshev:
unserialize() and being practical
November 04, 2014 @ 10:49:40

Stanislav Malyshev has a new post to his site talking about his proposal for a filtered unserialize change and why he sees it as a practical next step.

I have recently revived my "filtered unserialize()" RFC and I plan to put it to vote today. Before I do that, I'd like to outline the arguments on why I think it is a good thing and put it in a somewhat larger context. It is known that using unserialize() on outside data can lead to trouble unless you are very careful. Which in projects large enough usually means "always", since practically you rarely can predict all interactions amongst a million lines of code. So, what can we do?

He touches on three points that would make it difficult to just not use it this way (on external data) including the fact that there's not really any other way to work with serialized data in PHP. He suggests that by adding filtering to the unserialize handling of the language it can protect from issues around working with serialized external data.

Is this a security measure? [...] Yes, it does not provide perfect security, and yes, you should not rely only on that for security. Security, much like ogres and onions, has layers. So this is trying to provide one more layer - in case that is what you need.
0 comments voice your opinion now!
unserialize rfc filter practical security reasons

Link: https://php100.wordpress.com/2014/11/03/unserialize-and-being-practical/

Anthony Ferrara:
A Lesson In Security
November 03, 2014 @ 09:11:49

In his most recent post Anthony Ferrara gives a lesson in security prompted by the recent major issue with a SQL injection vulnerability in Drupal. He gets into detail about the vulnerability itself and the ultimate question: "how could this happen?"

Recently, a severe SQL Injection vulnerability was found in Drupal 7. It was fixed immediately (and correctly), but there was a problem. Attackers made automated scripts to attack unpatched sites. Within hours of the release of the vulnerability fix, sites were being compromised. And when I say compromised, I'm talking remote code execution, backdoors, the lot. Why? Like any attack, it's a chain of issues, that independently aren't as bad, but add up to bad news. Let's talk about them: What went wrong? What went right? And what could have happened better? There's a lesson that every developer needs to learn in here.

He details (complete with code examples) where the vulnerability was, how it could be exploited and what the resulting SQL would look like when it was abused. Fortunately, the fix for the issue was relatively simple, but fixing is easy - distributing that fix is much more difficult.

How did this happen? Everyone makes mistakes. Everyone. It's going to happen sooner or later. Heck, this vulnerable code was in the database layer since 2008, and was just discovered two weeks ago. That says something about how complex vulnerabilities can be.

He suggests that the bigger lesson here isn't about who made the mistake or even the code that caused it. It's more about how it was handled, and that, in using any kind of CMS/framework like this there's always risk. People are human, people make mistakes - "the key is how you deal with it".

0 comments voice your opinion now!
security drupal vulnerability detail lesson risk handle

Link: http://blog.ircmaxell.com/2014/10/a-lesson-in-security.html

PHP.net:
New Supported Versions Timeline Page
October 29, 2014 @ 11:18:40

The PHP.net website has introduced a new feature to help make it a bit clearer which versions of PHP are supported and which have reached their end-of-life mark. This new Supported versions page off the main site provides listings of currently supported versions and graphical timelines of past (and future) support milestones.

Each release branch of PHP is fully supported for two years from its initial stable release. During this period, bugs and security issues that have been reported are fixed and are released in regular point releases. After this two year period of active support, each branch is then supported for an additional year for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.

The page includes information on when the initial release in a series was made (like the 5.4.x or 5.5.x series), when active support did/will end and how long the timeline is for security fixes and support. As of the time of this post, PHP 5.3.x is the only series that has reached end-of-life, but the 5.4.x series is coming close being in security fix only mode now and EOL-ing completely in ten months.

0 comments voice your opinion now!
version support timeline page phpnet release bugfix security

Link: http://php.net/supported-versions.php

Fabien Potencier:
The PHP Security Advisories Database
October 27, 2014 @ 11:54:48

Fabien Pontencier has made an official announcement about a move to make the PHP Security Database the Symfony project started over a year ago. In the announcement he talks about the move to (hopefully) make it more widely adopted - pulling it out from under the Symfony namespace and into the FriendsOfPHP organization.

A year and a half ago, I was very proud to announce a new initiative to create a database of known security vulnerabilities for projects using Composer. It has been a great success so far; many people extended the database with their own advisories. As of today, we have vulnerabilities for Doctrine, DomPdf, Laravel, SabreDav, Swiftmailer, Twig, Yii, Zend Framework, and of course Symfony (we also have entries for some Symfony bundles like UserBundle, RestBundle, and JsTranslationBundle.)

[...] Today, I've decided to get one step further and to clarify my intent with this database: I don't want the database to be controlled by me or SensioLabs, I want to help people find libraries they must upgrade now. That's the reason why I've added a LICENSE for the database, which is now into the public domain.

The database has already been moved over to the FriendsOfSymfony organization and is still functioning with the SensioLabs security checker. You can find more on the database and its contents in this GitHub project.

0 comments voice your opinion now!
security advisories database public domain friendsofphp

Link: http://fabien.potencier.org/article/74/the-php-security-advisories-database

NetTuts.com:
Securing Your Server Login
October 22, 2014 @ 10:43:27

While PHP developers usually pay more attention to the code level of things, it's good to know something about managing the servers their applications live on too. In this most recent tutorial from NetTuts.com they introduce you to some of the basic things you can do to help secure your server against potential attacks, more specifically around the logins.

Thanks to the growing abundance of useful self-hosted apps such as WordPress and the affordable growth of cloud hosting providers, running your own server is becoming increasingly compelling to a broader audience. But securing these servers properly requires a fairly broad knowledge of Linux system administration; this task is not always suitable for newbies.

They provide a list of seven things to look at (not a comprehensive list, but good none the less) to protect your system logins:

  • Update Your System Components
  • Change Your SSH Port From the Default
  • Activate a Firewall
  • Change Your Root Login Name
  • Activate Google Two-Factor Authentication
  • Switch to Using SSH Keys for Login
  • Manage Your Application Security

Each item includes a summary of the "why" and commands or links to other resources with more information.

0 comments voice your opinion now!
server login security top7 list tips hosting

Link: http://code.tutsplus.com/tutorials/securing-your-server-login--cms-22001


Community Events





Don't see your event here?
Let us know!


composer language list symfony artisanfiles series tool introduction version laravel security voicesoftheelephpant release podcast library opinion community conference framework interview

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework