web安全测试要做哪些工作

　　随着互联网的不断发展，人们对网络的使用越来越频繁，通过网络进行购物、支付等其他业务操作。而一个潜在的问题是网络的安全性如何保证，一些黑客利用站点安全性的漏洞来窃取用户的信息，使用户的个人信息泄漏，所以站点的安全性变得很重要。这里跟大家讲解一下web安全测试要做哪些工作。

web安全测试要做哪些工作

　　一、大类检查点

　　二、测试项详细说明

　　上传功能

　　绕过文件上传检查功能

　　上传文件大小和次数限制

　　注册功能

　　注册请求是否安全传输

　　注册时密码复杂度是否后台校验

　　激活链接测试

　　重复注册

　　批量注册问题

　　登录功能

　　登录请求是否安全传输

　　会话固定：Session fixation attack(会话固定攻击)是利用服务器的session不变机制，借他人之手获得认证和授权，然后冒充他人。

　　关键cookie是否HTTPONLY：如果Cookie设置了HttpOnly标志，可以在发生XSS时避免JavaScript读取Cookie。

　　但很多Cookie需要给前端JS使用。所以这里只需要关注关键Cookie，即唯一标识用户及登录状态的会话标识需要添加这个属性。

　　登录请求错误次数限制

　　“记住我”功能：勾选“记住我”后，Cookie中记录了用户名和密码信息

　　本地存储敏感信息

　　验证码功能

　　验证码的一次性

　　验证码绕过

　　短信验证码轰炸：如果这个接口没有限制策略，就会被人恶意利用

　　忘记密码功能

　　通过手机号找回：不过由于程序设计不合理，导致可以绕过短信验证码，从而修改别人的密码。(使用burpsuite抓包，修改响应值true)

　　通过邮箱找回

　　密码安全性要求

　　密码复杂度要求

　　密码保存要求

　　横向越权测试

　　不同用户之间session共享，可以非法操作对方的数据。

　　纵向越权测试

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

　　XSS测试

　　跨站脚本攻击(Cross Site Scripting)：恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

　　反射型XSS：

　　利用请求参数param2，进行XSS注入，设置js等可执行或可跳转语句。param2=。

　　这个网站的已登录用户去点击，cookie会被发送到 New Site 上去。

　　处理意见：对特殊字符转义输出，特别是'"<>这几个。

　　存储型XSS

　　在论坛上发表帖子，假设论坛有漏洞，可以在帖子中注入下面的JS内容：

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

　　这是页面中注入的XSS生成的，如果你输入了账号密码，那就被发送给黑客了。

　　处理意见：对特殊字符转义输出，特别是'"<>这几个。

　　DOM型XSS

　　基于DOM型XSS样例，相比较于Reflected、Stored XSS属于server side execution issues而言，DOM based XSS 是client(browser)side execution issue。

　　Step1：如下面请求的hash部分，由客户端JS动态执行产生XSS注入。

　　http://www.webapp.com/example.jsp?param1=value1# iframeοnlοad=alert('xss')\\u003e

　　Step2：动态生成：

　　这个比较难测试，一般需要阅读页面中的JS代码，去分析。没有固定的测试步骤，还是需要大家自己多学习。不作为强制项，WebInspect扫过即可。

　　处理意见：对特殊字符转义输出，特别是'"<>。

　　SQL注入测试

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

　　这些输入参数往往包含恶意的SQL注入语句，后台处理程序没有对这些参数进行过滤，且所使用的数据库查询手段为拼接方式，进而导致敏感数据外泄。

　　在动态构造SQL语句的过程中，除了特殊字符处理不当引起的SQL注入之外，错误处理不当也会为Web站点带来很多安全隐患。

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

　　在SQL注入的过程中，如果Web服务器关闭了错误回显，那么是不是就安全了呢?答案显然是否定的，攻击者仍然可以通过 "盲注"技巧测试SQL命令是否注入成功。

　　所谓"盲注"就是在服务器没有错误回显时完成的注入方式，攻击者必须找到一个方法来验证注入的SQL语句是否执行。

　　"盲注"主要分为两种类型：基于时间的盲注和布尔盲注。

　　测试方法(黑盒)：sqlmap是一个自动化的SQL注入工具，其主要功能是扫描，发现并利用给定的URL的SQL注入漏洞，

