Межсайтовый скриптинг PHP Get проблема с URL - PullRequest
Новая
       8

Межсайтовый скриптинг PHP Get проблема с URL

0 голосов
/ 26 октября 2018

У меня проблема с межсайтовым скриптингом (XSS) на одном из моих сайтов. Сейчас я использую следующий код для получения URL каждой страницы: 

$pageurl = $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
  $pageurlencode = "http%3A%2F%2F".urlencode($pageurl);
  $pageurl = "http://".$pageurl;

Но, когда я помещаю $ pageurl в мой открытый URL-адрес графика (og: url), возникает проблема (потому что люди могут вставлять туда код). 

<meta property="og:url" content="<?php echo $pageurl; ?>" />

Итак, мой вопрос: как мне изменить мой $ pageurl, чтобы вредоносный код не добавлялся?

Я искал в StackOverflow похожие проблемы, но не смог найти ни одной, которая бы решала эту конкретную проблему (было много XSS, но ни одна из них не указывала на исправление вызова get URL). Итак, если вы видите дубликат, дайте мне знать, где вы его видели. Благодаря.

Ответы [ 2 ]

0 голосов
/ 26 октября 2018

Ваш последний комментарий был верным.

Строки запроса - и любые специальные символы, в этом отношении, всегда кодируются.Единственный возможный способ внедрения такого рода инъекций был 1), если < > " и т. Д. Были действительные символы URL или 2) даже действительные символы имени файла .Обратите внимание, что оба набора исключают любые символы HTML.Единственный раз, когда вам придется беспокоиться о внедрении, это если вы используете переменные $_GET или $_POST в PHP и выводите их напрямую - так как они декодируются в простой текст.Затем вы должны использовать htmlentities для их надлежащей очистки. См. Более широкое обсуждение внедрения текста.

Поскольку вы непосредственно получаете доступ к допустимой строке URL-адреса (через $_SERVER['REQUEST_URI']), вы никогда не получите недействительный (по спецификации) URL-адрес.

Браузер должен автоматически обрабатывать эту кодировку перед отправкой на сервер, а если нет, сервер должен защищать от любого некорректного URL.В любом случае, вашему сценарию не нужно беспокоиться об обработке этого.

РЕДАКТИРОВАТЬ

Похоже, вы можете иметь такие символы, как < > в именах файлов на Mac /Linux, однако они никогда не будут должным образом загружены сервером, поскольку они не следуют рекомендациям URL.

РЕДАКТИРОВАТЬ 2

Я только что протестировал это на сервере Node.JSи кажется, что ему удается обслуживать файлы со специальными символами.Чтобы быть в безопасности, всегда кодируйте, используя htmlentities или htmlspecialchars, как предложено на этой странице, однако, я никогда не могу себе представить, чтобы кто-то имел имя файла со специальными символами HTML - это, в основном, XSSing самостоятельно - но это полезно знатьиз.

РЕДАКТИРОВАТЬ 3

Curiosity взяла верх над собой, и я развернул файл с именем "<test.php на своем сервере NGINX, работающем на виртуальной машине Linux.Вот частичный вывод print_r($_SERVER): 

 [DOCUMENT_URI] => /"<test.php
 [REQUEST_URI] => /%22%3Ctest.php
 [SCRIPT_NAME] => /"<test.php

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

0 голосов
/ 26 октября 2018

И всегда используйте htmlspecialchars () для вывода динамических значений (пользовательский ввод) в исходные значения HTML.

...