News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Barry vd. Heuvel:
CSRF Protection in Laravel explained
February 23, 2015 @ 11:52:59

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).

0 comments voice your opinion now!
csrf protection laravel laravel5 middleware xcsrftoken header


Pádraic Brady:
Stateful vs Stateless CSRF Defences Know The Difference
August 13, 2013 @ 09:49:00

In this new post to his site, Pádraic Brady looks at two methods for generating CSRF (cross-site request forgery) tokens to help protect your application. It's not a tutorial, per se...more of a comparison of two methods: stateful and stateless CSRF tokens.

The difference between Stateful and Stateless CSRF defences is that the former requires storing the CSRF token on the server (i.e. session data) while the latter does not, i.e. the server has zero record of any CSRF tokens. As far as the server is concerned, the number of parties with persistent knowledge of a valid token is reduced to just one - the client. [...] Let's compare both types of CSRF protections.

He introduces the concepts behind both types of token generation, pointing out that most of the PHP frameworks out there rely on the stateful option (the "synchronizer" method). The other method ("double submit") actually involves two tokens, one in the POST content and the other as a cookie value. He also dissects this other stateless concept article he found and how its method of generation may not be ideal.

Like most attacks, CSRF does not exist in isolation so developing a good defence requires mitigating other attacks. [...] Any good CSRF token implementation, whether stateful or stateless, should reflect those requirements with features for limiting tokens by scope and time.
0 comments voice your opinion now!
csrf token stateless stateful difference doublesubmit random synchronizer


Joseph Scott:
Stateless CSRF Tokens
August 02, 2013 @ 11:16:44

Joseph Scott has a recent post to his site looking at the idea of stateless CSRF tokens and how to create them while avoiding the typical "store them in a session" mentality.

This is all fine and good until you want to avoid using PHP sessions. Perhaps you have several web servers and don't want to deal with shared session storage. Or have servers in multiple data centers and don't want to try and sync state across them. What ever the reason, popping a token into $_SESSION isn't an option in this case. In short you want some sort of stateless CSRF token.

He looks at two methods to help get around this issue. The first method is based on known values that won't change very frequently (say, maybe 24 hours). His second method, however, has a bit more strength to it. His idea uses a combination of a key, the current time, a timeout and a known string of data - all base64 encoded.

0 comments voice your opinion now!
csrf token stateless tutorial session base64 timeout microtime


Anthony Ferrara:
Preventing CSRF Attacks
February 20, 2013 @ 09:36:41

Anthony Ferrara has written up a new post to his site looking at efective use of CSRF tokens and a few different strategies for generating them.

There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

0 comments voice your opinion now!
csrf attack prevention overview token generation tutorial

Kevin Schroeder:
Generating secure cross site request forgery tokens (csrf)
February 11, 2013 @ 11:23:10

In this new post to his site Kevin Schroeder has a new post with his take on generating more secure CSRF tokens for use in your site.

In researching the second edition for the IBM i Programmer's Guide to PHP Jeff and I decided to include a chapter on security since we really didn't talk much about it in the first edition. I'm talking about cross site request forgeries right now and I wanted to make sure that what I was going to suggest would not break the internet in some way. I did some Google searching to see what other people were recommending.

Most of the examples he saw used md5, uniqid and rand to create a randomized hash. He suggests an alternative - a method using the hash_hmac and openssl_random_pseudo_bytes methods to generate a sha256 hash for use in your page's submissions.

0 comments voice your opinion now!
csrf token generation hmac openssl
8 Practices to Secure Your Web App
February 04, 2013 @ 12:56:40 has posted a new article with some high level security tips and reminders for PHP developers when wanting to help prevent issues with their applications. The article provides eight tips, each with a brief description.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

0 comments voice your opinion now!
secure application tips xss csrf sqlinjection file session error include

Anson Cheung:
Top 6 security attacks in PHP
August 09, 2012 @ 17:03:55

Anson Cheung has posted about some security attacks (six of them) that you need to watch out for when developing your apps.

