测试过程中常见的安全测试漏洞(可手动测试)
一、Web安全漏洞:
1、跨站脚本攻击XSS:Cross Site Scripting,为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS
恶意攻击者往Web页面里插入恶意script代码,当用户浏览该页面时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。在不同场景下,XSS有相应不同的表现形式,主要分为反射型、存储型、DOM型的跨站脚本攻击,所造成的映像主要是窃取用户的登录凭证(Cookies)、挂马攻击、页面访问挟持等
手工测试:
1.1、反射型XSS测试:(相当于get请求页面:url里面输入)对提交页面的各个参数依次进行SQL注入测试,判定是否存在注入
比如正常访问的地址是 http://www.ccc.com/xss.jsp?id=1&name=2,依次对2个参数进行XSS测试
1.1.1、提交 http://www.ccc.com/xss.jsp?id=1”><script>alert(/xxx/)</script><!--&name=2,根据返回页面是否弹出包含xxx字符串的窗口判断是否存在反射型XSS
1.1.2、提交 http://www.ccc.com/xss.jsp?id=1&name=
‘><script>alert(/xxx/)</script><!—
“ onerror=alert(/xxx/) t=”
“ onmousemove=alert(/xxx/) t=”
‘><img src=# onerror=alert(1)>
‘><iframe src=http://www.baidu.com><’
同样的判断返回页面是否弹出包含xxx字符串的窗口判断是否存在反射型XSS
1.2、存储型XSS测试:(页面输入框进行操作)在页面表单提交测试中,依次对提交参数进行XSS测试
提交参数语句
‘><script>alert(/xxx/)</script><!—
“ onerror=alert(/xxx/) t=”
“ onmousemove=alert(/xxx/) t=”
‘><img src=# onerror=alert(1)>
</textarea><script>alert(123)</script><!--
‘><iframe src=http://www.baidu.com><’
根据返回页面是否弹出包含xxx字符串的窗口判断是否存在存储型XSS
1.3、 修复建议
对用户所有输入的数据进行过滤,在输入页面就进行拦截处理,就尽量不要进入到数据库层面进行交互了。例如:"<" ">"、"script"的关键字等
对系统输出的内容进行编码处理。例如:HTML Entity。
2、任意文件上传
任意文件上传漏洞主要是由于程序员在开发文件上传功能时,没有考虑对文件格式后缀的合法性进行校验,或只考虑在应用前端(Web浏览器端)通过javascript进行后缀校验,攻击者可上传一个包含恶意代码的动态脚本(如jsp、asp、php、aspx文件后缀)到服务器上,攻击者访问该脚本时服务器将对包含恶意代码的动态脚本解析,最终执行相应的恶意代码。该漏洞最终将可能直接影响应用系统的服务器安全,攻击者可通过所上传的脚本完全控制服务器。
手工测试:对文件上传页面进行测试
2.1、直接上传(上传格式进行客户端校验):在上传过程中,直接选择动态脚本后缀的文件,如asp、php、jsp、aspx等文件格式,观察是否上传成功
2.2、绕过JS上传(上传格式进行服务器端校验):可以用charles或burpsuite工具进行测试,详细使用方法可百度或看我抓包工具的博客
当上传页面在前端采用javascript进行文件后缀限制时,可通过HTTP抓包工具进行改包上传,将文件后缀修改为动态脚本后缀并上传提交,如果响应中显示上传成功,并且数据库里也多了一条材料数据,则需要修改
2.3、截断后缀上传:上传处理将识别到%00,并对后缀.png截断删除,如果最终显示微信.aspx文件上传成功,并且数据库里新增了数据,则需要修改
部分上传功能在对后缀名进行验证时存在缺陷,导致在文件写入过程中产生错误,导致可通过十六进制截断符(%00)对后缀进行截断
比如上传一个文件360.asp%00.jpg,上传处理时检测到%00并对.jpg字符串进行截断删除,最终导致360.asp动态脚本成功上传到了服务器
2.4、不允许绕过Content-Type检查上传:只识别了文件类型,并没有看文件格式,导致可通过改包的方式上传动态脚本到服务器上
比如Content-Type的参数值为image/jpg,程序会认为本次提交的为图片格式类型,并没有对文件格式进行后缀验证,最终成功绕过Content-Type检查,将aspx动态脚本到服务器上
2.5、 修复建议
禁止上传任意文件。对上传的文件后缀进行限制
3、 任意文件下载或读取
由于应用系统在提供文件下载或读取功能时,在文件路径参数中直接指定文件路径的同时,并没有对文件路径的合法性进行校验,导致攻击者可以通过目录跳转(..\或../)的方式下载或读取到原始知道路径之外的文件,攻击者可以通过该漏洞下载或读取系统上的任意文件,比如数据库文件,应用系统源代码,密码配置等敏感信息,造成系统的敏感信息泄露。
手工测试:
对存在文件下载或文件读取功能的页面进行测试,查看所提交的参数中是否包含文件名或文件目录,尝试提交参数值查看是否可下载或读取其他目录的文件内容;
比如:原始下载功能路径为http://www.ccc.com/donwload.jsp?filename=test123456789.pdf
其中文件路径参数为filename,通过../对路径进行跳转尝试下载其他目录下的文件,修改filename参数为../../WEB-INF/web.xml尝试下载JSP网站的配置文件(测试过程中需适当增加../跳转字符串);如提交
http://www.ccc.com/donwload.jsp?filename=../../WEB-INF/web.xml
查看是否成功下载web.xml文件。
另一种情况如下:
http://www.ccc.com/donwload.jsp?filepath=uploadfile&filename=test123.pdf
该功能通过filepath以及filename指定下载目录以及下载文件名,可修改filepath参数值进行路径跳转,同时修改filename值指定文件名;如提交
http://www.ccc.com/donwload.jsp?filepath=../../WEB-INF&filename=web.xml
查看是否成功下载web.xml文件。
4、信息泄露
信息泄露主要是由于开发人员或运维管理人员的疏忽所导致。如未及时删除调试页面、未关闭程序调试功能、未屏蔽程序错误信息、备份文件未删除、数据库备份文件未删除、未屏蔽敏感数据信息等多个方面所导致的不同严重程度的信息泄露。攻击者可通过所掌握的信息进一步分析攻击目标,从而有效发起下一步的有效攻击。
手工/工具测试:
通过目录扫描工具扫描查看是否存在敏感路径;
通过文件扫描工具扫描查看是否存在敏感文件;
通过HTTP抓包工具观察请求响应中是否包含敏感的信息返回;
通过手工提交畸形的参数名或参数值尝试引起程序跑出异常,如提交单引号,超长字符串,异常编码字符串等方式;
修复建议
禁止使用服务器的绝对路径进行文件类的操作。
二、业务逻辑安全漏洞
5、未授权访问(直接在未登录情况下操作登录成功之后的页面)
应用系统对业务功能页面并未进行有效的身份校验,在未登录且获知业务功能页面的访问地址前提下,可直接操作该页面下的功能,将可能对应用系统的恶意破坏
手工测试:
成功登录后记录各个功能页面的URL,重启浏览器并直接访问所记录的各个URL,查看是否可访问成功;
最后在项目实例中发现:后台URL添加单引号直接显示了后台的部分功能,应修改
6、登录时验证码缺陷
常见于应用系统在登录处理流程过程中,当用户登录失败后并未对当前验证码进行注销并重新刷新验证码,攻击者可至始至终提交初始的验证码发起攻击穷举攻击;同时部分应用系统验证码只在客户端浏览器验证,并未经过服务器远程验证,将可能存在绕过验证码缺陷,另一方面,在生成或获取验证码的过程中存在缺陷,攻击者将可能成功预测验证码内容或直接解析验证码内容,从而使验证码失去原有意义,最终导致一系列的穷举或遍历数据攻击。
手工测试:
账号密码如果后台设置了密文,抓包工具获取到的是否密文展示
对存在验证码的功能页面进行刷新,观察验证码生成是否具有足够的随机性;
对存在验证码的功能页面进行刷新并通过HTTP抓包工具抓取当前请求包,查看验证码的获取过程,分析获取过程中是否存在缺陷可导致验证码被解析破解;
对存在验证码的功能页面进行数据提交,并通过HTTP抓包工具抓取当前请求包,最后重新对该请求数据包进行重放,查看是否请求失败或提示验证码错误,如请求成功,即验证码并未进行有效的刷新;
7、任意手机号注册:
常见于应用系统在登录处理流程过程中,当用户登录失败后并未对当前验证码进行注销并重新刷新验证码,攻击者可至始至终提交初始的验证码发起攻击穷举攻击;同时部分应用系统验证码只在客户端浏览器验证,并未经过服务器远程验证,将可能存在绕过验证码缺陷,另一方面,在生成或获取验证码的过程中存在缺陷,攻击者将可能成功预测验证码内容或直接解析验证码内容,从而使验证码失去原有意义,最终导致一系列的穷举或遍历数据攻击。
8、密码爆破