浅谈关于web端输入涉及的安全点

一、通常对于web端输入需要检查的安全点如下

1、sql注入

2、反射型XSS

3、存储型XSS

4、SSRF漏洞

5、XXE漏洞

6、反序列化漏洞

7、CRLF注入

8、SSTI模板注

以上的漏洞都可直接使用Burp Suite 的Actively scan this host功能主动扫描漏洞，来发现关于Burp Suite的安装和详细教程可以看我往期博客Burpsuite超详细安装教程_burpsuite安装详细教程-优快云博客

其中详细资源在博客附件中有

二、具体信息

1. SQL注入

1.1常见场景：

当用户输入直接拼接到SQL查询语句中，且未经过适当过滤或验证时，攻击者可构造恶意SQL语句，从而对数据库进行未授权访问或操作。

1.2手工检测：

在输入字段中输入特殊字符，如单引号（'）、双引号（"）、分号（;）等，观察应用程序的响应。例如，在登录页面的用户名或密码字段中输入 ' OR '1'='1，若能成功登录或出现异常的数据库错误信息，则可能存在SQL注入漏洞。

1.3防护措施：

使用参数化查询，将用户输入与SQL语句分离；对用户输入进行严格的验证和过滤，去除潜在的危险字符；限制数据库用户的权限，遵循最小权限原则；定期更新和打补丁数据库管理系统。

2、反射型XSS

2.1常见场景：

2.1.1攻击特定用户

攻击者向目标用户发送包含指向漏洞链接的邮件，诱使用户点击，从而盗取用户的cookie等敏感信息。

2.1.2利用系统中的“即时消息”攻击

攻击者在即时消息中发送含有恶意脚本的链接，当接收方点击消息中的链接时，触发XSS攻击。

2.1.3利用网站漏洞

有些网站允许用户提交HTML标签，攻击者可利用此特性提交含有恶意脚本的链接，诱使用户访问，盗取用户的session信息。

2.1.4广告攻击

攻击者在含有漏洞的网站购买广告，当受害者点击广告时，触发XSS攻击，盗取session信息。

2.2手工检测方法

2.2.1寻找输入点

在目标站点上找到所有可能的输入点，如查询接口、留言板、用户登录、搜索框、订单提交等。

2.2.2输入特殊字符和唯一识别字符

在输入点处输入一组特殊字符（如<、>、"、'、/等）和一个唯一识别字符（如test123），然后提交。

2.2.3查看返回源码

提交后，查看返回的网页源代码，搜索刚才输入的唯一识别字符，确定输入的数据被输出到了什么地方。

2.2.4分析输出位置和环境

根据输出位置，分析是否可以构造执行JavaScript的条件。例如，如果输出在HTML标签之间、标签之内、JavaScript代码的值中或CSS代码的值中，分别采取不同的构造方法。

2.2.5构造并提交脚本代码

根据输出位置和环境，构造可能触发XSS的脚本代码，如

<script>alert('XSS')</script>
或
"><script>alert('XSS')</script>

等，提交后查看是否成功执行，若成功执行则说明存在XSS漏洞。

2.3防止漏洞的措施

2.3.1输入验证

对所有输入的数据进行严格的验证，确保输入的合法性和有效性，过滤掉不符合要求的字符和字符串。

2.3.2输出编码

对输出的数据进行适当的编码，如HTML实体编码、URL编码等，将特殊字符转换为对应的编码形式，防止浏览器将其解析为可执行的脚本代码。

2.3.3使用安全的编程实践

避免直接将用户输入的数据插入到HTML文档中，尽量使用模板引擎等工具，并确保模板引擎对输出进行了适当的编码和转义。

2.3.4设置内容安全策略（CSP）

通过设置CSP头部，限制页面可以加载的资源类型和来源，减少XSS攻击的风险。

3、存储型XSS漏洞

3.1常见场景

论坛评论区、用户资料页、博客评论、文件上传系统（如HTML、SVG文件）

3.2手工检测

向输入点（如评论框）提交恶意脚本，如

<script>alert('XSS')</script>

，观察是否被存储并执行。

检查数据库中存储的数据是否包含未过滤的脚本。

使用通用XSS攻击字符串手动测试。

3.3防止措施

对用户输入进行严格的验证和过滤，使用白名单机制。

对输出数据进行HTML实体编码。

使用内容安全策略（CSP）限制脚本来源。

4、SSRF漏洞

4.1常见场景

内部服务访问（如数据库、管理接口）

文件解析漏洞（如XML、JSON解析）

4.2手工检测

查看分享、下载、收藏等功能处，如果存在直接加载的url