Be aware of the most common security threats to PHP applications is the important step to secure your PHP scripts may not be immune. Here, the article is going to go over top 6 common security threads in PHP scripts. You may familiar with this, if not, this is a good time for you to read and keep in mind.

The top six on his list are:

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Session fixation
  • Session capturing/hijacking
  • Cross-Site Request Forgeries (CSRF)
  • Code Injection

For each item, he includes a bit of explanation as to what the issue is and a common solution as to how to prevent it.

0 comments voice your opinion now!
security attack xss csrf session sqlinjection code

Henrik Bjørnskov's Blog:
Symfony2 Add Cross Site Request Forgery protection to login forms
December 30, 2011 @ 10:28:42

In a new post to his blog Henrik Bjørnskov has a tip on preventing cross-site request forgeries in your Symfony2 forms with the help of a simple Symfony2 configuration setting.

When talking with @jmikola on #Symfony-dev this afternoon we got into the subject of cross site request forgery and symfony2 login forms. And it seems that form-login already supports this but neither of us knew how it worked. So here is another quick tip. This time about securing you login form from cross site attacks.

The key is to define a "csrf_provider" in your security.yml config file and point it to the "form.csrf_provider" provider. He also includes the controller and view code/templating you'll need to get the token included in the form (and validated).

0 comments voice your opinion now!
symfony2 framework security crosssite request forgery csrf form
Preventing Cross-Site Request Forgeries
September 28, 2011 @ 10:12:11

SitePoint' has a new tutorial posted today from Martin Psinas about some tactics to prevent cross-site request forgeries from happening in your PHP application. The article introduces key concepts of CSRF and how you can keep it from happening in your code.

Cross-site request forgery (CSRF) is a common and serious exploit where a user is tricked into performing an action he didn't explicitly intend to do. This can happen when, for example, the user is logged in to one of his favorite websites and proceeds to click a seemingly harmless link. In the background, his profile information is silently updated with an attacker's e-mail address. [...] Any action that a user is allowed to perform while logged in to a website, an attacker can perform on his/her behalf, whether it's updating a profile, adding items to a shopping cart, posting messages on a forum, or practically anything else.

He shows it to you "in action" with a PHP script for a basic login page that takes a username and password, does some filtering and sets the username to the session. Their "harmless.html" file offers a link to the site's "process" page with a logout action that would allow the "harmless" file access to the current session if clicked. To prevent this from happening, they suggest a unique token be included in interactions on your site. This key is checked against a token in the current session (or other location) and is only valid if they match.

The Symfony framework has included this as a part of their forms for a while now and includes automatic handling to check its validity. Solutions also exist for other frameworks like Zend Framework and many others.

0 comments voice your opinion now!
csrf crosssiterequestforgeries crosssite security token

Michael Nitschinger's Blog:
Securing Lithium Forms
June 08, 2011 @ 12:03:23

Michael Nitschinger has a new post to his blog today showing how you can secure the forms in Lithium using the handy CSRF token implemented directly in the framework.

CSRF (Cross-Site-Request-Forgery) attacks work by sending arbitary (form) requests from a victim. Normally, the receiving site (in our case the Controller who processes the form data) doesn't know where the data comes from. The CSRF protection in Lithium aims to solve this problem in an elegant and secure way. You can read more about those attacks here. Note that you'll need to clone the latest master branch of Lithium if you want to try it out now.

There's two parts to the protection, one on either side of things - a field in the form output and a check in the controller to see if the submitted value is correct. He includes code for a simple form (a title field and submit button) that lazy loads the Security helper and generates the token for you. He walks through the controller side of things a line at a time and includes a sample logging/forwarding bit in the second example to redirect users when the CSRF check doesn't pass.

0 comments voice your opinion now!
secure lithium framework form csrf security

Community Events

Don't see your event here?
Let us know!

community list opinion podcast extension version language example series framework laravel php7 release voicesoftheelephpant introduction library laravel5 security api interview

All content copyright, 2015 :: - Powered by the Solar PHP Framework