The Paragon Initiative has posted a new tutorial giving you a pocket guide version to securing your PHP application in 2016.

Please set aside most of what you've heard over the years; chances are, most of it just muddies the water. Security is not a product. Security is not a checklist. Security is not an absolute.

Security is a process. Security is an emergent property of a mature mindset in the face of risk.

Perfect security is not possible, but attackers do have budgets. If you raise the cost of attacking a system (your application or the networking infrastructure it depends on) so high that the entities that would be interested in defeating your security are incredibly unlikely to succeed, you'll be incredibly unlikely to be compromised.

The post talks about the "essence of security" and how most prevention methods don't even add much processing overhead or overall development time. He makes four recommendations of things to do in current and future development to help secure your applications:

• Use PHP 7 in All New Development
• Use HTTPS Everywhere
• Use Security Headers
• Use Trustworthy Reference Material

The post ends with a few other things to think about when building secure applications including raising the "cost" of attacking your system and keeping in mind that your platform may not be the attacker's "end game".

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It’s a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let’s review this powerful protocol through the lens of a web developer. We’ll tackle the topic in two parts. In this first entry, we’ll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

While not specific to PHP, security is something that all developers need to think about in their applications. To that end, the Infosec Institute has published this guide to helping you prevent SQL injection attacks that could come in via the HTTP headers of requests to your site.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren’t they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

• X-Forwarded-For
• User-agent
• Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

Brian Moon points out a (sometimes annoying) habit of PHP when it comes to newlines - it drops them after the closing tag.

Have you ever noticed that PHP eats the newlines after a closing PHP tag? Not sure what I mean? There is lots on Google about it. [...] So, why does PHP do this? Well, you have to go back 11 years. PHP 3 was emerging. I was just starting to use it for Phorum at the time. There were two reasons.

The first reason was the it, at least in the minds of the developers of the language, "removed all traces of PHP" from the script without any training newlines to show for it. The second case was a bit more valid - because lots of editors at the time required newlines at the end of every line of code. This caused loads of trouble tracking down things like the infamous "Headers already sent" issues (pre-output buffering).