在您自己的 iPhone 上防止 sqlite 注入攻击？
当数据保存在某人的 iPhone 和云上的远程数据库之间时，我总是对 SQL 注入攻击采取预防措施。
但是，当只是将数据（使用 sqlite）从某人的手机保存到他们自己手机上的数据库时，是否也有必要这样做？
他们能做的最糟糕的事情是什么？删除自己手机上自己的数据（或表格）？ （如果他们真的足够努力的话。）
谢谢。
I always take precautions regarding SQL INJECTION ATTACKS when data is saved between someone's iPhone and a remote database on the cloud.
But is it also necessary to do the same... when just saving data (using sqlite) from someone's cell phone, to a database that's just on their own phone?
What's the worse they can do? Delete their own data (or tables) on their own phone?
(If they really try hard enough.)
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有必要吗？ - 是的，它是“必要的”，即它可能值得。即使您不太关心这种情况下的安全性（这可能是有效的），您也应该担心正确性（至少是值得骄傲的问题）。
可能发生的最坏情况是什么？
Patty O'Brian将她的名字输入到一个字段中，该字段搞乱了 SQL 调用，导致 SQL 调用失败。程序要么不能很好地处理它，要么用户收到一条关于失败原因的模糊错误消息。无论哪种方式，现在用户都会联系支持人员并消耗时间和精力（用户#2从不承认他们做了什么，这使得调试变得更加困难）和/或要求他们的退款。
Is it necessary? - Yes, its "necessary", i.e. its probably worth it. Even if you don't care much about security in this context (which may be valid), you should worry about correctness (at the very least, its matter of pride).
What's the worst that could happen?
Patty O'Brianenters her name into a field that gums up the SQL call and it fails. The program either doesn't handle it well or the user gets an ambiguous error message as to why it failed.Either way, now the user contacts support and eats up time and energy (user #2 never admitting what they did, making it even more difficult to debug) and/or demands their money back.
是的，这是必要的，恕我直言。
大多数注入攻击都可以通过遵守正确性来预防
例如，SQL 占位符和绑定变量可以处理意外形成的输入（例如，
"5 o'clock"中的无辜撇号）和恶意输入（例如，"' OR 1=1 --")。因此，在数据处理时要小心谨慎，不要担心大多数注入。
注入可能会破坏应用程序逻辑
我认为 SQLite 有触发器，但在任何情况下，应用程序都可能根据从本地数据库提取的数据做出决策，攻击环境的其他方面等。如果今天的应用程序对此还不够复杂，那么明天的应用程序就会复杂。
其他人可能正在使用（攻击）手机，而不仅仅是授权用户
确实，这是一种常见风险，例如通过 StackOverflow 进行身份验证的桌面。然而，我发现“智能手机”应用程序更容易遭受非预期操作者的攻击：许多手机没有密码，许多应用程序不需要频繁的重新验证，用户可以随意将手机交给只需要快速拨打电话的人。
Yes, it is necessary, IMHO.
The majority of injection attacks can be prevented by adherence to correctness
SQL placeholders and bound variables, for example, handle both unexpectedly formed input (e.g., the innocent apostrophe in
"5 o'clock") and malicious input (e.g.,"' OR 1=1 --").So, be scrupulously correct in your data handling, and don't worry about most injections.
Injections might subvert application logic
SQLite has triggers, I think, but in any case the application might make decisions based on data pulled from the local db, attacking other facets of the environment, etc. If today's application isn't complex enough for this, tomorrow's rev will be.
Someone else might be using (attacking) the phone, not just an authorized user
True, this is generic risk of, say, the desktop authenticated to StackOverflow. However, I find that "smartphone" apps are more at risk of unintended operators: many phones have no passcode, many apps require no frequent re-authentication, and users may freely give their phones to people who just need to make a quick call.
如果您要将 iPhone 数据库与远程数据库同步，请勿信任该内容。不需要 SQL 注入来更改数据库。越狱的 iPhone 允许用户完全访问整个文件系统，其中包括 sqlite 数据库文件，然后攻击者可以根据需要对其进行修改。这不是 SQL 注入，这是“客户端信任”漏洞。
sqlite 下的 SQL 注入对于攻击者来说非常有用。与 MySQL 不同，Sqlite 允许您堆叠查询，因此攻击者始终可以创建/删除/插入/更新/删除/选择/等，无论什么查询受到 SQL 注入的影响。在 MySQL 中，通常会注入子查询或联合查询来获取特定数据，但例如在正常情况下您无法将 select 语句转换为插入。
If you are syncing an iPhone database with a remote database do not trust the content. It doesn't take SQL Injection to change the database. A jailbroken iPhone gives the user full access to entire file system which includes the sqlite database file, this can then be modified however the attacker wants. This isn't sql injection, this is a "Client Side Trust" vulnerability.
SQL Injection under sqlite is useful to an attacker. Unlike MySQL, Sqlite allows you to stack queries, so the attacker can always create/drop/insert/update/delete/select/etc no matter what query is affected by sql injection. Under MySQL its common to inject sub-selects or union-selects to obtain specific data, but for instance you cannot turn a select statement into an insert under normal conditions.