常见的安全测试漏洞

安全性测试是测试中非常重要的一部分。这类问题往往危害极大，可能造成企业的资产损失和信誉损害，而传统的安全防御设备和措施收效甚微。今天鲁牛就和大家分享一波Web安全测试的要点总结！

一、检查站的主要类别

二。测试项目的详细描述

上传功能

绕过文件上传检查功能，对上传文件的大小和频率进行限制。

注册功能

注册请求是否安全，后台是否检查注册时的密码复杂度，是否测试激活链接，重复注册，批量注册问题

登录功能

登录请求是否安全传输，会话是否固定:会话固定攻击是利用服务器的会话不变机制获得他人的认证和授权，然后冒充他人。密钥cookie是否为HTTPONLY:如果cookie上设置了HttpOnly标志，就可以阻止Javascript在XSS发生时读取cookie。但是很多cookie需要前端JS使用。所以这里我们只需要关注key cookie，也就是唯一标识用户和登录状态的session ID需要加上这个属性。

限制登录错误次数“记住我”功能:勾选“记住我”时，用户名和密码信息记录在cookie中，敏感信息存储在本地。

验证码功能

验证码一次性验证码绕过短信验证码的轰炸:如果这个接口没有限制策略，就会被恶意利用。

忘记密码功能

通过手机号找回:但由于程序设计不合理，有可能绕过短信验证码，从而修改他人密码。通过邮箱检索

密码安全要求

密码复杂性要求密码保存要求

横向越权测试

不同用户之间的会话共享可以非法操作彼此的数据。

纵向越权测试

很多应用只是简单的通过前端判断，或者低权限角色看不到对应的菜单，但是并不做后台检查当前登录用户是否有权限。

XSS测试跨站脚本攻击:恶意攻击者在网页中插入恶意脚本代码。当用户浏览页面时，会执行Web中嵌入的脚本代码，从而达到对用户进行恶意攻击的目的。

反射XSS:使用请求参数param2注入XSS，并设置可执行或可跳转的语句，如js。param2= .

该网站的登录用户单击，cookie将被发送到新网站。

处理方法:转义特殊字符的输出，尤其是' '。

XSS存储部在论坛上发布了一个帖子。假设论坛有漏洞，可以在帖子中注入以下JS内容:

当其他用户浏览帖子时，会弹出登录框。

它是由XSS注入这个页面生成的。如果你输入你的帐户密码，它将被发送给黑客。

处理方法:转义特殊字符的输出，尤其是' '。

多姆XSS标牌是根据多姆XSS标牌制作的。与属于服务器端执行问题的反射XSS和存储XSS相比，基于DOM的XSS属于客户端执行问题。

步骤1:作为下面请求的散列部分，客户机JS动态执行以生成XSS注入。

http://www.webapp.com/example.jsp param 1 = value 1 # iframeonload = alert u003e

第二步:动态生成:

处理方法:转义特殊字符的输出，尤其是' '。

SQL注入试验

SQL注入攻击的基本原理是通过构造特殊的输入参数，迫使后台数据库执行额外的SQL语句，从而获取数据库数据。

这些输入参数往往包含恶意的SQL注入语句，没有经过后台处理程序的过滤，使用的数据库查询方式是拼接，导致敏感数据的泄露。

在动态构造SQL语句的过程中，除了特殊字符处理不当导致的SQL注入，错误处理不当也会给网站带来很多安全隐患。

最常见的问题是向攻击者显示详细的内部错误信息。这些细节将为攻击者提供与网站潜在缺陷相关的重要线索。

在SQL注入过程中，如果Web服务器关闭错误回显，是否安全？显然，答案是否定的，攻击者仍然可以通过“盲注”技术测试SQL命令是否被成功注入。

所谓“盲注”，就是在服务器没有错误回显的情况下完成的注入方法。攻击者必须找到一种方法来验证注入的SQL语句是否被执行。

有两种类型的“盲注”:基于时间的盲注和布尔盲注。

测试方法:sqlmap是一个自动SQL注入工具，其主要功能是扫描、发现和利用给定URL的SQL注入漏洞

测试方法:如果项目的数据库持久层框架是mybatis，其sqlmap是用#{xxx}而不是${xxx}编写的，则不存在SQl注入问题。

注意:尽量不要在sqlMap中使用$符号；$正在使用语句，会有注入问题。#使用PreparedStatement，转义给数据库，不会有注入问题；前者容易出现SQL注入等安全问题，所以mybatis推荐使用#。

写接口极限测试

例如:检索密码的电子邮件。打了很多次电话，造成邮件轰炸。

