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.

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.

Operator precedence parsers are very simple on the surface. So don't feel in the least bit intimidated, because by the time you've read through this I hope to have you walk away with a solid foundation on how to write your very own operator precedence parser. The goal is to understand how to solve the problem of operator precedence parsing, and not necessarily to write your own parser. Learning how the problem can be solved is the most important thing to take away from this article.

He starts with an introduction to the concepts behind "operator precedence" including processing order and grouping. He also mentions infix and postfix (RPN) notations for handling different formats of equations. He used the "Shunting-yard Algorithm" and how it relates to handling the different parts of the equation, one at a time, in the correct order. He rest of the post is dedicated to the details of the execution in the tool, including code examples and the tokenization of the strings passed into it.

I've written about Google and OAuth before, but that was OAuth v1.0, and they are introducing OAuth2 for their newer APIs; in this example I was identifying myself in order to use the Google Plus API. [...] OAuth 2 doesn't need an extension or any particular library as it doesn't have the signing component that OAuth 1 had, and OAuth 2 also has fewer round trips. It does require SSL however, because the requests are in the clear.

She includes some code snippets with an example of a connection - making a request to the remote HTTPS resource, adding some parameters to the URL (including the response type, your client ID and a redirect url). The response then contains the "code" value you'll need to make the second request to fetch the access token you'll need on future requests. You can find out more about the interface she's accessing in these docs about the Google Plus API.

After looking around for a while [for a good resource on compilers] I settled for Terence Parr's Language Implementation Patterns. This is exactly what I needed - bit sized patterns on compiler and parser design with working code. The book provides a recipe style approach, gradually moving from simple to complex compiler/parser design issues. As I primarily work with PHP, I thought of porting some code to PHP to see how it works.

He shows examples using his custom tool to show a basic lexer output for a list and a complete listing of the code involved. Ultimately, though, he finds that PHP isn't overly suited to the task - anything more than his simple example could be more trouble than it's worth.

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.

I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. [...] This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.

In this latest post, she talks about the three different types of tokens - consumer, request and verififier - and how to use them to locate a user in your app's users. Her code validates the request token and verifier against the database and, if successful, inserts the rest of the token information for the user.

Zend Framework has pretty good OAuth consumer implementation. However, it has no support for implementing OAuth provider, and it turns out that there aren't many other libraries for it. Most examples out there base on PECL oauth extension, which works just fine, with one caveat - you have to have this PECL extension installed, while ZF implementation does not require that. So I went ahead and wrote some code that allows to easily add OAuth provider to your ZF-based or ZF-using application. That should make writing OAuth provider easier.

His code just fleshes out the server portion of the provider, not all of the token generation and key handling it'll need on the backend - that'll still be the job of your scripts. You can find the library over on github in his Zend_OAuth_Provider repository.

OAuth is great - there's no need to save users' passwords, it's - in theory - a consistent way to interact with other services, and it's hopefully something that your users are familiar and comfortable using. But if you're not just interacting with your users' accounts - for example, your application uses a single account on a service to broadcast messages, or analyze data - getting or renewing the access token can be painful.

He illustrates the problem with an example connecting to Twitter and even points out a script that makes bridging this gap simpler. Unfortunately, it's not exactly what he needed, so he reworked the idea with a call to the Twitter API using a Zend_Oauth_Consumer and a custom callback. The script is then set up with some command line options for inputting the key and secret information. Also included is functionality letting you define a configuration file. You can see the final result here on github.

The consumer requests a request token (see my earlier post about consuming OAuth), and as a provider, we need to handle that request. In my example, I chose to pass the variables as GET parameters, but you could adapt this to handle POST variables or information contained in HTTP headers.

She includes the code (using the functionality of the pecl_oauth extension) to provide a token and the three functions you'll need to define to get things working - the consumerHandler, the tokenHandler and timestampNonceHandler. She also includes a sample database table structure for storing the OAuth information for a user.