Getting Started With Laravel 4, Chapter 4: Authentication and Security

Authenticating users

PHP doesn't have any way to authenticate users.  This leads to many problems,  and many different solutions in pure PHP.  Laravel provides the tools to make this happen.

Creating the user model

Laravel provides default inside auth.php and an existing user model that we can take advantage of.  For this app, we will simplify it a little bit.

Creating the users database schema

The author introduces a foreign key constraint.  And we will use a seeder function to add data to our new user table.  We are also introduced to the Hash::make helper.  Laravel expects all passwords to be hashed with this function.  You should not store passwords in clear text, and you should not hash them with some of the weaker algorithms (md5 or sha1).

Authentication routes and views

We make a few changes to our master view to accommodate users, allowing them to login and logout.  We pass in our username and password to the Auth::attempt method.  When this function returns True, we can redirect them to where they wanted to go, or we can redirect them to where we want them go.  If it returns false, we redirect them to login page.  Inside app/filters.php There is a guest() method.  You can use this to redirect the user to the correct page by changing these filters.  We also create a simple login page for the cats app.  We also need to create a logout route.  The next step is to wrap all of our protected routes inside an auth route group.  Finally, we add a few lines of code to all of our views to protect them from unauthorized users.  We also need to add the user_id to our function that saves a cat.

 Validating user input

You could use regular expressions to validate data, but Laravel makes this so much easier.  There are over 30 different validation rules.  Too many to go over in this section.  Make sure you read the documentation.  You can check if the validation fails, collect the errors, and then display them back to the user by redirecting back to the form page. 

Links:
https://laravel.com/docs/5.6/validation

Securing your app

Before deploying our app, we need to see what Laravel can and can't do to protect us and our users.

Cross-site request forgery

Form:open/Form:model already add CSRF tokens to to help prevent these attacks.  To take advantage of these will we wrap our routes inside a Route::group.  It will make sure these routes check the hidden CSRF token before allowing the request to come throug

Links:
https://en.wikipedia.org/wiki/Cross-site_request_forgery

Escaping content to prevent cross-site scripting

XSS is when a bad user inserts code into our database.  Never trust input from users.  To protect us against such attacks we user {{{}}} (triple curly braces).  This will not allow the code to run on our site, instead it will "escape" all the text, and just display it on the screen.

Links:
https://en.wikipedia.org/wiki/Cross-site_scripting

Avoiding SQL injection

Laravel protects against this by default.  Eloquent uses PDO behind the scenes.  The trouble we can run into is when we choose to write our own sql queries using DB::raw.  To protect against this, we will replace any variables in our sql with a question mark, and pass in an array of those variables. 
No mention of sql injection is complete without mention of Little Bobby Droptables from  Randall Munroe over at XKCD.



Links:
https://en.wikipedia.org/wiki/SQL_injection

Using mass assignment with care

We used mass-assignment earlier when we used the built-in forms functions.  This allowed us to create a model without having to assign all the fields individually.  A nefarious user could add a new field to our form, and cause bad things to happen.  You can use the $fillable array in your model, and any extra fields will cause an error, and won't make it to your model.

Cookies - secure by default

Laravel cookies are auto-signed and encrypted.  If they are tampered with, Laravel will discard them automatically.

Forcing HTTPS when exchanging sensitive data

Laravel provides methods to force pages to be served over HTTPS.  This will require an SSL cert installed on your server. 

Comments

Post a Comment

Popular posts from this blog

Go Programming Blueprints, Chapter 2, Adding User Accounts

A universal truth in programming is that there are relatively few unique unsolved problems.  What tasked with a new problem, always see what other solutions exist and how we can solve our new one.  In this instance, we are going to use open source solutions to auth against existing services. Handlers all the way down Everything we write will be http handlers.  This allows us to encapsulate objects as far down the chain as needed.  Making pretty social sign in page We get a quick lesson on bootstrap, and why and how to use it.  There are two methods to showing our bootst rap.  We can leave it hosted on a CDN or add it to our assets folder.  Endpoints with Dynamic Paths Go doesn't support the most robust path selections (/path/options), such as ruby on rails or Django python.  As with everything Go, there are open source packages we can use to help with this functionality.  We will use string.split to break our argument paths in the re...
Read more

Successful Big Game Hunting Chapter 10

Chapter 10: Short Course on Bear Hunting As with all the short course chapters, this is a quick chapter on hunting different types of bears.  Mr. Gilchrist has several tips on the different types of bears, and tips on how to distinguish between them.  In at least one western state, there is a test on how to visually tell the difference between a grizzly bear and a black bear. Of course he as tips on how to prepare a bear hide for for taxidermy, and how to score a bear as a trophy.  He also has several tips on how to tell if a bear is a trophy. Favorite Quote: "Bears often react violently to a superficial hit.  He may fall as though mortally wounded, when only hit in the paw"
Read more