新的界面，比如写文章，上传文件等。如果对这些接口没有限制，那么恶意用户就会通过调用程序无限循环中的接口来写入大量数据。以并发和循环的方式上传大量文件，填满磁盘，消耗服务器资源。

建议:对书写量大的界面进行必要的限制。

CSRF试验

CSRF，中文名:跨站请求伪造。用户C注销A时浏览B，B利用C的会话非法访问A。

检查:

是否有保卫CSRF的随机数，验证码，csrf_token等。，如果有，是否验证referer，如果有，可以推测所请求的参数，并且没有CSRF防御机制。在测试过程中，需要检查所有的写接口。您可以通过以下方式记录接口和标记是否已经过检查。建议:

1.验证码验证码使得用户必须与应用程序交互才能完成最终请求。因此，在正常情况下，验证码可以有效地遏制CSRF攻击。

但是这种方法似乎并不是很好用，简单的图形验证码有很多旁路机制，是防御CSRF的辅助手段。

方法二:referer验证浏览器发送HTTP请求时，一般会在Referer中指明发起请求的URL。

通过Referer，我们可以判断一个请求是否来自同一个域，从而防御CSRF，但是Referer可能包含一些敏感信息，在某些情况下甚至是伪造的。

因此，我们不能依赖Referer作为对CSRF的主要防御，但我们可以通过Referer监控CSRF攻击的发生。

方法三:令牌验证是目前最常见、最有效的方式，在请求的原始参数不变的情况下，增加一个随机的、不可预测的参数令牌。

在后端处理数据之前，它将首先验证令牌参数。只有当用户请求中的令牌与用户会话中的令牌一致时，该请求才会被视为合法。

由于Token的存在，攻击者无法构造一个完整的请求来进行CSRF攻击，从而保证了网站或系统的安全。

敏感信息泄露

SVN信息泄露:数据库账号、密码等信息；

敏感信息的页面泄漏:一些WEB应用程序在返回给客户端的响应中包含敏感信息，如密码。

目录遍历

对于一个安全的Web服务器来说，恰当地控制对Web内容的访问是非常重要的。目录遍历是Http中的一个安全漏洞，使得攻击者能够访问受限目录并在Web服务器的根目录之外执行命令。

利用Web应用程序代码进行目录遍历攻击的例子在包含动态页面的Web应用程序中，输入往往是通过GET或POST的请求方法从浏览器获得的。以下是GET的Http URL请求示例:

http://test.webarticles.com/show.asp视图=oldarchive.html

使用这个URL，浏览器向服务器发送一个动态页面show.asp请求，并附带一个值为oldarchive.html的视图参数。当请求在Web服务器上执行时，show.asp将从服务器的文件系统中获取oldarchive.html文件，并将它们返回给客户机的浏览器。然后，攻击者可以假设show.asp可以从文件系统中获取文件，并编译以下URL:

http://test.webarticles.com/show.asp视图=../../../../../Windows/system.ini

然后，这可以从文件系统中获取system.ini文件，并将其返回给用户。这里不用说了，相信大家都会明白的意思../.攻击者不得不猜测最多有多少层才能找到Windows目录，但可想而知，这并不难，尝试几次后总会找到。

除了Web应用程序的代码，Web服务器本身也可能无法抵御目录遍历攻击。这可能存在于Web服务器软件或存储在服务器上的一些示例脚本中。

在最近的Web服务器软件中，这个问题已经得到了解决，但互联网上的很多Web服务器仍然使用旧版本的IIS和Apache，它们可能仍然无法抵御这样的攻击。即使您使用已解决此漏洞的Web服务器软件版本，您仍可能有一些目录包含对黑客来说显而易见的敏感默认脚本。

例如，以下URL请求使用IIS的脚本目录来移动目录并执行指令:http://server.com/scripts/..%5c../Windows/System32/cmd . exe/c+dir+c:

这个请求将返回C:目录中所有文件的列表，这是通过调用cmd.exe，然后使用dir c:来实现的。%5c是web服务器的转换器，用来表示一些常用字符，这里表示“”

新版本的Web服务器软件会检查这些转换器并限制其通过，但对于一些旧版本的服务器软件来说，这个问题仍然存在。

判断是否存在目录遍历漏洞的最好方法是使用Web漏洞扫描器。Web漏洞扫描程序可以遍历您网站的所有目录，以判断是否存在目录遍历漏洞。如果有，它会报告漏洞并给出解决方案。除了目录遍历漏洞，Web应用程序扫描还可以检查SQL注入、跨站脚本攻击和其他漏洞。

换行符

CRLF是HTTP响应头拆分漏洞，是由于对用户输入的CR和LF字符没有进行严格的过滤造成的。

建议:过滤掉CR和LF字符，或者进行转义。