Предотвратить атаки инъекций sqlite на вашем собственном iPhone?

Question

Я всегда принимаю меры предосторожности в отношении атак SQL-инъекций, когда данные сохраняются между чьим-то iPhone и удаленной базой данных в облаке.

Но также необходимо ли делать то же самое ... при простом сохранении данных (используя sqlite) с чьего-либо мобильного телефона в базу данных, которая находится только на их собственном телефоне?

Что хуже они могут сделать? Удалить свои данные (или таблицы) на свой телефон? (Если они действительно стараются изо всех сил.)

Спасибо.

Answer 1

• Нужно ли? - Да, это "необходимо", т. Е. Оно, вероятно, того стоит. Даже если вас не очень заботит безопасность в этом контексте (что может быть допустимо), вам следует беспокоиться о корректности (по крайней мере, о ее гордости).

• Что может быть хуже всего?

  • Пользователь # 1 Patty O'Brian вводит свое имя в поле, которое объединяет вызов SQL, и происходит сбой. Программа либо плохо справляется с этим, либо пользователь получает неоднозначное сообщение об ошибке, объясняющее, почему это не удалось.
  • Пользователь # 2 вводит имя, которое объединяет вызов SQL, и это успешно! Программа сейчас находится в неизвестном состоянии.

  В любом случае, теперь пользователь обращается в службу поддержки и съедает времени и энергии (пользователь № 2 никогда не признает, что он сделал, что делает его более трудным для отладки) и / или требует своих денег назад .

Answer 2

Да, надо, ИМХО.

1. Большинство инъекционных атак можно предотвратить, если соблюдать правильность
   Заполнители SQL и связанные переменные, например, обрабатывают как неожиданно сформированный ввод (например, невинный апостроф в "5 o'clock"), так и злонамеренный ввод (например, "' OR 1=1 --").
   Поэтому будьте скрупулезно верны в обработке ваших данных и не беспокойтесь о большинстве инъекций.

2. Инъекции могут подорвать логику приложения
   Я думаю, что в SQLite есть триггеры, но в любом случае приложение может принимать решения на основе данных, извлеченных из локальной базы данных, атаковать другие аспекты среды и т. Д. Если сегодняшнее приложение не достаточно сложно для этого, завтрашняя версия будет.

3. Кто-то может использовать (атаковать) телефон, а не только авторизованный пользователь
   Правда, это общий риск, скажем, аутентификации рабочего стола в StackOverflow. Однако я считаю, что приложения «смартфоны» более подвержены риску непреднамеренных операторов: многие телефоны не имеют пароля, многие приложения не требуют частой повторной аутентификации, и пользователи могут свободно передавать свои телефоны людям, которым просто нужно сделать быстрый звонок.

Answer 3

Если вы синхронизируете базу данных iPhone с удаленной базой данных , не доверяйте содержимому . Для изменения базы данных не требуется SQL-инъекция. Взломанный iPhone дает пользователю полный доступ ко всей файловой системе, которая включает в себя файл базы данных sqlite, который затем может быть изменен по желанию злоумышленника. Это не инъекция sql, это уязвимость "Client Side Trust".

SQL-инъекция под sqlite полезна для злоумышленника. В отличие от MySQL, Sqlite позволяет составлять запросы, поэтому злоумышленник всегда может создать / удалить / вставить / обновить / удалить / выбрать / и т. Д. Независимо от того, на какой запрос влияет внедрение SQL. В MySQL обычно вводят вложенные выборки или объединения для получения определенных данных, но, например, вы не можете превратить оператор выбора в вставку при нормальных условиях.