Android中是怎样防止SQL注入的？

Posted 2023-03-18

在JavaWeb中有PreparedStatement可以防止SQL注入，但是在android中有没有类似的功能呢？现在要做一个查找的功能，将本地SQLite数据库中的带有%的字段查找出来，如果我使用 字段 like "%"会直接将所有的结果都打印出来了，这是不对的。应该是输出带有%的字段，而不是打印所有字段

COPY过来有什么意思。。。。。。。 ----------------------------- 要防止SQL注入其实不难，你知道原理就可以了。 所有的SQL注入都是从用户的输入开始的。如果你对所有用户输入进行了判定和过滤，就可以防止SQL注入了。用户输入有好几种，我就说说常见的吧。 文本框、地址栏里***.asp?中？号后面的id=1之类的、单选框等等。一般SQL注入都用地址栏里的。。。。如果要说怎么注入我想我就和上面的这位“仁兄”一样的了。 你只要知道解决对吗？ 对于所有从上一页传递过来的参数，包括request.form 、request.qurrystring等等进行过滤和修改。如最常的***.asp?id=123 ，我们的ID只是用来对应从select 里的ID，而这ID一般对应的是一个数据项的唯一值，而且是数字型的。这样，我们只需把ID的值进行判定，就可以了... 参考技术A

Android中的数据多是存储在Sqlite数据库中，这个文件一般在手机的系统路径如：/data/data/com.xx.yy/databases/zzz.db。其中com.xx.yy为包名。zzz.db名字随意，为数据库文件

在安卓应用程序中，有一个非常重要的组件，即“content provider”

当应用继承ContentProvider类，并重写该类用于提供数据和存储数据的方法，就可以向其他应用共享其数据

  3.Sql注入问题

综合上面的内容，我们可以看到，query里至少两个参数我们可控，一个是projection，一个是selection，这两个都会影响SQL与的组成，也就为注入提供了可能。

这里以某app为例（虽然感觉漏洞影响有限，但是为了尊重厂商，请允许打码处理），该app对外暴露了一个content provider，uri为：content://com.masaike.mobile.downloads/my_downloads，其中com.masaike.mobile为包名，downloads为库的名字，my_downloads为表名（不一定，可自定义的哦）。

现在语句这么写：

Cursor cursor = contentResolver.query("content://com.masaike.mobile.downloads/my_downloads", new String[]"_id'","method",null, null, null);

其中_id和method为两个字段名，我们在_id后面加个单引号，运行下看logcat内容：

从上图很容易看出来，SQL语句因为有个单引号，导致出错。所以注入是存在的。

而如果我们修改projection的内容为"* from sqlite_master where type='table';--",这样子即在闭合后面查询的情况下显示出来全部的表名。当然也可以构造其他语句了。

参考技术B 1. android里也有参数化查询的, 可防止SQL 注入2. select * from table1 where col1 like '%\%%' ESCAPE '\'; 查看原帖>>本回答被提问者采纳 参考技术C 安卓系统相当于linux 获取了root相当于获取管理员权限 SQL的注入是需要管理员权限许可才可执行，否则不可 参考技术D 不允许用户输入特殊符号，从根本上防止注入

php如何防止SQL注入

    通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

在用户名输入框中输入:‘ or 1=1#,密码随便输入，这时候的合成后的SQL查询语句为#在mysql中是注释符，这样井号后面的内容将被mysql视为注释内容，这样就不会去执行了,等价于

  

select * from users where username=‘‘ or 1=1

　　

SQL 注入是PHP应用中最常见的漏洞之一。事实上令人惊奇的是，开发者要同时犯两个错误才会引发一个SQL注入漏洞，一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。这两个重要的步骤缺一不可，需要同时加以特别关注以减少程序错误。

幸运的是，SQL注入是很容易避免的，只坚持过滤输入和转义输出。

虽然两个步骤都不能省略，但只要实现其中的一个就能消除大多数的SQL注入风险。如果你只是过滤输入而没有转义输出，你很可能会遇到数据库错误（合法的数据也可能影响SQL查询的正确格式），但这也不可靠，合法的数据还可能改变SQL语句的行为。另一方面，如果你转义了输出，而没有过滤输入，就能保证数据不会影响SQL语句的格式，同时也防止了多种常见SQL注入攻击的方法。

当然，还是要坚持同时使用这两个步骤。过滤输入的方式完全取决于输入数据的类型，但转义用于向数据库发送的输出数据只要使用同一个函数即可。对于MySQL用户，可以使用函数mysql_real_escape_string()：或者使用php自带的addslashes()方法转义字符串。