1- Avoiding SQL injection

An SQL injection vulnerability exists when an application inserts arbitrary and unfiltered user input in an SQL query. This user input can come from cookies, server variables, or, most frequently, through GET or POST input values. These attacks are conducted to access or modify data that is not normally available and sometimes to disturb the normal functioning of the application.

By default, Laravel will protect you against this type of attack since both the query builder and Eloquent use PHP Data Objects (PDO) class behind the scenes. PDO uses prepared statements, which allows you to safely pass any parameters without having to escape and sanitize them.

In some cases, you might want to write more complex or database-specific queries in SQL. This is possible using the DB::raw method. When using this method, you must be very careful not to create any vulnerable queries like the following one:

Route::get(‘sql-injection-vulnerable’, function() {$name = “‘Bobby’ OR 1=1”;return DB::select(DB::raw(“SELECT * FROM cats WHERE name = $name”));});

To protect this query from SQL injection, you need to rewrite it by replacing the parameters with question marks in the query and then pass the values in an array as a second argument to the raw method:

Route::get(‘sql-injection-not-vulnerable’, function() {$name = “‘Bobby’ OR 1=1”;return DB::select(DB::raw(“SELECT * FROM cats WHERE name = ?”, [$name]));});

The preceding query is known as a prepared statement, as we define the query and what parameters are expected, and any harmful parameters that would alter the query or data in the database in an unintended way are sanitized.

2- Forcing HTTPS when exchanging sensitive data

If you are serving your application over HTTP, you need to bear in mind that every bit of information that is exchanged, including passwords, is sent in cleartext. An attacker on the same network could therefore intercept private information, such as session variables, and log in as the victim. The only way we can prevent this is to use HTTPS. If you already have an SSL certificate installed on your web server, Laravel comes with a number of helpers to switch between http:// and https:// and restrict access to certain routes. You can, for instance, define an https filter that will redirect the visitor to the secure route as shown in the following code snippet:

Route::filter(‘https’, function() {if ( ! Request::secure())return Redirect::secure(URI::current());});

3- Using mass assignment with care

a convenient feature that allows us to create a model based on the form input without having to assign each value individually.

This feature should, however, be used carefully. A malicious user could alter the form on the client side and add a new input to it:

<input name=“is_admin” value=“1” />

Then, when the form is submitted, we attempt to create a new model using the following code:

Cat::create(Request::all())

Thanks to the $fillable array, which defines a white list of fields that can be filled through mass assignment, this method call will throw a mass assignment exception.

It is also possible to do the opposite and define a blacklist with the $guarded property. However, this option can be potentially dangerous since you might forget to update it when adding new fields to the model.

Cookies – secure by default Laravel makes it very easy to create, read, and expire cookies with its Cookie class.

You will also be pleased to know that all cookies are automatically signed and encrypted. This means that if they are tampered with, Laravel will automatically discard them. This also means that you will not be able to read them from the client side using JavaScript.

4 – Cross-site Request Forgery

Cross-site request forgery (CSRF) attacks are conducted by targeting a URL that has side effects (that is, it is performing an action and not just displaying information). We have already partly mitigated CSRF attacks by avoiding the use of GET for routes that have permanent effects such as DELETE/cats/1, since it is not reachable from a simple link or embeddable in an <iframe> element. However, if an attacker is able to send his victim to a page that he controls, he can easily make the victim submit a form to the target domain. If the victim is already logged in on the target domain, the application would have no way of verifying the authenticity of the request.

The most efficient countermeasure is to issue a token whenever a form is displayed and then check that token when the form is submitted. Form::open and Form::model both automatically insert a hidden _token input element, and middleware is applied to check the supplied token on incoming requests to see whether it matches the expected value.

5 best security tips for a laravel Appliction

Click to Tweet

5- Escaping content to prevent cross-site scripting (XSS)

Cross-site scripting (XSS) attacks happen when attackers are able to place client-side JavaScript code in a page viewed by other users. In our application, assuming that the name of our cat is not escaped, if we enter the following snippet of code as the value for the name, every visitor will be greeted with an alert message everywhere the name of our cat is displayed:

Evil Cat <script>alert(‘Meow!’)</script>

While this is a rather harmless script, it would be very easy to insert a longer script or link to an external script that steals the session or cookie values. To avoid this kind of attack, you should never trust any user-submitted data or escape any dangerous characters. You should favor the double-brace syntax ({{ $value }}) in your Blade templates, and only use the {!! $value !!} syntax, where you’re certain the data is safe to display in its raw format.

The most efficient countermeasure is to issue a token whenever a form is displayed and then check that token when the form is submitted. Form::open and Form::model both automatically insert a hidden _token input element, and middleware is applied to check the supplied token on incoming requests to see whether it matches the expected value.

<

p style=””>In this article, we have covered several common attack vectors for web applications and learned about how Laravel protects your application against them.    Since a framework cannot protect you against everything  ;)