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

Check Point Blog:
Finding Vulnerabilities in Core WordPress: A Bug Hunter’s Trilogy, Part I
Aug 06, 2015 @ 11:44:14

The Check Point blog has posted the first part of a series from one of their vulnerability researchers about finding security vulnerabilities in the core WordPress code (and some of the results along with CVE numbers).

In this series of blog posts, Check Point vulnerability researcher Netanel Rubin tells a story in three acts – describing his long path of discovered flaws and vulnerabilities in core WordPress, leading him from a read-only ‘Subscriber’ user, through creating, editing and deleting posts, and all the way to performing SQL injection and persistent XSS attacks on 20% of the popular web.

In this first part he focuses on the concept of "identity" in a WordPress application. He focused on the "roles and capabilities" functionality to find bypass methods in operations like editing and adding new posts. As he works through his process, code is included from the WordPress core showing where the issue(s) lie and what would be needed to exploit the issue.

tagged: bug hunt wordpress vulnerability core code part1 series checkpoint

Link: http://blog.checkpoint.com/2015/08/04/wordpress-vulnerabilities-1/

Paragon Initiative:
Everything [About] Preventing Cross-Site Scripting Vulnerabilities in PHP
Jun 17, 2015 @ 12:19:29

The Paragon Initiative has posted a new tutorial that wants to provide you with everything you need to know about preventing cross-site scripting in PHP applications.

Cross-Site Scripting (abbreviated as XSS) is a class of security vulnerability whereby an attacker manages to use a website to deliver a potentially malicious JavaScript payload to an end user. XSS vulnerabilities are very common in web applications. They're a special case of code injection attack; except where SQL injection, local/remote file inclusion, and OS command injection target the server, XSS exclusively targets the users of a website.

[...] Cross-Site Scripting represents an asymmetric in the security landscape. They're incredibly easy for attackers to exploit, but XSS mitigation can become a rabbit hole of complexity depending on your project's requirements.

He introduces the concept of cross-site scripting (XSS) for those new to the term and provides a brief "mitigation guide" for those wanting to jump to the end. He then gets into some examples of what a XSS vulnerability could look like, both stored and reflected and provides the "quick and dirty" method for preventing them. He also mentions some tips in implementing your solution including avoiding HTML in your data if at all possible. He goes on to talk about the use of HTMLPurifier to prevent attacks, context-sensitive escaping (HTML vs JS vs CSS) and some of the browser-level features that help prevent XSS for the user.

tagged: prevent xss crosssitescripting security prevent vulnerability context browser

Link: https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know

Pádraic Brady:
PHP’s “Magic Hash” Vulnerability (Or Beware Of Type Juggling)
May 14, 2015 @ 12:19:43

Pádraic Brady has a new post to his site talking about the recently announced (but actually relatively old) issue with PHP hash comparison, the "magic hash" issues.

A while back, I noticed a flurry of activity around a somewhat obvious outcome of PHP’s type juggling antics. As the snowball gathered pace and grew, it’s being more widely reported as a vulnerability dubbed “Magic Hashes”. What is this mysterious potential vulnerability in PHP applications? The vulnerability is a straightforward outcome of PHP’s type juggling antics.

He talks about the == (double equals) versus === (triple equals), how they differ and how the use of the triple equals basically negates this issue. The problem comes back around to PHP's type juggling and how it assumes equality based on the data given. He includes some specific examples showing places the issue can happen even when comparing two variables of the same type. He also makes a mention of another issue that can come in separate from this called timing attacks and how to prevent them as well.

tagged: magichash vulnerability typejuggling timing attack doubleequals tripleequals

Link: http://blog.astrumfutura.com/2015/05/phps-magic-hash-vulnerability-or-beware-of-type-juggling/

Anthony Ferrara:
PHP Install Statistics
Dec 31, 2014 @ 09:29:43

Anthony Ferrara has a new post to his site sharing the results of some PHP version statistics he's gathered and how it relates back to the security of applications.

After yesterday's post, I decided to do some math to see how many PHP installs had at least 1 known security vulnerability. So I went to grab statistics from W3Techs, and correlated that with known Linux Distribution supported numbers. I then whipped up a spreadsheet and got some interesting numbers out of it. So interesting, that I need to share...

He starts with the versions that currently have no known security issues and matches those up with the linux releases that currently include them. He then looks at the adoption rates for more recent versions and maps those against the security status as well...with some "grim results". He summarizes the totals of all of the version results and comes up with an interesting statistic: over 78 percent of PHP installations (and thus applications) are vulnerable to some kind of security vulnerabilities just because of what they're hosted on.

