Dieter Stinglhamber has a new tutorial posted to his site showing you how to build a Laravel application that doesn't use cookies...well, any cookies that could be used for tracking.

Since May 25th you have been harassed by "We have updated our privacy policy" emails but also websites started to great you with "Please, let us and our 256 partners track you".

In response to these abusive practices, some developers have decided to follow a better path, removing every cookie that is not needed. For example, my website doesn't have a single cookie, Spatie new website won't have any either. [...] I encourage every developer to do the same and if you are using Laravel, here's how you can (very) easily get rid of the default cookies set by the framework.

He talks about the two cookies that are used by default in Laravel applications: the CSRF token and the session ID. He shares ways to remove each of these cookies (if you're not using them) and, for a final "trick", removing other cookie-related middleware from the "web" group that interact with cookies.

In a recent post to his site Aidan Woods shares information (and code) related to the use of secure headers in PHP applications. He's even created a package to help make it easier to drop them into a new or existing project without too much trouble.

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP. By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project. The project, SecureHeaders is available on GitHub.

He starts by covering why he created the library and what it can help you with including making things like a CSP policy easier to maintain. The article goes on to talk about the Content-Security-Policy header is and what kind of prevention it applies. He also shares how the package displays errors, modifies cookies to secure them (HTTPOnly and Secure flags) as well as provide a "safe mode" that "place an upper limit on things like HSTS and HPKP, and remove flags like includeSubDomains or preload until the header is manually added as a safe mode exception, or safe mode is disabled."

In a new post to his site Aaron Saray has shared two tips that can help you protect the information in your PHP sessions - two configuration options to enable that can enforce stricter standards and options enhancing their overall security.

Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.

The two configuration options he mentions are ones that:

• force the session identifier to use cookies (versus also allowing it from the URL)
• enforce "strict mode" on the sessions

Each comes with a bit of description as to what the setting does and the recommended setting is to provide the most protection. One note, though: strict mode is only included in PHP 5.5.2 or greater.

In a new post to his blog Paul Reinheimer talks about replacing sessions with cookies and some of the (security) pitfalls that can come with it.

I’ve seen several instances where people have demonstrated the ease with which encrypted cookies can replace sessions within PHP. Michael Nitschinger wrote a piece recently demonstrating the switch with Lithium, while CodeIgniter does this by default (optionally encrypting). The problem is that while replacing sessions with cookies works, it introduces a few risks not present with native session support, and these risks tend to be under documented.

He gives an illustration of an attacker who sits between Amazon and one of their warehouses. Despite encrypting their order details, all it would take is the attacker to grab an order and copy it and resend (a "replay attack"). He's created an example application to illustrate the point (source on github). The attacker doesn't even have to know what the encrypted information contains - they only have to replicate it.

On WebReference.com today, there's this new tutorial with an introduction to getting PHP to interact with web forms.

HTML forms are one of the key ingredients of any dynamic website because they can enable the users of a site to interact with it. Otherwise, websites are more or less static:They may be driven by a database and, therefore, regularly changing, but they look the same for each and every visitor. HTML forms can change that; therefore, using data from forms from within PHP is very important.

They give examples of how to send data back to a script from a form, reading that data (using superglobals), and what data will be returned from each form element type. From there, they get into specifics like dealing with magic quotes and saving the form data into a cookie...

On WebReference.com today, there's this new tutorial with an introduction to getting PHP to interact with web forms.

HTML forms are one of the key ingredients of any dynamic website because they can enable the users of a site to interact with it. Otherwise, websites are more or less static:They may be driven by a database and, therefore, regularly changing, but they look the same for each and every visitor. HTML forms can change that; therefore, using data from forms from within PHP is very important.

They give examples of how to send data back to a script from a form, reading that data (using superglobals), and what data will be returned from each form element type. From there, they get into specifics like dealing with magic quotes and saving the form data into a cookie...