为什么要保护 WebSQL 数据库免受 SQL 注入，如果它可以使用开发控制台进行编辑？
Why should a WebSQL database be protected against SQL injection, if it can be edited with the development console?
我正在开发一个仅用于学习目的的客户端 Web 应用程序，使用 WebSQL 来存储和查询数据，并使用 Javascript 来处理它。 WebSQL 不再维护，但该问题可能对所有客户端数据库都有效。
在 W3C 的 proposed specification for WebSQL 中，§8.5 推荐了一种特定的语法（使用 ? 作为值的占位符的参数化查询）来避免 SQL 注入攻击。
鉴于用户可以自由修改网页中使用的 Javascript 代码，包括 SQL 语句（或使用开发控制台或其他浏览器工具更改数据库），为什么要程序准备好避免 SQL 注入？
我在 WebSQL、this one, this one and this answer 中发现了三个与 SQL 注入相关的 Whosebug 问题，但其中 none 强调了为什么 SQL 注入是一个问题在客户端数据库上。
可能其他人有明确的动机，为什么 SQL 注入是客户端数据库的一个问题？
我会说 "an SQL injection attack" 与 "I'm gonna modify the program, or better yet, just write my own" 攻击 不同 。
是的，您完全正确地观察到用户可以对数据库和对结束于[=18=的软件源代码做任何他想做的事情]他的电脑。但是，这不是 "SQL injection."
"SQL injection," 我认为，代表任何情况，其中 一个局外人 从外部 有效地修改了数据库结构或内容， 无需直接修改源代码或提供自己的新源代码。
很可能会争论，因为本质上您只是 做了， SQL 注入对于仅存在于客户端 电脑。我认为你的论点是站得住脚的。但是，我不认为这是放弃使用参数的成功论据。我断然建议人们 永远不要 将文字、外部提供的值插入任何 SQL 字符串，"period."
SQL 考虑第三方对数据库的不需要的操作时，注入是有意义的。
客户端 Web 应用程序涉及：
- 设计数据库和SQL语句的开发人员；
- 用户，可以使用浏览器工具修改它们；
- 第三方脚本，如库，无法访问应用程序数据库。
实际上，数据库是特定于一个来源的，因此脚本无法打开属于另一个来源的数据库：
- If no database with the given name from the origin origin exists, then create the database
（WebSQL W3C specification 的第 4.1 节）
第三方攻击脚本可能会利用页面的DOM在表单输入中填写攻击代码，在提交表单时注入攻击代码（可能是攻击者自己调用submit() 表单元素的方法）。为避免这种情况，请使用参数化查询：用户输入永远不会被解释为 SQL 代码。
我正在开发一个仅用于学习目的的客户端 Web 应用程序，使用 WebSQL 来存储和查询数据，并使用 Javascript 来处理它。 WebSQL 不再维护，但该问题可能对所有客户端数据库都有效。
在 W3C 的 proposed specification for WebSQL 中，§8.5 推荐了一种特定的语法（使用 ? 作为值的占位符的参数化查询）来避免 SQL 注入攻击。
鉴于用户可以自由修改网页中使用的 Javascript 代码，包括 SQL 语句（或使用开发控制台或其他浏览器工具更改数据库），为什么要程序准备好避免 SQL 注入？
我在 WebSQL、this one, this one and this answer 中发现了三个与 SQL 注入相关的 Whosebug 问题，但其中 none 强调了为什么 SQL 注入是一个问题在客户端数据库上。
可能其他人有明确的动机，为什么 SQL 注入是客户端数据库的一个问题？
我会说 "an SQL injection attack" 与 "I'm gonna modify the program, or better yet, just write my own" 攻击 不同 。
是的，您完全正确地观察到用户可以对数据库和对结束于[=18=的软件源代码做任何他想做的事情]他的电脑。但是，这不是 "SQL injection."
"SQL injection," 我认为，代表任何情况，其中 一个局外人 从外部 有效地修改了数据库结构或内容， 无需直接修改源代码或提供自己的新源代码。
很可能会争论，因为本质上您只是 做了， SQL 注入对于仅存在于客户端 电脑。我认为你的论点是站得住脚的。但是，我不认为这是放弃使用参数的成功论据。我断然建议人们 永远不要 将文字、外部提供的值插入任何 SQL 字符串，"period."
SQL 考虑第三方对数据库的不需要的操作时，注入是有意义的。
客户端 Web 应用程序涉及：
- 设计数据库和SQL语句的开发人员；
- 用户，可以使用浏览器工具修改它们；
- 第三方脚本，如库，无法访问应用程序数据库。
实际上，数据库是特定于一个来源的，因此脚本无法打开属于另一个来源的数据库：
- If no database with the given name from the origin origin exists, then create the database
（WebSQL W3C specification 的第 4.1 节）
第三方攻击脚本可能会利用页面的DOM在表单输入中填写攻击代码，在提交表单时注入攻击代码（可能是攻击者自己调用submit() 表单元素的方法）。为避免这种情况，请使用参数化查询：用户输入永远不会被解释为 SQL 代码。