　　测试方法(白盒)：如果项目的数据库持久层框架是mybatis，并且他的sqlmap中编写方式都是使用#{xxx}方式，而非使用${xxx}方式，就不存在SQl注入问题。

　　注：sqlMap中尽量不要使用$;$使用的是Statement(拼接字符串)，会出现注入问题。#使用的是PreparedStatement(类似于预编译)，将转义交给了数据库，不会出现注入问题;前者容易出现SQL注入之类的安全问题，所以mybatis推荐使用#。

　　写接口限制测试

　　比如：找回密码的邮件。多次调用，造成邮件轰炸。

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

　　修复建议：对写入量大的接口(如上传)做必要的限制。

　　CSRF测试

　　CSRF(Cross-site requestforgery)，中文名称：跨站请求伪造。用户C在为退出A的情况下，浏览B，B使用C的session非法访问A。

　　检查：

　　是否有防御CSRF的随机数，验证码、csrf_token等都是， 有则 (通过)

　　是否验证referer，有则(通过)

　　请求的参数均可推测，无CSRF防御机制。(不通过)

　　测试中，需要对所有写接口检查，可以采用如下方式，记录接口，标记是否已检查。

　　修复建议：

　　方法1：验证码

　　验证码使用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制CSRF攻击。

　　但是这种方式易用性方面似乎不是太好，并且对于简单的图形验证码也有很多绕过机制，是防御CSRF的一种辅助手段

　　方法2：Referer 验证

　　当浏览器发送一个HTTP请求时，一般都会在Referer中表明发起请求的URL。

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

　　因此我们无法依赖于Referer来作为防御CSRF的主要手段，但是可以通过Referer来监控CSRF攻击的发生。

　　方法3：Token验证

　　在请求原参数不变的条件下，新增了一个随机的、不可预测参数Token是目前最普遍有效的方式。

　　后端在对数据处理前会首先对Token参数进行验证，只有用户请求中的Token与用户Session(或Cookie)中的Token一致时，才会认为请求是合法的。

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

　　敏感信息泄露

　　SVN信息泄露：有数据库账号和密码等信息;

　　页面泄露敏感信息：有些WEB应用，在返回给客户端的响应中，包含了敏感信息，例如密码。

　　目录遍历

　　一个安全的Web服务器，对Web内容进行恰当的访问控制是极为关键的。目录遍历是Http所存在的一个安全漏洞，它使得攻击者能够访问受限制的目录，并在Web服务器的根目录以外执行命令。

　　利用Web应用代码进行目录遍历攻击的实例

　　在包含动态页面的Web应用中，输入往往是通过GET或是POST的请求方法从浏览器获得，以下是一个GET的Http URL请求示例：

　　http://test.webarticles.com/show.asp?view=oldarchive.html

　　利用这个URL，浏览器向服务器发送了对动态页面show.asp的请求，并且伴有值为oldarchive.html的view参数，当请求在Web服务器端执行时，show.asp会从服务器的文件系统中取得oldarchive.html文件，并将其返回给客户端的浏览器，那么攻击者就可以假定show.asp能够从文件系统中获取文件并编制如下的URL：

　　http://test.webarticles.com/show.asp?view=../../../../../Windows/system.ini

　　那么，这就能够从文件系统中获取system.ini文件并返回给用户，../的含义这里就不用多说了，相信大家都会明白。攻击者不得不去猜测需要往上多少层才能找到Windows目录，但可想而知，这其实并不困难，经过若干次的尝试后总会找到的。

　　利用Web服务器进行目录遍历攻击的实例

　　除了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站点的所有目录以判断是否存在目录遍历漏洞，如果有它会报告该漏洞并给出解决的方法，除了目录遍历漏洞以外，Web应用扫描还能检查SQL注入、跨站点脚本攻击以及其他的漏洞。

　　CRLF

　　CRLF就是HTTP响应头拆分漏洞，是对用户输入的CR 和LF字符没有进行严格的过滤导致的

　　修复建议：过滤CR和LF字符，或者转义。

　　关于web安全测试要做哪些工作就为大家介绍带这里，安全测试是测试中非常重要的一部分，这类问题往往危害巨大，可能造成企业的资产损失和名誉受损，并且传统的安全防御设备和措施收效甚微，因此往往需要借助安全厂商的力量进行web安全测试，如果您有这方面的需求可以向安全狗咨询，我们会安排专业的技术团队为您解决。