Related to this other post about content security policies in PHP sites, DashExamples.com has a quick new post about what you'll need to add to your application to implement a policy of your own.

Content Security Policy(CSP) is a mechanism in the browser that restricts what content will be requested and run by the browser. CSP does this by passing in a specific response header that tells the browser what resources (images, javascript, css, frames, etc) can be requested and accepted to execute. There are multiple ways to setup CSP for your web site, you can use your web server configuration like I showed in a previous example or use a dynamic scripting language like PHP.

What it really boils down to is setting a header, either X-Content-Security-Policy or X-Content-Security-Policy-Report-Only, to tell the browser what security policy to use and how to honor it. You can find out more about content security policies from this page on the Mozilla wiki. CSPs allow you to define how your site's content interacts and help to prevent issues like XSS and data injection.

On the Dream In Code forums there's a recent post showing you how to prevent mail() header injections when taking user input, like from a form.

PHP's mail() function is a very useful and powerful function, even to the point that it is very easy to exploit. A way hackers exploit this function is a method called email header injection. [...] I'm sure most of you can already tell that's not going to be pretty since we didn't check the user input and so forth. PHP provides us with functions such as filter_var which will validate user input and either return false if the validation fails or return the filtered data.

He includes an example of using this filtering methods to check the user input for malicious information - validating that the "to" address is a valid email (FILTER_VALIDATE_EMAIL) and a sanitize() method that removes things like newlines, carriage returns and a few other characters.

In a recent post to his blog Artur Ejsmont looks at an attack that could potentially leave a hole open in your PHP-based application for a cross-site scripting (XSS) attack - HTTP response splitting (mail headers too).

There are two similar security issues both taken care of by Suhosin patch and strict escaping/encoding rules. They both relate to injecting new lines into headers of network protocols. They are not very well known and i think its worth mentioning it. HTTP response splitting is a web based attack where hacker manages to trick the server into injecting new lines into response headers along with arbitrary code. If you use GET/POST parameters in the headers like cookie or location, then someone could provide new lines with XSS attack.

He gives some examples of how it might work via the header function so that superglobals might be abused (like adding information on the URL to inject into $_GET). To prevent the attack, you just have to ensure that no special characters make it into the headers or cookies. He also mentions that the Suhosin patch takes care of the issue automatically.

If you've ever come up against an error when trying to compile the pecl_oauth package (from the PECL repository), you might take a look at this new post from Lorna Mitchell on how she solved the issue and got the compile running smoothly again.

When I tried to install from PECL, it grabbed the files, ran the configure step but stopped with an error status during make. [...] Closer inspection showed this line around the point things started to go wrong: Error [...] pcre.h: No such file or directory. I didn't have the header files for pcre installed - in ubuntu the headers are in the -dev packages.

A quick call to "aptitude" to grab and install those development libraries and she was back up and running. She's running Ubuntu, but this tip is cross-distribution - you'll just have to use the package manager (and package name) of your distribution's choice.

Jozef Chutka was working on a Flash-based application and, in trying to optimize it, figured that he'd set up an image caching system to keep the app from having to grab the images each time. The result is shared in this post - a simple tool that relies on HTTP headers to notify the client if anything's changed.

I can not hold all of those [requests] within flash player cache because some of them may change, and I also want shortest possible respond times and client-server traffic reduction as well as server side computing reduction. That's where browser caching comes into the scene. I have experimented a bit with all possible http headers to understand each browser specifics and I came with a solution.

He includes a snippet of code that shows how it would check the current image and send the correct headers as to whether or not it needs to be updated from the cached version the application has. This also keeps you from having random parameters in your requests because the server always assures the content is fresh.

Brian Moon has a new post to his blog today looking at something it's common for web applications to use, ob_start, and what about HTTP headers makes it work to prevent the infamous "headers already sent" message.

HTTP is the communication protocol that happens between your web server and the user's browser. Without too much detail, this is broken into two pieces of data: headers and the body. The body is the HTML you send. But, before the body is sent, the HTTP headers are sent.

He includes a sample raw HTTP response for a page and how the ob_start function works to buffer the output of the resulting page to save the header information until the buffer is echoed or cleaned out. There is a down side he mentions, though - there's no partial buffering built in so it's an all or nothing short.

One of the most popular reasons to use the header function in PHP applications is to do a redirect, but the webshop.com blog wants to remind you that there's more to it than just that.

If you are a web developer and you've ever worked with PHP you have probably come across the PHP header() function in the past. You most likely used it to implement a hard redirect; but you may not have understood exactly what was happening behind the scenes every time you call this handy function. Let's take a look at what the header() function does and find some uses for it other than its most common use-redirects.

They look at what the header function is for, what HTTP headers are (and some examples) as well as a few examples of use outside of redirects including defining content types, response codes and cache control.

Hasin Hayder has a quick post about taking a URL in the opposite direction than most seem to go these days - from shortened to the long, full URL.

Now when you get the short url shortened by using any of these services, you dont know where your browser is taking you! so if you are interested to figure out the original url hiding behind these short url, you need to have a little knowledge on how these services actually work.

Then the short URL is hit, the HTTP response is in the 300 family and the browser is redirected to the correct location. He uses cURL in PHP to grab this header information and parse out the full-length URL to return both the URL requested (the shortened one) and the full-length it was generated to point to.

DevShed has posted the latest article in their "introduction to views in CodeIgniter" series - a look at working with the views to add more layout/design to them with CSS.

Now it's time to continue exploring the capabilities given by CodeIgniter when it comes to handling views. Since the visual appearance of the web page mentioned above was pretty rudimentary, in this second article I'm going to improve it a bit to make it look more appealing and professional.

To add in their CSS, they update their header_view.php file to includes the styles in the template. The views for each block are then loaded via the controller - header, content and footer areas.

On the CSS-Tricks.com site today there's a quick tutorial on changing up the look and feel of your site based on an external source. More specifically, they give the example of updating the graphics of your site depending on the weather in your area via PHP and CSS.

Using a little magic and trickery (read: PHP and CSS), we can change the appearance of a website automatically based on the weather outside, in real time! In the example site we have created, the header graphic will change to one of four different styles based on Sunny, Rain, Snow, and Cloudy.

Their example makes a request to the Yahoo! weather data for a location and brings it in to PHP where the XML is parsed (via a regular expression) and the current conditions are parsed out. This condition is then passed out into the page as the class type on the header and, based on the CSS already defined, the correct image is pulled in as the background.