Imagemagick, a well-used alternative by PHP developers for graphics manipulation (an alternative to GD) has had several new vulnerabilities announced. These vulnerabilities allow for everything from remote code execution to initiating network requests. The Imagetragick site has more information:

There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.

A number of image processing plugins depend on the ImageMagick library, including, but not limited to, PHP’s imagick, Ruby’s rmagick and paperclip, and nodejs’s imagemagick. If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities.

There's two mitigations listed to help with a more immediate fix: using a policy.xml file and verifying that image data starts with the right "magic bytes". The site also shares more information about the different vulnerabilities and what kind of attacks they could allow. It is highly recommended that you add the mitigations they show and update your installation to use the latest release (7.0.1-1) with fixes for these issues.

In this new post (and this related article) Pádraic Brady shares some of his opinions about default security languages should provide and the Secure by Design principles.

Odd though it may seem, this principle explains some of PHP’s greatest security weaknesses. PHP does not explicitly use Secure By Design as a guiding principle when executing features. I’m sure its in the back of developers’ minds just as I’m sure it has influenced many if their design decisions, however there are issues when you consider how PHP has influenced the security practices of PHP programmers. The result of not following Secure By Design is that all applications and libraries written in PHP can inherit a number of security vulnerabilities, hereafter referred to as “By-Default Vulnerabilities”.

He focuses on what he sees as a responsibility of those creating the language to either default to a more secure architecture or provide information as to why their choices could cause problems. In the extended version of the post, he talks about some specific issues that the language has including SSL/TLS misconfiguration, openings for XML entity injection attacks and limited native filtering for cross-site scripting.

Rochak Chauhan has come up with a list of ten things, some security problems that could be lurking in your applications waiting to pop up at the worst time. Here's his list:

• Unvalidated Parameters
• Broken Access Control
• Broken Account and Session Management
• Cross-Site Scripting (XSS) Flaws
• Buffer Overflows
• Command Injection Flaws
• Error Handling Problems
• Insecure Use of Cryptography
• Remote Administration Flaws
• Web and Application Server Misconfiguration

Each item on the list has a bit of detail (and sometimes some code) to help point out the problem. Some of them even have references to external sources and packages to help you solve the problems.

On PHPBuilder.com, there's a new tutorial about validating user sessions - ensuring that data in your user's sessions is valid and isn't an attack trying to sneak in.

In a nutshell, sessions are the way that we "maintain state" from one page to the next, that is, how we identify specific users across multiple page requests. The ability to track users as they go from one page to the next using sessions allows us a number of options, such as tracking where they are going (web statistics) or to verify credentials for a specific section of the site.

First, there's a little mini-intro to sessions for those unsure on their use. It's followed by a look at some session vulnerabilities that could be introduces by malicious users looking to break things on your site (including HTML/Javascript injection, as their example shows).

They recommend a three step plan to get started with the validation of your user's sessions - making it easy for users to log out when they want to, use unique aspects of the remote machine to define the session and to validate all user input, especially things that will be put into a session variable.

Pierre-Alain Joye has posted a reminder about an event happening on the 29th of January (2007) with Damien Séguy in Paris concerning PHP security.

He will focus on the XSS and CSRF aspects of the web applications: sources of the vulnerabilities, attacks/exploits and the defense techniques. I will sadly not attend but such events are rare enough to be mentioned loudly.

The talk is a part of this meeting and requires a RVSP to attend, so if you'd like to attend, please sign up today.

Pierre-Alain Joye has posted a reminder about an event happening on the 29th of January (2007) with Damien Séguy in Paris concerning PHP security.

He will focus on the XSS and CSRF aspects of the web applications: sources of the vulnerabilities, attacks/exploits and the defense techniques. I will sadly not attend but such events are rare enough to be mentioned loudly.

The talk is a part of this meeting and requires a RVSP to attend, so if you'd like to attend, please sign up today.

According to this article from LWN.net, you might need to be a bit wary of how you use the allow_url_fopen configuration parameter on your server. Apparently there are some remote file inclusion issues that could cause problems for calls to include or require already in your code.

An attacker's fondest wish is to be able to run their code on the target system; an RFI exploit does just that. By exploiting two very dubious 'features' of the PHP language, an attacker can inject their code into a PHP program on the server.

Basically, if the potential hacker can manage to get in on a varaible that's inside of an include and use it (in)correctly, they can get the script to jump out and run the code from their server instead of the local copy. Turning off regiter_globals will provide some protection, put poor programming and not performing any input validation can poke holes in the script's security without the need for globals.

Check out the rest of the article for more information on this (potentially) serious issue and check your code/configuration doubly to make sure you're not at risk.

According to this article from LWN.net, you might need to be a bit wary of how you use the allow_url_fopen configuration parameter on your server. Apparently there are some remote file inclusion issues that could cause problems for calls to include or require already in your code.

An attacker's fondest wish is to be able to run their code on the target system; an RFI exploit does just that. By exploiting two very dubious 'features' of the PHP language, an attacker can inject their code into a PHP program on the server.

Basically, if the potential hacker can manage to get in on a varaible that's inside of an include and use it (in)correctly, they can get the script to jump out and run the code from their server instead of the local copy. Turning off regiter_globals will provide some protection, put poor programming and not performing any input validation can poke holes in the script's security without the need for globals.

Check out the rest of the article for more information on this (potentially) serious issue and check your code/configuration doubly to make sure you're not at risk.

Recently , Google has released a new service for their search engine, the Google Code Search. It allows for developers to look through and locate items in public source code through the simple Google interface we're all used to. Fortunately, there's also a few security problems the site can help with as well, and Chris Shiflett shares some of these in his latest post.

Stephen de Vries sent an email to SecurityFocus's web application security mailing list earlier today to comment on the new Google Code Search: "Google's code search provides an easy way to find obvious software flaws in open source and example applications."

Chris talks about cross-site scripting problems, issues with the superglobals, SQL injection problems, and even a misplaced trust of the $_SERVER superglobal. Each of the items is linked to is search terms on the Code Search to make it easy to locate.

Recently , Google has released a new service for their search engine, the Google Code Search. It allows for developers to look through and locate items in public source code through the simple Google interface we're all used to. Fortunately, there's also a few security problems the site can help with as well, and Chris Shiflett shares some of these in his latest post.

Stephen de Vries sent an email to SecurityFocus's web application security mailing list earlier today to comment on the new Google Code Search: "Google's code search provides an easy way to find obvious software flaws in open source and example applications."

Chris talks about cross-site scripting problems, issues with the superglobals, SQL injection problems, and even a misplaced trust of the $_SERVER superglobal. Each of the items is linked to is search terms on the Code Search to make it easy to locate.