On the Evozon blog there's a post that provides "a brief reality check to developers about GDPR" and how it effects them and their applications. GDPR (General Data Protection Regulation) is a regulation passed in Europe that enforces certain requirements about personal data and how it should be handled.

If you`re reading this, it means you`ve already heard about it or you`re about to receive some flash-news: there`s a new all-encompassing data privacy regulation in the EU. Ready or not, 25th of May 2018, the date when the General Data Protection Regulation (GDPR) becomes effective, will wait for nobody. If there’s any buzz around it, it`s because of a good reason: businesses will have to comply, software will have to evolve.

While there is still some uncertainty around certain parts, the article goes through some things you can do to help you prepare and make your application compliant including:

• discovering and documenting the purpose of the data that is being collected
• providing clear notification of data collection for the user
• define retention periods and deletion policies
• tracing any changes that happen with the data

The article does a good job providing a "checklist" of sorts you can use to ensure you're compliant. Of course, it's by no means an actual method of compliance but it does provide a good list to guide you in the right direction.

The Fortrabbit blog has a post that want to help you store your database password securely and away from prying attacker eyes. While they use the example of a a database password, credentials for just about any other service could be protected the same way.

How do you protect your access data? Your sensitive secrets, basically anything your PHP application uses to authenticate or authorize with other services such as databases, caches, cloud storages, image resize services, transactional mail providers. All of them. Where do you put this — easily accessible while in development and secure for production?

They start by pointing out a few places where they should not be stored: in your code, in a version control system or in an environment variable (plain text). Instead, they suggest using a combination of a secret key that's configured in the application and encrypted versions of the values in environment variables. Some code is included showing how to set this up in a Laravel-based application, but the principle can be applied independent of the framework too with some other simple tools. They end the post with some links to other articles including a "considered harmful" piece reinforcing their methods.

Barry vd. Heuvel has a recent post to his site explaining how the Laravel framework has implemented CSRF protection natively. CSRF is short for Cross-site request forgery and is a type of security vulnerability.

In this blog we take a closer look into CSRF protection in Laravel. We compare the difference between the CSRF filter in Laravel 4 and the current VerifyCsrfToken middleware in Laravel 5.

He start with a quick look at why CSRF protection is even needed and what kind of problems it can cause. He shows how the CSRF protection was enabled in the Laravel 4 routing and how, in Laravel 5, the token evaluation was updated to use the hash_equals to prevent timing attacks. He then gets into the details of the middleware and how it handles the protection for you (including detection and use of the X-CSRF-TOKEN header).

In a new tutorial from the SitePoint PHP blog today Jeroen Meeus looks at a way to protect parts of your application from being used and abused. He shows you how to protect various parts of you site, including images and actual pages, with the help of either your web server or bits of code.

When building an awesome web app or website, we sometimes want people to be able to embed parts of our web app/website into their own. That could be an iframe holding a ‘like’ button, a simple image that they want to reuse or even our entire app embedded in an iframe. But how do we control who has access, who is allowed to use up our bandwidth and query our service? We define the problem as controlling access to assets. By assets we mean: anything that can be queried from our site.

He talks about the problem of "lifting" content and how to fall back to a "deny all, allow some" mentality. He starts with examples of Apache configurations that use mod_rewrite to only allow requests that come from the current domain (trusted) and the "files" directive coupled with Deny/Allow. He also includes an nginx example, showing the same request handling. The code examples show how to use PHP and Javascript to prevent access the same way.

On the Dreamincode.com forum there's an interesting approach mentioned for security login forms from brute-force attacks using a queueing system rather than the usual real-time requests.

Login forms in online systems are often easy targets for brute-force attacks; attacks designed to go through all possible values (or at least all probable values) for a password to "guess" a correct one. Securing your forms from such attacks is important, but it can be tricky to do in an effective manner without adversely affecting the user experience of your normal user. The method I am suggesting in this article is that of queuing login attempts in an effort to limit how many attempts an attacker can execute per second. [...] So, how do we implement this in PHP?

He suggests using a MySQL-based queueing system (but it could easily be replaced with one of the *MQ types) that tracks users versus login attempts. He's put together a library that handles the storage and login attempt management. He takes some time to explain the functionality of the class and how to put it to use.

Elijah Horton has a recent post to his site sharing a tool he's developed to sandbox and validate PHP code of user-contributed code.

Few quotes related to the PHP language are as pithy and resoundingly accurate as the phrase: "Eval is evil." The reasons are myriad: the eval() function basically gives whatever code is passed to it unlimited control of the parser, and this freedom makes eval() both a temptation for developers, who may need to dynamically control PHP at runtime, and a panacea for hackers who are ever-searching for more servers to add to their botnets. So, how does one make use of the extreme power available through runtime evaulation of PHP, without exposing one's server to near-certain rooting? Through a sandbox.

His tool - PHPSandbox, uses the PHP-Parser library to deconstruct the PHP code its given and look for issues. He gives an example of a call to mail and how it would catch the issue. He shows how to install it via Composer, how to configure it with whitelisted methods/functions. It also includes a way to overwrite function calls with a bit safer alternative.

Gareth Heyes has posted about some bypasses that he's found for getting around the XSS Auditor functionality in some browsers:

I had a look at XSS Auditor for a bit of fun because Mario said it’s getting harder to bypass. Hmmm I don’t agree. I seem to remember the same flaws are present from the last time I checked it with a little variation. It is also a very limited XSS filter not supporting detection of script based attacks (very common).

He includes three of his own bypasses - using a "formaction" on the submit input in a form, using "target" to override the iframe external resource restriction and the injection of a specially placed anchor tag. Each of these comes with a proof-of-concept example and another is also included courtesy of Mario Heiderich.

On the Script Tutorials blog today there's a good summary post reminding you of some of the common security issues that your web application can face, mostly due to improper validation and filtering.

Our new article focuses on security in web. Many beginners (and not only) web programmers sometimes can make mistakes when developing its web applications. Our article is intended to eliminate potential gaps in knowledge web developers. It is quite possible that you already know something, but I’ll be incredibly happy if you learn anything new. Today we learn about most popular exploits (with samples).

Security issues that made their list include:

• SQL injections
• Cross-site scripting/Cross-site Request Forgeries
• Remote & local file inclusion
• Displaying errors on production
• Including .svn (or any version control meta) files in the production release

In a recent post to his blog Jason Stiles takes a look at some of the things you can do with PHP to help protect your site from XSS (cross-site scripting attacks) with some basic filtering.

Cross-Site Scripting (XSS) is a type of attack where a hacker attempts to inject client-side scripting into a webpage that others are able to view. The attack could be as simple as an annoying alert window or as sophisticated as stealing a logged in user's credentials (commonly saved in browser cookies). [...] Since these types of user input can immediately be displayed to other user's, the attack could be spread pretty quickly and even without your knowledge.

He provides a basic function to get you started filtering the input from your users - a "xss_protect" method that takes in the data, whether to strip HTML tags or not and an optional set of allowed tags if you do. He also asks for opinions and better methods in his comments:

No solution is going to be perfect, but at least now you have a head start! If you have ways of improving this function, let myself and everyone else know in the comments.

In a recent post to the Web Development Blog they talks a look at some methods you can use on your site to help reduce the amount of spam sent to email addresses by protecting them from scripts that might harvest them right from the page.

There are lots of spam bots checking the Internet for email addresses on regular websites, forums, blog and mailing lists. Once caught by some spam bot your mailbox is in need of a strong spam filter or sometimes it might be better to use a new e-mail address. In this article we show you different ways, how you’re able to show your e-mail address to human visitors and hide it for spam bots.

They give four solutions, some a bit more practical than others - using an image instead of the text-only version of the address, hiding the @ symbol, hiding it with PHP (converting it to ASCII) and using Javascript to handle it similarly.