CODEWITHSUNDEEP
phpxsslaravel
warmspringwinds
warmspringwinds

Reputation: 1177

Sanitize user input in laravel

I've got a simple question: When is it best to sanitize user input? And which one of these is considered the best practice:

  1. Sanitize data before writing to database.
  2. Save raw data and sanitize it in the view.

For example use HTML::entities() and save result to database. Or by using HTML methods in the views because in this case laravel by default uses HTML::entities(). Or maybe by using the both.

EDIT: I found interesting example http://forums.laravel.com/viewtopic.php?id=1789. Are there other ways to solve this?

Upvotes: 16

Views: 28431

Answers (5)

Oddman
Oddman

Reputation: 3959

It depends on the user input. If you're generally going to be outputting code they may provide (for example maybe it's a site that provides code snippets), then you'd sanitize on output. It depends on the context. If you're asking for a username, and they're entering HTML tags, your validation should be picking this up and going "no, this is not cool, man!"

If it's like the example I stated earlier (code snippets), then let it through as RAW (but be sure to make sure your database doesn't break), and sanitize on output. When using PHP, you can use htmlentities($string).

Upvotes: 1

735Tesla
735Tesla

Reputation: 3241

I just found this question. Another way to do it is to enclose dynamic output in triple brackets like this {{{ $var }}} and blade will escape the string for you. That way you can keep the potentially dangerous characters in case they are important somewhere else in the code and display them as escaped strings.

Upvotes: 4

Andres Felipe
Andres Felipe

Reputation: 4330

i'd found this because i was worried about xss in laravel, so this is the packages gvlatko

it is easy:

To Clear Inputs = $cleaned = Xss::clean(Input::get('comment');

To Use in views = $cleaned = Xss::clean(Input::file('profile'), TRUE);

Upvotes: 1

Muhammad Usman
Muhammad Usman

Reputation: 12503

I have a full article on input filtering in Laravel, you might find it useful http://usman.it/xss-filter-laravel/, here is the excerpt from this article:

You can do a global XSS clean yourself, if you don’t have a library to write common methods you may need frequently then I ask you to create a new library Common in application/library. Put this two methods in your Common library:

/*
 * Method to strip tags globally.
 */
public static function global_xss_clean()
{
    // Recursive cleaning for array [] inputs, not just strings.
    $sanitized = static::array_strip_tags(Input::get());
    Input::merge($sanitized);
}

public static function array_strip_tags($array)
{
    $result = array();

    foreach ($array as $key => $value) {
        // Don't allow tags on key either, maybe useful for dynamic forms.
        $key = strip_tags($key);

        // If the value is an array, we will just recurse back into the
        // function to keep stripping the tags out of the array,
        // otherwise we will set the stripped value.
        if (is_array($value)) {
            $result[$key] = static::array_strip_tags($value);
        } else {
            // I am using strip_tags(), you may use htmlentities(),
            // also I am doing trim() here, you may remove it, if you wish.
            $result[$key] = trim(strip_tags($value));
        }
    }

    return $result;
}

Then put this code in the beginning of your before filter (in application/routes.php):

//Our own method to defend XSS attacks globally.
Common::global_xss_clean();

Upvotes: 12

Erlend
Erlend

Reputation: 4416

I would say you need both locations but for different reasons. When data comes in you should validate the data according to the domain, and reject requests that do not comply. As an example, there is no point in allowing a tag (or text for that matter) if you expect a number. For a parameter representing.a year, you may even want to check that it is within some range. Sanitization kicks in for free text fields. You can still do simple validation for unexpected characters like 0-bytes. IMHO it's best to store raw through safe sql (parameterized queries) and then correctly encode for output. There are two reasons. The first is that if your sanitizer has a bug, what do you do with all the data in your database? Resanitizing can have unwanted consequences. Secondly you want to do contextual escaping, for whichever output you are using (JSON, HTML, HTML attributes etc.)

Upvotes: 12

Related Questions