Я новичок в разработке вещей в Интернете. До сих пор я трачу много времени (50% или около того), чтобы попытаться помешать плохим людям вкладывать такие вещи, как sql-инъекция, в мои входные формы и проверять его на стороне сервера. Это нормально?Какой процент моего времени будет потрачен на верификацию пользовательского ввода во время веб-разработки?
Нет. Это не нормально. Может быть, вам нужно:
Любой современный язык поддерживает обе вещи.
С наилучшими пожеланиями
Я рад, что вы заботиться, чтобы защитить себя. Слишком многие не делают.
Однако, как говорили другие, лучший выбор архитектуры заставит ваши проблемы уйти. Использование подготовленных операторов (большинство языков должно иметь поддержку для этого) приведет к удалению SQL-инъекций. Кроме того, со многими базами данных они приведут к значительно лучшей производительности. Обработка межсайтовых скриптовых атак более сложна. Но основная стратегия должна состоять в том, чтобы решить, как избежать пользовательского ввода, решить, где вы его избежите, и всегда делать это в одном месте. Не попадайте в ловушку, думая, что лучше! Постоянно делать это одним способом в одном месте будет достаточно, и вы избежите того, чтобы выяснить, какой из нескольких уровней экранирования вызывает определенную ошибку.
Или курс обучения тому, как создавать и поддерживать разумную архитектуру, имеет опыт. И более того, он размышляет о ваших плохих переживаниях. Поэтому обратите внимание на ваши текущие болевые точки (похоже, вы такие), и подумайте о том, что вы могли бы сделать по-другому, чтобы избежать их. Если у вас есть наставник, поговорите со своим наставником. Это не всегда поможет вам в этом проекте, но это будет со следующего.
Чтобы предотвратить атаки с использованием sql-инъекций, просто выполняйте свои запросы с помощью подготовленных инструкций (точный способ зависит от вашей платформы). Как только вы это сделаете, вам больше не придется беспокоиться об этом конкретном аспекте. Вам просто нужно использовать этот везде.
Что касается проверки общего ввода, всегда полезно полагаться на общую базу для проверки необходимых полей, цифр и т. Д. Валидаторы ASP.Net очень просты в использовании. Одно эмпирическое правило, которому вы должны следовать, - не доверять клиентской стороне (javascript), чтобы сделать это для вас, так как легко обойти это. Всегда делайте это на стороне сервера.
Специальный футляр для хранения под вашим радаром - это когда вы разрешаете вводить богатый контент, который может содержать html/javascript. Это позволяет злоумышленнику вводить javascript в ваши данные, которые будут вызывать код, который вы не контролируете при его рендеринге. Do не попытайтесь свернуть свой собственный код проверки. Найдите в Интернете бесплатный, проверенный, запрограммированный код, который сделает это за вас. У Джеффа было несколько указателей в этом отношении в одном из подкастов.
Как только вы автоматизируете свой код проверки ввода, время, затраченное на его выполнение, должно быть напрямую связано со сложностью ваших бизнес-правил. Итак, как правило: держите их простыми.
@Jeremy - некоторые PHP особенность
Когда дело доходит до запросов к базе данных, всегда попробовать и использовать подготовленные параметризованные запросы. Это поддерживают библиотеки mysqli и PDO. Это бесконечно безопаснее, чем использование escaping-функций, таких как mysql_real_escape_string.
Да, mysql_real_escape_string фактически является просто функцией экранирования строки. Это не волшебная пуля. Все, что он сделает, это избежать опасных символов, чтобы их можно было безопасно использовать в одной строке запроса. Однако, если вы не будете заранее дезинфицировать свои входы, тогда вы будете уязвимы для определенных векторов атаки.
Представьте себе следующую SQL:
$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);
Вы должны быть в состоянии видеть, что это уязвимо для использования.
Представьте параметр id содержал общий вектор атаки:
1 OR 1=1
Там нет рискованных символов в их кодирования, поэтому он будет проходить прямо через отводящей фильтр. Оставляем нас:
SELECT fields FROM table WHERE id = 1 OR 1=1
Какой прекрасный вектор инъекции SQL.
Несмотря на то, что эти функции полезны, их следует использовать с осторожностью. Вы должны убедиться, что все веб-входы в некоторой степени подтверждены. В этом случае мы видим, что мы можем быть использованы, потому что мы не проверяли, что переменная, которую мы использовали в качестве числа, была фактически числовой. В PHP вы должны широко использовать набор функций для проверки того, что входные данные являются целыми числами, поплавками, буквенно-цифровыми и т. Д. Но когда дело доходит до SQL, учитывайте большую ценность подготовленного оператора. Вышеприведенный код был бы безопасным, если бы он был подготовленным оператором, поскольку функции базы данных знали бы, что 1 OR 1=1 не является допустимым литералом.
Что касается htmlspecialchars(). Это собственное месторождение.
В PHP существует настоящая проблема, поскольку в нем имеется целый ряд различных функций экранирования, связанных с html, и нет четкого указания точно, какие функции выполняют что-то.
Во-первых, если вы находитесь внутри HTML-тега, у вас настоящие проблемы. Посмотрите на
echo '<img src= "' . htmlspecialchars($_GET['imagesrc']) . '" />';
Мы уже внутри HTML-тега, поэтому нам не нужно < или>, чтобы сделать что-нибудь опасное. Наш вектор атаки может быть просто javascript:alert(document.cookie)
Теперь результирующий HTML выглядит
<img src= "javascript:alert(document.cookie)" />
атака получает прямо через.
Все ухудшается. Зачем? потому что htmlspecialchars только кодирует двойные кавычки и не является одиночным.Так что, если мы имели
echo "<img src= '" . htmlspecialchars($_GET['imagesrc']) . ". />";
Наш злой хакер теперь может вводить целые новые параметры
pic.png' onclick='location.href=xxx' onmouseover='...
дает нам
<img src='pic.png' onclick='location.href=xxx' onmouseover='...' />
В этих случаях нет волшебной пули, вы просто должны самостоятельно вводите ввод. Если вы попытаетесь отфильтровать плохие персонажи, вы наверняка потерпите неудачу. Возьмите белый подход и только пусть через символы, которые хороши. Посмотрите на XSS cheat sheet для примеров того, как разнообразные векторы могут быть
Даже если вы используете htmlspecialchars ($ string) вне HTML-тегов, вы по-прежнему уязвимы для многобайтовых символов атаки набора символов.
Наиболее эффективным может быть использование комбинации mb_convert_encoding и htmlentities следующим образом.
$str = mb_convert_encoding($str, ‘UTF-8′, ‘UTF-8′);
$str = htmlentities($str, ENT_QUOTES, ‘UTF-8′);
Даже это оставляет уязвимым IE6 из-за того, как он обрабатывает UTF. Тем не менее, вы можете вернуться к более ограниченной кодировке, например, ISO-8859-1, до тех пор, пока использование IE6 не снизится.
В то время как вы говорите о специфических функциях PHP, принципы применяются ко всем langugages. Понимание SQL injection/XSS является первым шагом к его предотвращению. – Wayne 2008-09-22 14:18:15
Только примечание к подготовленным заявлениям. Прежде всего, вы должны попытаться использовать хранимые процедуры, если можете ... они, вероятно, являются лучшим решением в большинстве случаев.
Во-вторых, они оба защищают вас от внедрения SQL только до тех пор, пока вы не используете динамический SQL, то есть SQL, который записывает больше SQL и затем выполняет его. В этом случае они будут неэффективными - и так будут храниться процедуры.
Что касается процента времени, которое вы тратите: валидация очень важна, и это заставляет задуматься, если не какое-то время. Но процент зависит от того, насколько велика ваша заявка, нет? В очень маленьком приложении, скажем, только для регистрации информационного бюллетеня, вполне возможно, что валидация требует огромного процента вашего времени.
В больших приложениях, то есть там, где у вас много кода без представления, это не нормально.
Я вижу вашу проблему. Похоже, у вас есть логика защиты , посыпанная всей кодовой базой. И каждый раз, когда вы пишете потенциально опасный код, вы должны быть осторожны, чтобы включить все защиты. И каждый раз, когда появляется новая угроза, вы должны пройти все эти утверждения и убедиться, что они защищены.
Вы не можете сделать настоящую безопасность таким образом.
У вас должны быть некоторые обертки, которые будут сделать производственный код небезопасного, если не невозможно. Например, подготовленные заявления. Но вы можете использовать ORM, например, Ruby on Rails ActiveRecord или какой-то эквивалент в вашей структуре.
Для вывода и защиты XSS убедитесь, что выходной сигнал HTML-экранированный по умолчанию. Тогда, если вам действительно нужно вывести сгенерированный HTML для пользователя, вы сделаете это явно, и это будет проще проверить.
Для защиты CSRF попробуйте также найти общее решение.Как правило, он должен выполнять свою работу автоматически, без необходимости явно создавать токен проверки и вручную проверять его, отбрасывать или отклонять запрос.
У вас возникла проблема, которая может быть решена только путем обобщения.
Try для выявления общих типов ввода-проверка вам необходимо
a d вызывать их систематически перед обработкой данных.
Все Доступ к базе данных должен выполняться с помощью подготовленных операторов, а не для конкатенации строки запроса.
Все вывод должен быть экранирован, так как вы хотите сохранить все, что сбежало в вашей базе данных.
Хороший внеполосный/социальный подход: идентифицируйте своих пользователей как можно лучше. Чем выше вероятность получить идентификацию, тем меньше они будут обманывать систему. Получите их номер мобильного телефона, чтобы отправить код, проверить свою кредитную карту и т. Д.
Пример: Одна функция, которую я хочу добавить гораздо позже, - это скопировать и вставить предварительно форматированный html-документ в текстовое поле. – danmine 2008-09-21 07:49:17