php sql json防注入,【网络安全】SQL注入、XML注入、JSON注入和CRLF注入科普文

SQL注入

所谓SQL注入，是将恶意SQL命令通过某种方式提交到服务器后台，并欺骗服务器执行这些恶意的SQL命令的一种攻击方式。 —— [ 百度百科 ]

造成SQL注入漏洞原因有两个：一个是没有对输入的数据进行过滤(过滤输入)，还有一个是没有对发送到数据库的数据进行转义(转义输出)。

一些寻找SQL漏洞的方法

http://host/test.php?id=100 and 1=1 //返回成功

http://host/test.php?id=100 and 1=2 //返回失败

http://host/test.php?name=rainman ‘ and ‘1’=‘1 //返回成功

http://host/test.php?name=rainman ‘ and ‘1’=‘2 //返回失败

http://host/test.php?name=rainman ‘ and ‘1’=‘2 )) //使用括号进行语句闭合

//在具有模糊搜索的地方

1)先搜索(')，如果出错，说明90%存在这个漏洞。

2)然后搜索(%)，如果正常返回，说明95%有洞了。

3)然后再搜索一个关键字，比如(2006)吧，正常返回所有2006相关的信息。

4)再搜索(2006%'and 1=1 and '%'=')和(2006%'and 1=2 and '%'=')。

//看看能否绕过验证

(1) 用户名输入： ‘or 1=1 or’ 密码：任意

(2) Admin’ -- (或’or 1=1 or’ --)(admin or 1=1 --) (MSSQL)(直接输入用户名，不进行密码验证)

(3) 用户名输入：admin 密码输入：’ or ‘1’=‘1 也可以

(4) 用户名输入：admin' or 'a'='a 密码输入：任意

(5) 用户名输入：’ or 1=1 --

(6) 用户名输入：admin’ or 1=1 -- 密码输入：任意

(7) 用户名输入：1'or'1'='1'or'1'='1 密码输入：任意

//不同的SQL服务器连结字符串的语法不同，比如MS SQL Server使用符号+来连结字符串，而Oracle使用符号||来连结

http://host/test.jsp?ProdName=Book’ //返回错误

http://host/test.jsp?ProdName=B’+’ook //返回正常

http://host/test.jsp?ProdName=B’||’ook //返回正常说明有SQL注入

如果应用程序已经过滤了’和+等特殊字符，我们仍然可以在输入时过把字符转换成URL编码(即字符ASCII码的16进制)来绕过检查。

防御SQL注入

对输入进行过滤；

使用预编译的SQL语句，比如Java中的PreparedStatement；

使用存储过程(不是所有场景都使用，这个方法不是很推荐)；

MyBatis的SQL注入防护—模糊查询-- MySQL

select * from table where name like concat('%',#{name},'%')

-- Oracle

select * from table where name like '%' || #{name} || '%'

-- SQL Server

select * from table where name like '%'+#{name}+'%'

-- DB2

select * from table where name like concat('%',#{name},'%')

SQL注入相关的优秀博客

XML注入

什么是XML注入

XML的设计宗旨是传输数据，而非显示数据。XML注入是一种古老的技术，通过利用闭合标签改写XML文件实现的。

下面举个最简单的例子

用户输入

root

若攻击者刚好能掌控用户输入字段，输入 adminhacker ,最终修改结果为:

admin

hacker

root

这样我们可以通过XML注入添加一个管理员账户。

预防XML注入

对有改变XML结构的特殊输入进行过滤或者编码；

对["&","","'".'"',"/"]这些特殊字符过滤。

JSON注入

什么是JSON注入

我们知道JSON是根据引号(")、冒号(:)、逗号(,)和花括号({})区分各字符的意义的。如果有恶意用户向JSON中注入恶意字符，那么JSON将解析失败。例如，输入的PassWord值为：admin"888

那么组装成的JSON数据位如下：

"PassWord":" admin"888"

在PassWord中的引号将会破坏整个JSON的结构，导致JSON解析失败。JSON注入没有其他几种注入的危害性大，但依然不可小视，笔者一直认为没有低危的漏洞，只是还没碰到可利用的场景，攻击者可能通过这类低危漏洞辅助其他攻击，这时低危漏洞将不再低危。

JSON注入的防御

如何防御JSON注射呢？方法依然很简单，只需要对其关键字符进行转义即可，如：将"admin"888"转换为"admin"888"，这样JSON的值就可以解析了。如果字符串中出现""，同样需要将其转义""。

CRLF注入

我们知道：一个HTTP请求报文由四个部分组成：请求行、请求头部、空行、请求数据。请求报文格式就如下图所示：

参考博客

我们可以发现请求行和请求头的尾部都有CRLF标志，请求头和请求体之间也是通过CRLF标志分割的。CRLF注入漏洞就是利用Http的这种报文结构，向请求行或请求头的字段注入恶意的CRLF，就能注入一些首部字段或报文主体(请求响应数据)，并在响应中输出，所以CRLF又称为HTTP响应拆分漏洞(HTTP Response Splitting)。

CRLF介绍

CRLF指的是回车符(CR，ASCII 13，r，%0d) 和换行符(LF，ASCII 10，n，%0a)。CRLF的概念最早源自打字机，表明行的结束，计算机出现后沿用了这个概念。

回车符(r)的作用是将光标移到行首，换行符(n)的作用是将光标垂直移到下行。键盘上的回车键(Enter)就可以执行该操作。但是不同的操作系统，行的结束符是不一样的。Windows系统使用CRLF表示行的结束，Linux/Unix系统使用LF表示行的结束，MacOS系统早期使用CR表示，但是现在好像也用LF表示行的结束。所以同一文件在不同操作系统中打开，内容格式可能会出现差异，这是行结束符不一致导致的。

在HTTP规范中，行使用CRLF来结束。首部与主体由两个CRLF分隔，浏览器根据这两个CRLF来获取HTTP内容并显示。

CRLF漏洞检测

CRLF注入漏洞的本质和XSS有点相似，攻击者将恶意数据发送给易受攻击的Web应用程序，Web应用程序将恶意数据输出在HTTP响应头中(XSS一般输出在主体中)。所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。

总结下：

如果你找到了一个你传给Web程序的参数最后会在响应的Http头部回显，那么这个地方可能就是一个存在CRLF注入漏洞的地方。

CRLF漏洞预防

过滤参数中的rn之类的行结束符；

输入参数尽量不要在相应头部回显，如果非要回显的话一定要对该字段的输入值进行严格的过滤。

内容来源于网络如有侵权请私信删除