tagged: install statistics security vulnerability issue percent

Link: http://blog.ircmaxell.com/2014/12/php-install-statistics.html

Anthony Ferrara:
A Lesson In Security
Nov 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".

tagged: security drupal vulnerability detail lesson risk handle

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

Evert Pot:
Composer's bug now fixed
Feb 24, 2014 @ 12:38:06

Evert Pot has posted an update to a previous post around Composer's vulnerability around installing the wrong packages in the case of a conflict. In this latest post he points out, however, that the bug is now fixed.

As an update to my previous post, the composer security problem now appears fixed. Good to see that a quick response was possible after all.

The original issue was caused by the "replace" functionality, allowing the possibility for an incorrect package to be installed instead of the one requested. Other posts with more details include this one from Pádraic Brady and Nils Adermann. if you're a Composer user, it's highly suggested you update your currently installed version (run a "composer self-update").

tagged: composer bug security vulnerability fix selfupdate

Link: http://evertpot.com/composer-bug-fixed

Pádraic Brady:
Composer: Downloading Random Code Is Not A Security Vulnerability?
Feb 21, 2014 @ 10:04:52

In his latest post Pádraic Bradyhas posted a response to a recent post stating that in issue in Composer where the wrong package could be installed is not a security issue. Pádraic disagrees, here's why:

The problem here is quite simple. A user defines a composer.json file that requires the package bloggs/framework. Someone else creates a package on Packagist.org called evil/framework whose own composer.json states that it replaces bloggs/framework. Next, a group of poor random victims, potentially thousands, use composer to install applications with a dependency on bloggs/framework. Composer does some internal wizardry and installs evil/framework when certain conditions are met. The victims didn’t request evil/framework but they get it anyway.

He suggests that this is a kind of remote file inclusion and possibly a remote code execution vulnerabilities. He points out that the manual steps suggested in the post aren't listed in the Composer documentation and fixes for it are still pending work.

Saying one thing, but acting like it’s the other thing you don’t want people to call it, makes me think it really is the other thing. Probably because it is. Users can fall victim to a replace and it’s called “unintuitive”, but if a package states that it replaces something that might lead to the unintuitive behaviour, it’s an abuse.
tagged: composer random code vulnerability security package

Link: http://blog.astrumfutura.com/2014/02/composer-downloading-random-code-is-not-a-security-vulnerability/

Pádraic Brady:
Getting Ahead In Security By Watching The Neighbours
Jan 18, 2013 @ 11:53:52

In his latest post Padraic Brady talks some about the recent security issues that happened with Ruby on Rails that allowed for remote code execution and how, if you use code blindly, you could be in for a similar fate.

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail’s case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of “buried” code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby’s dark magic, e.g. eval(), include(), require_once(), system() and, let’s not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise…

Pay attention to competing applications or frameworks – their problems may also be your problems. If you’re worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters’ might originate from.

tagged: rubyonrails security vulnerability code execution yaml symfony2


5 More PHP Security Vulnerabilities
Nov 13, 2012 @ 14:42:02

On PHPMaster.com there's a continuance of a previous article about security in PHP applications talking about a few more considerations when trying to make things secure.

In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you’re developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn’t do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.

He talks some about the settings that you might need to tweak in your "php.ini" server-side configuration file, some hints on filtering data (like using filter_input) and what to watch out for with error reporting. He also mentions session fixation and the protection of user data and passwords to keep them out of the hands of would-be attackers.

tagged: security vulnerability tutorial phpini filterinput session fixation user


PHP 5.4.3 and PHP 5.3.13 Released!
May 09, 2012 @ 07:10:36

The PHP project has released another update to both the 5.3.x and 5.4 revisions of the language correcting the bug that was found dealing with a flaw in CGI-based setups.

The PHP development team would like to announce the immediate availability of PHP 5.4.3 and PHP 5.3.13. All users are encouraged to upgrade to PHP 5.4.3 or PHP 5.3.13 The releases complete a fix for a vulnerability in CGI-based setups (CVE-2012-2311). Note: mod_php and php-fpm are not vulnerable to this attack. PHP 5.4.3 fixes a buffer overflow vulnerability in the apache_request_headers() (CVE-2012-2329). The PHP 5.3 series is not vulnerable to this issue.

Users are encouraged to upgrade their applications, especially those using CGI-based setups. You can find the latest source on the downloads page and the Windows binaries on windows.php.net.

tagged: release bugfix cgi apache vulnerability attack