Когда лучше санировать ввод данных пользователем?
Я понял, что подход ниже очень прост.
Я объявил интерфейс для обратного вызова
public interface AsyncResponse {
void processFinish(Object output);
}
Затем создал асинхронную задачу для ответа на все типы параллельных запросов
public class MyAsyncTask extends AsyncTask<Object, Object, Object> {
public AsyncResponse delegate = null;//Call back interface
public MyAsyncTask(AsyncResponse asyncResponse) {
delegate = asyncResponse;//Assigning call back interfacethrough constructor
}
@Override
protected Object doInBackground(Object... params) {
//My Background tasks are written here
return {resutl Object}
}
@Override
protected void onPostExecute(Object result) {
delegate.processFinish(result);
}
}
Затем вызывается асинхронная задача при нажатии кнопки в классе активности.
public class MainActivity extends Activity{
@Override
public void onCreate(Bundle savedInstanceState) {
Button mbtnPress = (Button) findViewById(R.id.btnPress);
mbtnPress.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
MyAsyncTask asyncTask =new MyAsyncTask(new AsyncResponse() {
@Override
public void processFinish(Object output) {
Log.d("Response From Asynchronous task:", (String) output);
mbtnPress.setText((String) output);
}
});
asyncTask.execute(new Object[] { "Your request to aynchronous task class is giving here.." });
}
});
}
}
Спасибо
13 ответов
Мне нравится санировать его как можно раньше, что означает, что очистка происходит, когда пользователь пытается войти в недопустимые данные. Если существует TextBox для их возраста, и они вводят в чем-либо другой, который число, я не позволяю нажатию клавиши для буквы пройти.
Затем независимо от того, что считывает данные (часто сервер) я делаю проверку работоспособности, когда я читал в данных, только чтобы удостовериться, что ничто не закрадывается из-за более решительного пользователя (такого как редактирующие руку файлы или даже изменение пакетов!)
Редактирование: В целом, санируйте рано и санируйте любое время, Вы теряли из виду данные в течение даже секунды (например, Файл Сохраняют-> Открытый Файл)
Ввод данных пользователем нужно всегда рассматривать как злонамеренный прежде, чем укоротить его на нижние уровни Вашего приложения. Всегда вход очистки дескриптора как можно скорее и не должен ни по какой причине быть сохраненным в Вашей базе данных прежде, чем проверить на злонамеренное намерение.
Я нахожу, что очистка его сразу имеет два преимущества. Один, можно проверить против него и предоставить обратную связь пользователю. Два, Вы не должны волноваться о потреблении данных в других местах.
Я санирую свои данные прямо, прежде чем я сделаю любую обработку на них. Я, возможно, должен взять поля Имени и фамилии и связать их в третье поле, которое вставляется в базу данных. Я собираюсь санировать вход, прежде чем я даже сделаю конкатенацию, таким образом, я не получаю вида ошибок вставки или обработки. Чем скорее, тем лучше. Даже использование JavaScript на фронтэнде (в веб-установке) идеально, потому что это произойдет без любых данных, идущих в сервер для начала.
страшная часть - то, что Вы могли бы даже хотеть начать санировать данные, выходящие из Вашей базы данных также. Недавний скачок Атак с использованием кода на SQL ASPRox, которые распространялись вокруг, вдвойне смертелен, потому что он заразит все таблицы базы данных в данной базе данных. Если Ваша база данных размещается где-нибудь, где существует несколько учетных записей, размещаемых в той же базе данных, Ваши данные становятся поврежденными из-за чьей-либо ошибки, но теперь Вы соединили разряды хостинга вредоносного программного обеспечения Вашим посетителям ни из-за какого начального собственного отказа.
Уверенный это делает для большой работы впереди, но если данные очень важны, то это - достойные инвестиции.
Пользователи являются злыми!
Хорошо, возможно, не всегда, но мой подход должен всегда санировать сразу, чтобы не гарантировать ничему опасные движения в какой-либо степени мой бэкенд.
дополнительное преимущество - то, что можно обеспечить, возвращаются пользователю, если Вы санируете в точке входа.
Предположите, что все пользователи являются злонамеренными. Санируйте весь вход как можно скорее. Точка.
Уберите данные перед хранением их. Обычно Вы не должны формовать НИКАКОЙ действия SQL без первой чистки входа. Вы не хотите подчиняться атаке с использованием кода на SQL.
я сортирую, следуют этим основным правилам.
- Только делают действия SQL изменения, такой как, ВСТАВЛЯЮТ, ОБНОВЛЯЮТ, УДАЛЯЮТ через POST. Никогда НЕ ДОБИРАЙТЕСЬ.
- Escape все.
- , Если Вы ожидаете, ввод данных пользователем, чтобы быть чем-то удостоверяется, что Вы проверяете, что случается так что что-то. Например, Вы запрашиваете число, затем удостоверьтесь, что это - число. Используйте проверки.
- фильтры Использования. Очистите нежелательные символы.
Рано хорошо, определенно прежде чем Вы попытаетесь проанализировать его. Что-либо, что Вы собираетесь произвести позже, или особенно передать другим компонентам (т.е. оболочка, SQL, и т.д.) должно быть санировано.
, Но не идут за борт - например, пароли хешируются перед хранением их (право?). Хеш-функции могут принять произвольные двоичные данные. И Вы никогда не будете распечатывать пароль (право?). Не анализируйте пароли - и не санируйте их.
кроме того, удостоверьтесь, что Вы делаете очистку от доверяемого процесса - клиентский JavaScript/что-либо хуже, чем бесполезный security/integrity-wise. (Это могло бы обеспечить лучший пользовательский опыт перестать работать рано, хотя - просто делают это оба места.)
Это зависит от того, какую очистку Вы делаете.
Для защиты от Внедрения SQL, ничего не делайте к самим данным. Просто используйте подготовленные операторы и тот путь, Вы не должны волноваться по поводу питания с данными, что пользователь, вводимый, и наличие его негативно, влияет на Вашу логику. Необходимо санировать немного, чтобы гарантировать, что числа являются числами, и даты являются датами, так как все - строка, как это прибывает из запроса, но не пытайтесь сделать любую проверку, чтобы сделать вещи как ключевые слова блока или что-либо.
Для защиты от нападений на XSS, вероятно, было бы легче зафиксировать данные, прежде чем это будет сохранено. Однако как другие упомянули, иногда хорошо иметь нетронутую копию точно, что вводимый пользователь, потому что, как только Вы изменяете его, это потеряно навсегда. Это почти слишком плохо нет надежного способа гарантировать Вам, приложение только производит санированный HTML путем, можно удостовериться, чтобы Вы не становились пойманными Внедрением SQL при помощи подготовленных запросов.
Самая важная вещь состоит в том, чтобы всегда быть последовательной в том, когда Вы выходите. Случайной двойной очисткой является Ламе, и не очистка опасна.
Для SQL, просто удостоверьтесь, что Ваши поддержки библиотеки доступа к базе данных связывают переменные, который автоматически выходит из значений. Любой, кто вручную связывает ввод данных пользователем на строки SQL, должен знать лучше.
Для HTML, я предпочитаю выходить в прошлый момент. При уничтожении ввода данных пользователем Вы никогда не можете возвращать его, и если они делают ошибку, они могут отредактировать и зафиксировать позже. При уничтожении их исходного входа он пошел навсегда.
Perl имеет опцию инфекции, которая считает весь ввод данных пользователем "испорченным", пока это не было проверено с регулярным выражением. Испорченные данные могут использоваться и раздаваться, но они заражают любые данные, с которыми они вступают в контакт, пока не не испорчено. Например, если ввод данных пользователем добавляется к другой строке, новая строка также испорчена. В основном любое выражение, которое содержит испорченные значения, произведет испорченный результат.
Испорченные данные могут быть брошены вокруг по желанию (заражающий данные, когда это идет), но как только это используется командой, которая имеет эффект на внешний мир, сбои сценария жемчуга. Таким образом, если я буду использовать испорченные данные для создания файла, создайте команду оболочки, изменение рабочий каталог, и т.д., то Perl перестанет работать с ошибкой безопасности.
я не знаю о другом языке, который имеет что-то как "инфекция", но использование его было очень глазным открытием. Удивительно, как быстро испорченные данные распространены вокруг, если Вы не не заражаете его сразу же. Вещи, настолько естественные и нормальные для программиста, как установка переменной на основе пользовательских данных или открытия файла, кажутся опасными и опасными с заражением включенного. Таким образом, лучшая стратегия того, чтобы добиться цели состоит в том, чтобы не испортить, как только Вы получаете некоторые данные из внешней стороны.
И я подозреваю, что это - лучший способ на других языках также: проверьте пользовательские данные сразу же так, чтобы ошибки и дыры в системе безопасности не могли распространить слишком далеко. Кроме того, должно быть легче контролировать код для дыр в системе безопасности, если потенциальные ямы находятся в одном месте. И Вы никогда не можете предсказывать, какие данные будут использоваться для какой цель позже.
Я считаю, что дезинфицируйте вводимые пользователем данные, как только возможно на стороне клиента и на стороне сервера, я делаю это так
- (на стороне клиента), позволяю пользователю введите в поле только определенные ключи.
- (на стороне клиента), когда пользователь переходит к следующему полю с помощью onblur, проверьте введенный им ввод против регулярного выражения и обратите внимание на пользователя, если что-то не так.
- (на стороне сервера), снова проверьте ввод, если поле должно быть INTEGER, проверьте это (в PHP вы можете использовать is_numeric ()), если поле имеет хорошо известный формат проверьте это на регулярное выражение, все другие (например, текстовые комментарии), просто убежать от них. Если что-то подозрительно, остановите выполнение скрипта и верните пользователю уведомление о том, что введенные им данные недействительны.
Если что-то действительно похоже на возможную атаку, сценарий отправляет мне письмо и SMS, чтобы я мог проверить и предотвратить это как можно скорее, мне просто нужно проверить журнал, в котором я вхожу в систему для всех пользователей input, а также шаги, которые скрипт сделал перед тем, как принять или отклонить ввод.
Я очищаю свои пользовательские данные так же, как Раду ...
Первая на стороне клиента, использующая регулярные выражения и взявшая под свой контроль допустимые символы. ввод в заданные поля формы с использованием javascript или jQuery, привязанных к событиям, например onChange или OnBlur, который удаляет любой запрещенный ввод, прежде чем он может быть Отправлено. Однако поймите, что на самом деле это только позволяет тем пользователи знают, что данные будут проверяться и на стороне сервера. Это больше предупреждение, чем любая реальная защита.
Во-вторых, а в наши дни я редко вижу, чтобы это делалось, что первая проверка была done на стороне сервера - это проверить место, откуда отправляется форма. Разрешив отправку формы только со страницы, которую вы определили как действительную location, вы можете убить скрипт ДО того, как прочтете какие-либо данные. Предоставленный, этого само по себе недостаточно, так как хороший хакер со своим собственным сервером может "подделать" и домен, и IP-адрес, чтобы вашему скрипту показалось, что он идет из допустимого местоположения формы.
Далее, и мне даже не нужно это говорить, но всегда, я имею в виду ВСЕГДА , беги ваши скрипты в режиме заражения. Это заставляет не лениться, а прилежно относиться к шаг номер 4.
Как можно скорее очистите данные пользователя, используя правильные регулярные выражения, соответствующие данные, которые ожидаются от любого заданного поля формы. Не используйте ярлыки вроде печально известный « волшебный рог единорога », чтобы продуть ваши проверки на заражение ... или вы можете просто отключить проверку на зараженность на все благо это будет делать для вашей безопасности.Это все равно, что дать психопату острый нож, несущий ваше горло, и говоря: "Ты действительно не причинишь мне вреда этим, хочешь".
И вот чем я отличаюсь от большинства других на этом четвертом шаге, так как я только дезинфицирую пользовательские данные, которые я собираюсь ИСПОЛЬЗОВАТЬ таким образом, который может представлять безопасность риск, такой как любые системные вызовы, присвоения другим переменным или любая запись в хранить данные. Если я использую данные, введенные пользователем, только для сравнения с данными Я сам сохранил в системе (поэтому знаю, что мои данные в безопасности), то я не утруждаю себя дезинфекцией пользовательских данных, так как я никогда не собираюсь это представляет собой проблему безопасности. Например, введите имя пользователя как пример. Я использую введенное пользователем имя пользователя только для того, чтобы сравнить его с совпадением в моя база данных, и если это правда, после этого я использую данные из базы данных для выполнения все другие функции, которые я мог бы вызвать в сценарии, зная, что это безопасно, и никогда после этого снова используйте данные пользователей.
И последнее: отфильтровать все попытки автоматической отправки роботами в наши дни с помощью система «аутентификации человека», такая как Captcha. Это достаточно важно в наши дни что я нашел время, чтобы написать свою собственную схему аутентификации человека, которая использует фотографии и ввод для «человека», чтобы ввести то, что он видит на картинке. Я сделал это потому что Я обнаружил, что системы типа Captcha действительно раздражают пользователей (вы можете сказать по их прищурившись от попыток расшифровать искаженные буквы ... обычно снова и снова снова).Это особенно важно для скриптов, использующих SendMail или SMTP. для электронной почты, так как это фаворит для ваших голодных спам-ботов.
Вкратце, я объясню это, как и своей жене ... ваш сервер похож на популярный ночной клуб, и чем больше у вас вышибал, тем меньше у вас проблем в ночном клубе. У меня два вышибалы за дверью (клиент-боковая проверка и аутентификация человека), один вышибала прямо за дверью (проверка действительного места отправки формы ... `` Это действительно вы на этом идентификаторе '') и еще несколько вышибал в непосредственная близость к двери (запущен режим заражения и используются хорошие регулярные выражения для проверки данные пользователя).
Я знаю, что это старый пост, но я счел его достаточно важным, чтобы любой, кто прочитает его после моего визита сюда, понял, что это не « волшебная пуля », когда дело касается безопасности, и это все это работает в сочетании друг с другом, чтобы обеспечить безопасность ваших пользовательских данных. Просто использовать один или два из этих методов практически бесполезно, поскольку их сила существует только тогда, когда они все работают вместе.
Или вкратце, как часто говорила моя мама ... «Лучше перестраховаться, чем сожалеть».
ОБНОВЛЕНИЕ:
Еще одна вещь, которую я делаю сейчас, - это кодирование всех моих данных Base64, а затем шифрование данные Base64, которые будут находиться в моих базах данных SQL. Для их хранения таким образом требуется примерно на треть больше байтов, но, на мой взгляд, преимущества безопасности перевешивают дополнительный размер данных
.