使用Burp Suite等工具构造恶意URL，测试应用是否能访问内部服务。

检查应用对URL的处理逻辑，是否限制了访问的IP和端口。

尝试访问常见的内部服务地址，如http://127.0.0./ssrf.php?url=http://127.0.0.1/test.php 

将url=后面的http://127.0.0.1/test.php 替换成内网地址，可以访问到对应的文件则存在问题

将url=后面的http://127.0.0.1/test.php替换成本机地址file:///D:/工作资料/XX安全测试报告.doc，可以访问到对应的文件则存在问题

4.3防止措施

限制应用对内部服务的访问权限。

验证和过滤用户输入的URL。

使用安全的库和框架，避免已知漏洞。

5、XXE漏洞

5.1常见场景

文件上传功能（如XML文件）

XML解析（如SOAP请求）

5.2手工检测

参数形式为XML类型的，在XML请求参数中加入构造恶意的XML内容，如

<!DOCTYPE test [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><test>&xxe;</test>

，观察是否能读取文件，如果服务器测存在XXE漏洞，则程序在解析XML请求参数时，会将/etc/passwd的文件内容解析到test参数中，并通过&test赋值给<message>标签

检查XML解析器是否启用了外部实体解析。

5.3防止措施

禁用XML解析器的外部实体解析。

验证和过滤用户输入的XML内容。

使用安全的XML解析库。

6、反序列化漏洞

6.1常见场景

序列化对象存储（如Session、Cookie）

不安全的反序列化操作

6.2手工检测

使用 ysoserial 生成恶意序列化数据

基本命令格式：

java -jar ysoserial.jar [Payload类型] "[命令]"

其中Payload类型：选择合适的反序列化链（如 CommonsCollections1、CommonsCollections5 等）。命令：要执行的命令（如 whoami、touch /tmp/success 等）。

CommonsCollections1：通过构造一个特殊的 AnnotationInvocationHandler 对象，利用 LazyMap 和 ChainedTransformer 来触发命令执行。适用版本：适用于 JDK 1.7 和 1.8（8u71 之前）

CommonsCollections5：通过构造一个特殊的 BadAttributeValueExpException 对象，利用 TiedMapEntry 和 LazyMap 来触发命令执行。适用版本：适用于 JDK 1.8

whoami命令是用于显示当前登录用户的用户名

touch命令用于创建一个空文件或更新文件的时间戳。如果文件不存在，touch 会创建一个空文件；如果文件已存在，touch 会更新文件的访问和修改时间。

示例：
生成一个执行 whoami 命令的序列化数据：

java -jar ysoserial.jar CommonsCollections5 "whoami" > payload.ser

这会将生成的序列化数据保存到 payload.ser 文件中。

将序列化数据发送到目标服务器：
将生成的 payload.ser 文件内容替换到目标应用的输入点（如 HTTP 请求的 Cookie、参数等）。

如果目标应用使用 Cookie 存储序列化数据，可以将 payload.ser 的内容编码为 Base64，然后设置为 Cookie 值：

echo -n "payload.ser中的内容" | base64

然后将生成的 Base64 字符串作为 Cookie 的值发送到目标服务器。

测试应用是否能成功反序列化。

检查反序列化代码是否使用了不安全的类或方法。

6.3防止措施

避免反序列化不可信的数据。

使用安全的序列化格式（如JSON）。

对反序列化数据进行严格的验证。

7、CRLF注入

7.1常见场景

HTTP头注入

日志伪造

文件路径注入

7.2手工检测

请求中的参数被直接用在响应的头信息中时，在请求的参数中加入

%0A%0Dtest:%20key=value

等，看响应中是否会增加新的响应头。增加就存在漏洞

例：GET /cbew/api/ccd/common/get_list/time=1741679658673&Type=%0D%0Atest:%20key=value 

请求中有参数Type，让Type参数等于%0D%0Atest:%20key=value 

7.3防止措施

对输入进行严格的验证，过滤CRLF字符。

使用安全的库和框架，避免已知漏洞。

8、SSTI漏洞

8.1常见场景

模板引擎渲染用户输入

动态内容生成

8.2手工检测

模板引擎渲染用户输入，可以构造恶意模板表达式，如

curl -g 'http://localhost:80/page?name={{7*7}}'

，观察是否能执行计算。

如果返回结果如下：

Hello 49!<br>
OS type: posix

执行了计算就存在SSTI漏洞

检查模板引擎是否启用了沙箱模式。

8.3防止措施

禁用模板引擎的沙箱模式。

对用户输入进行严格的验证和过滤。

使用安全的模板引擎。