You say in the name field? Do you mean the name on the user model?

There was a security issue with the default auth setup that allowed someone to create a username with script embedded that would be executed unchecked by vue

It looks like this could have been used. This is bad news for the community if this is the case

@Cronix thanks for clarifying that. I am building a simple site right now on a shared host. I've setup mine correctly on a sub-domain and everything is secured.

the following versions were patched against this issue 5.6.9 and 5.5.37.

https://medium.com/@taylorotwell/js-frameworks-server-side-rendering-and-xss-722805009892

@Snapey Thank you ! Didn't see that.

I should add that only sites BUILT after those versions are protected. Sites that are upgraded are still vulnerable to the XSS issue

@Snapey so if you are using laravel 5.4 you are not protected?

So there really is a security problem?

@Snapey yes the column name of the User model - I use default auth Laravel methods without extends and etc.

@martyyy @Snapey @muhi AFAIK, the XSS issue was about VueJS (and possibly other, similar JS frameworks) reading curly brackets as code when found inside user input (interpolations, Vue thinks it's supposed to compile the expression), hence the added v-pre directive to the section where the user name is being echoed.

If you don't bind the Vue instance to the whole layout, this shouldn't be a problem. If you do, you will still need to use v-pre whenever user input is involved. You could also sanitize curly brackets from your input or disable Vue's interpolation.

See this thread and my answer to it: https://laracasts.com/discuss/channels/vue/vue-interpolation

This is quite an annoying little thing. Adding v-pre to each html node where curly brackets should not be parsed is easy to forget and feels like the days where you had to wrap each parameter in your html with htmlentities.

It would be cool if there was an option to say at the root of node of your app say: v-pre and on every spot where you do need to parse the {{ }} tags you add another tag like v-parse or whatever.

Another quick and dirty solution could be to just strip out all curly brackets from your inputs in a middleware. Equal to the middleware that is automatically applied to 'trim' all input values. This only works for new values and not for existing values in your database of course.

<?php

namespace App\Http\Middleware;

use Illuminate\Foundation\Http\Middleware\TransformsRequest;

class RemoveCurlyBrackets extends TransformsRequest
{
    /**
     * The attributes that should not be undone from curly brackets.
     *
     * @var array
     */
    protected $except = [
        //
    ];

    /**
     * Transform the given value.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return mixed
     */
    protected function transform($key, $value)
    {
        if (in_array($key, $this->except, true)) {
            return $value;
        }

        return str_replace(['{{', '}}'], '', $value);
    }
}

Another better solution would be to do the following. See this comment on github for a full reply https://github.com/vuejs/vue/issues/4223#issuecomment-294864675. I've tested it and it seems to do the job.

Below code is also available as a package mentioned in the other topic. https://github.com/alfa-jpn/vue-disable-interpolation

const noDelimiter = {replace: () => '(?!x)x'}; // return a non-matching regexp.

const app = new Vue({
    el: '#vue-app',
    delimiters: [noDelimiter, noDelimiter],
    components: {
        MyComponent,
    },
});

Yeah, but how is that related to the leaked .env details?

XSS is horrible, but that doesn't give you any advantage to read files on the server side. even if he stole his whole admin session, he would still be unable to read more files then the webserver should .. or am i missing something here?

@Helmchen yes you are right, it is unlikely the .env is leaked with the use of xss. Unless the .env is somehow editable in an admin area but I doubt that ;-)

I am just going to ask the question again @martyyy because I didn't saw an answer yet. Did you check your logins on your webserver? Because that could be still an option right? The attacker had access to your server directly instead of an open .env file that he accessed in his browser.

The XSS issue with vue is most easily fixed by removing app from the <div id="app"> tag of the default layouts so that Vue cannot bind to it.

The disappointing thing about it is that it affects projects that don't know or care about Vue, and just use boilerplate layout.

In Martyyy's case, he is not seeing this in his database - just a straightforward script tag. This should be escaped by the blade {{ }} but I see too many people outputting raw data - particularly in forms

The script linked in the username, if executed, sends the user's cookies etc to a 'mothership' server. In this case its a client side javascript injection, but if you can cause tags to be rendered in user content, then why not php?

Always escape user input folks!

You`re right @Snapey I just was sure Laravel do this in default auth methods - but it is my mistake to not check it.

Very interesting talk here. Ain't it a condition that only /public/ folder should be the web-root and all the other directories should not be exposed?

Is it still possible for the hacker to access .env and other files without having root access to the server, in that case?

Are you using forge or something else for provisioning/deployment? In forge you manage your env within forge, maybe there is a security issue at forge.

Also there is a little chance you can find something in the access log?

I use deploybot