Может ли переменная URI когда-либо вредоносный

Question

Учитывая следующий простой код:

function loadthis ($var) 
{ 
     $id = $this->model->get_id($var); 
} 

Вопрос: может любой вредоносный код никогда не передаются через переменную URI?

Сценарий: www.mydomain.com/mycontroller/loadthis/dosomethingreallybadhere

Дополнительно:

• Я использую активную запись на модели, так что я знаю, что они не могут делать инъекции SQL
• В этом примере я НЕ использую класс form_validation (но я использую его в других местах для своих форм)

• Я ограничу свои символы URI к умолчанию, предоставленных Codeigniter

  $config['permitted_uri_chars'] = 'a-z 0-9~%.:_\-'; 
  

Answer 1

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

1. Цитаты, одиночные кавычки и полуколоны, поскольку они могут быть использованы для атаки с использованием MySQL.
2. HTML-символы разметки, такие как < или>, так как они могут использоваться для ввода вредоносных скриптов.

Это далеко не полный список. Это основные вещи, которые вы должны быть в поиске. Я настоятельно рекомендую вам ознакомиться с рекомендациями по безопасности на уровне https://www.owasp.org/index.php/Main_Page

Answer 2

Да и нет.

«Данные» сами по себе никогда не опасны, это всего лишь данные. Это зависит от того, что вы делаете с ним, что может иметь нежелательные последствия, если данные содержат то, чего вы не ожидали. Таким образом, для данных, полученных по URL-адресу, или действительно любые данные, полученные от кого-то, у пользователя пользователь имеет контроль над, вы не можете знать или гарантировать, что эти данные содержат. Следовательно, не пишите код, который использует эти данные, и будет либо разбивать, либо открывать уязвимости безопасности, если данные содержат то, чего вы не ожидали.

Данные с неизвестным контентом не являются опасными, если вы рассматриваете его как чужой объект и обрабатываете его соответствующим образом. Это is опасно, если вы относитесь к нему так, как будто знаете, что в нем, хотя вы этого не делаете. Да, это сложный ответ. ;)

Answer 3

Это зависит от кода, конечно. Вы никогда не можете сказать «это абсолютно безопасно» без анализа всей базы кода. Ограниченная кодировка URL-адресов кажется разумной (если этого достаточно для вашего приложения). Однако я могу представить, по крайней мере, один пример, где вход может быть вредоносным, если пользователь помещает \..\..\ в URL-адрес, что в некоторых случаях может открыть пользовательский файл (в Windows).

Если вы беспокоитесь только о инъекции SQL, если у вас есть такой код:

SELECT * FROM articles WHERE article_id = $id 

злонамеренный пользователь может установить $ идентификатор 0 or 1 like 1, который проходит ваш ограниченный набор символов.

То же самое можно сделать для XSS, если вы где-нибудь забываете сбежать должным образом (часто возникает в сгенерированном JavaScript-коде), но пример сложнее думать.

В любом случае, нет истинного/идеального/безопасного способа ограничения ввода пользователем для обеспечения безопасности. Единственный способ избежать XSS/SQL/любой инъекции - пройти весь ваш код и убедиться, что везде, где вы либо используете для ввода, или вывод некоторой переменной, она правильно экранируется в соответствии с используемым контекстом. Правило не ограничивает ввод, но будьте готовы, что может содержать что-либо.

Если ввод является строкой, будьте готовы, он может содержать любые символы и иметь дело с ним. Сохраните его в базе данных , так как это, и убедитесь, что во время сохранения он не может навредить. Если вам нужно избежать этого при построении SQL-запроса, убегите туда. Если вам нужно поместить строку (или ее часть) в вывод HTML, убегите в этом. Конечно, вы должны быть очень осторожны, чтобы убедиться, что вы все равно избегаете всех мест.