典型网站漏洞分类影响及解决方案.docx
《典型网站漏洞分类影响及解决方案.docx》由会员分享，可在线阅读，更多相关《典型网站漏洞分类影响及解决方案.docx（10页珍藏版）》请在冰豆网上搜索。
典型网站漏洞分类影响及解决方案
典型网站漏洞分类影响及解决方案
本文由s8h4a2n6贡献
doc文档可能在WAP端浏览体验不佳。
建议您优先选择TXT,或下载源文件到本机查看。
一、
典型网站漏洞分类
根据风险等级,网站漏洞一般可分为高风险、中风险和低风险三种。
其中高风险漏洞是必须封堵的。
中、低风险漏洞中有一部分是必须封堵的。
还有一部分中、低风险漏洞,由于其封堵的代价可能远高于不封堵所造成的损失,因而能够进行选择性封堵。
能够采取工具亿思平台进行其网站的漏洞扫描,具体地址为:
典型网站漏洞的分类及相应的封堵要求如下表所示:
风险等级
高风险1、SQL注入漏洞2、跨站漏洞
中、低风险1、默认测试用例文件2、管理后台登陆入口
中、低风险1、存在电子邮件地址
漏洞名称
3、XPATH注入漏3、应用程序错误引起的2、无效链接洞信息泄露4、备份文件造成的源代码泄漏3、Web应用默认目录
封堵要求
必须封堵
选择封堵
1
二、
典型网站漏洞影响及解决方案
1、SQL注入漏洞漏洞影响:
本漏洞属于Web应用安全中的常见漏洞,属于OWASPTOP10（）中的注入类漏洞。
很多WEB应用中都存在SQL注入漏洞。
SQL注入是一种攻击者利用代码缺陷进行攻击的方式,可在任何能够影响数据库查询的应用程序参数中利用。
例如url本身的参数、post数据或cookie值。
正常的SQL注入攻击很大程度上取决于攻击者使用从错误消息所获得信息。
可是,即使没有显示错误消息应用程序仍可能受SQL注入的影响。
总体上讲,SQL注入是对web应用而不是对web服务器或操作系统本身的攻击。
正如其名称所示,SQL注入是对查询添加非预期SQL命令从而以数据库管理员或开发人员非预期的方式操控数据库的行为。
如果成功的话,就能够获得、修改、注入或删除有漏洞web应用所使用数据库服务器的数据。
在某些环境下,可利用SQL注入完全控制系统。
解决方案:
防护建议包括部署分层安全措施（包括在接受用户输入时使用参数化的查询）、确保应用程序仅使用预期的数据、加固数据库服务器防止不恰当的访问数据。
建议使用以下措施防范SQL注入漏洞:
2
对于开发========使用以下建议编写不受SQL注入攻击影响的web应用。
参数化查询:
SQL注入源于攻击者控制查询数据以修改查询逻辑,因此防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔,这能够防止执行从用户输入所注入的命令。
这种方式的缺陷是可能对性能产生影响（但影响很小）,且必须以这种方式构建站点上的每个查询才能完全有效。
只要无意中绕过了一个查询,就足以导致应用受SQL注入的影响。
以下代码显示的是能够进行SQL注入的SQL语句示例。
sSql="SELECTLocationNameFROMLocations";sSql=sSql+"WHERELocationID="+Request["LocationID"];oCmd.CommandText=sSql;
下面的例子使用了参数化的查询,不受SQL注入攻击的影响。
sSql="SELECT*FROMLocations";sSql=sSql+"WHERELocationID=@LocationID";oCmd.CommandText=sSql;oCmd.Parameters.Add（"@LocationID",Request["LocationID"]）;
应用程序没有包含用户输入向服务器发送SQL语句,而是使用-@LocationID-参数替代该输入,这样用户输入就无法成为SQL执行的命令。
3
这种方式能够有效的拒绝攻击者所注入的任何输入,尽管仍会生成错误,但仅为数据类型转换错误,而不是黑客能够利用的错误。
以下代码示例显示从HTTP查询字符串中获得产品ID并使用到SQL查询中。
请注意传送给SqlCommand的包含有SELECT的字符串仅仅是个静态字符串,不是从输入中截取的。
另外还请注意使用SqlParameter对象传送输入参数的方式,该对象的名称（@pid）匹配SQL查询中所使用的名称。
C#示例:
string
connString
=
WebConfigurationManager.ConnectionStrings["myConn"].ConnectionString;using（SqlConnectionconn=newSqlConnection（connString））{conn.Open（）;SqlCommandcmd=newSqlCommand（"SELECTCount（*）FROMProductsWHEREProdID=@pid",conn）;SqlParameterprm=newSqlParameter（"@pid",SqlDbType.VarChar,50）;prm.Value=Request.QueryString["pid"];cmd.Parameters.Add（prm）;intrecCount=（int）cmd.ExecuteScalar（）;}
4
VB.NET示例:
Dim
connString
As
String
=
WebConfigurationManager.ConnectionStrings（"myConn"）.ConnectionString
UsingconnAsNewSqlConnection（connString）conn.Open（）DimcmdAsSqlCommand=NewSqlCommand（"SELECTCount（*）FROMProductsWHEREProdID=@pid",conn）DimprmAsSqlParameter=NewSqlParameter（"@pid",
SqlDbType.VarChar,50）prm.Value=Request.QueryString（"pid"）cmd.Parameters.Add（prm）DimrecCountAsInteger=cmd.ExecuteScalar（）EndUsing
验证输入:
可经过正确验证用户输入的类型和格式防范大多数SQL注入攻击,最佳方式是经过白名单,定义方法为对于相关的字段只接受特定的帐号号码或帐号类型,或对于其它仅接受英文字母表的整数或字母。
很多开发人员都试图使用黑名单字符或转义的方式验证输入。
总体上讲,这种方式经过在恶意数据前添加转义字符来拒绝已知的恶意数据,如单引号,这样之后的项就能够用作文字值。
5
这种方式没有白名单有效,因为不可能事先知道所有形式的恶意数据。
对于安全操作============
使用以下建议帮助防范对web应用的SQL注入攻击。
限制应用程序权限:
限制用户凭据,仅使用应用运行所必须权限的。
任何成功的SQL注入攻击都会运行在用户凭据的环境中,尽管限制权限无法完全防范SQL注入攻击,但能够大大增加其难度。
强系统管理员口令策略:
一般攻击者需要管理员帐号的功能才能使用特定的SQL命令,如果系统管理员口令较弱的话就比较容易暴力猜测,增加成功SQL注入攻击的可能性。
另一个选项就是根本不使用系统管理员口令,而是为特定目的创建特定的帐号。
一致的错误消息方案:
确保在出现数据库错误时向用户提供尽可能少的信息。
不要泄漏整个错误消息,要同时在web和应用服务器上处理错误消息。
当web服务器遇到处理错误时,应使用通用的web页面响应,或将用户重新定向到标准的位置。
绝不要泄漏调试信息或其它可能对攻击者有用的细节。
有关如何在IIS中关闭详细错误消息的说明请见:
6
使用以下句法在Apache服务器上取缔错误消息:
Syntax:
ErrorDocument<3-digit-code>Example:
ErrorDocument500/webserver_errors/server_error500.txt
WebSphere之类的应用服务器一般默认安装启用了错误消息或调试设置。
有关如何取缔这些错误消息的信息,请参考应用服务器文档。
存储过程:
如果不使用的话,请删除master..Xp_cmdshell、xp_startmail、xp_sendmail、sp_makewebtask之类的SQL存储过程。
SQL注入漏洞根本上还是取决于web应用程序的代码。
尽管不是修复,但能够经过向IDS中添加结合了正则表示式的规则作为紧急措施检测SQL注入攻击。
尽管这无法修复所有可能的SQL注入漏洞,但便于实施,而且要求攻击者必须要改进其方法才能实现成功的攻击。
可如下使用正则表示式。
删除SQL元字符的正则表示式:
/（\%27）|（\'）|（\-\-）|（\%23）|（#）/ix
7
可如下将上述正则表示式添加到Snort规则:
alerttcp$EXTERNAL_NETany->$HTTP_SERVERS$HTTP_PORTS（msg:
"SQLInjection-
Paranoid";flow:
to_server,established;uricontent:
".pl";pcre:
"/（\%27）|（\'）|（\-\-）|（%23）|（#）/i";classtype:
Web-application-attack;sid:
9099;rev:
5;）
传统SQL注入攻击的正则表示式:
/\w*（（\%27）|（\'））（（\%6F）|o|（\%4F））（（\%72）|r|（\%52））/ix
删除有UNION关键字的SQL注入攻击的正则表示式:
/（（\%27）|（\'））union/ix（\%27）|（\'）
可为其它的SQL查询（如select、insert、update、delete、drop等）编写类似的正则表示式。
在MSSQL服务器上检测SQL注入攻击的正则表示式:
/exec（\s|\+）+（s|x）p\w+/ix
对于质量保证============
8
解决SQL注入缺陷最终要求基于代码的修复,”对于开发”和”对于安全操作”部分所述的步骤提供了修复这些漏洞所必要的信息。
以下步骤概述了如何对应用程序手动测试SQL注入。
如何对应用程序手动测试SQL注入:
1.在浏览器中打开希望测试SQL注入漏洞的web应用。
2.将鼠标光标悬停在Web站点的链接上并注意底部的状态栏,能够看到链接所指向的URL。
找到其中带有参数的URL,如
注释:
如果没有在状态栏中看到任何URL,请点击链接然后查看地址栏,直到找到带有参数的URL。
3.找到带有参数的URL后,点击链接进入网页,在地址栏中能够看到状态栏中的URL。
4.有两种测试SQL注入脚本的方法,请使用全部两种方式依次测试每个参数值。
方法1.在地址栏中点击光标,高亮显示参数值,如高亮显示name=value中的value并
9
用单引号（'）替换,这时应类似于name='。
方法2.在地址栏中点击光标,在value中间输入单引号（'）,这时应类似于name=val'ue。
5.点击GO键将请求发送到Web服务器。
6.分析Web服务器响应中的错误消息,大多数数据库错误消息都类似于以下示例:
Exampleerror1:
MicrosoftOLEDBProviderforSQLServererror'80040e14'Unclosedquotationmarkbeforethecharacterstring'51ORDERBYsome_name'./some_directory/some_file.asp,line5
Exampleerror2:
ODBCErrorCode=S1000（Generalerror）[Oracle][ODBC][Ora]ORA-00933:
SQLcommandnotproperlyended
Exampleerror3:
Error:
1353SQLSTATE:
HY000（ER_VIEW_WRONG_LIST）Message:
View'sSELECTandview'sfieldlisthavedifferentcolumncounts
10
7.有时错误消息并不明显,隐藏在页面源码中。
如果要查看这些消息,必须查看页面的HTML源码并搜索错误。
如果要在InternetExplorer中实现这个操作,点击”查看”菜单,然后选择”源码”选项,这能够打开记事本显示页面的HTML源码。
在记事本中,打开”编辑”菜单并选择”查找”。
这时会出现一个对话框询问”查找内容”。
输入MicrosoftOLEDB或[ODBC]然后点击”查找下一个”。
8.如果6或7步成功,则Web站点存在SQL注入漏洞。
2、跨站漏洞漏洞影响:
跨站脚本攻击（也称为XSS）指利用网站漏洞从用户那里恶意盗取信息。
用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时,一般会点击其中的链接。
攻击者经过在链接中插入恶意代码,就能够盗取用户信息或在终端用户系统上执行恶意代码。
成功的跨站脚本攻击所带来的主要问题包括:
帐号劫持-攻击者能够在会话cookie过期之前劫持用户的会话,并以访问ULR用户的权限执行操作,如发布数据库查询并查看结果。
恶意脚本执行-用户可能在不知情的情况下执行攻击者注入到动态生成页面中的JavaScript、VBScript、ActiveX、HTML甚至Flash内容。
蠕虫传播-经过Ajax应用,跨站脚本能够以类似于病毒的方式传播。
跨站
11
脚本负载能够自动将其自身注入到页面中,并经过更多的跨站脚本轻易的重新注入同一主机,而所有这些都无需手动刷新页面。
因此,跨站脚本能够使用复杂的HTTP方式发送多个请求,并以用户不可视的方式自我传播。
信息窃取-攻击者能够经过重新定向和伪造站点将用户连接到攻击者所选择的恶意服务器并获得用户所输入的任何信息。
拒绝服务-一般攻击者经过在包含有跨站脚本漏洞的站点上使用畸形的显示请求,就能够导致主机站点重复的自我查询,出现拒绝服务的情况。
浏览器重新定向-在某些使用帧的站点上,用户可能在实际上已经被重新定向到恶意站点的情况下误导为仍处在原始站点上,因为浏览权地址栏中的URL仍保持不变。
这是由于没有重新定向整个页面,而只是执行JavaScript的帧。
控制用户设置-攻击者能够恶意更改用户设置。
本漏洞属于Web应用安全常见漏洞。
解决方案:
推荐措施包括实施安全编程技术确保正确过滤用户提供的数据,并编码所有用户提供的数据以防以可执行的格式向终端用户发送注入的脚本。
对于开发
12
========
可经过仔细验证所有输入和正确编码所有输出来防范跨站脚本攻击。
可使用标准的ASP.NET验证控件或直接在代码中实施验证,要尽可能使用严格的模版。
输出编码要确保在将内容发送给客户端之前对任何可脚本化的内容都进行了正确的HTML编码。
可经过HttpUtility.HtmlEncode函数实现,如以下Label控件示例所示:
Label2.Text=HttpUtility.HtmlEncode（input）
考虑用户输入经过应用可能用到的所有路径。
例如,如果数据是由用户输入的,存储在数据库中,然后再重新显示,就必须要确保在每次检索的时候都能正确编码。
如果必须允许自由格式文本输入（如在消息板中）,而又希望允许使用一些HTML格式,则能够经过仅明确允许很小的安全标签列表来安全的处理这种情况,如下所示:
C#示例:
StringBuildersb=newStringBuilder（HttpUtility.HtmlEncode（input））;sb.Replace（"",""）;sb.Replace（"",""）;
13
sb.Replace（"",""）;sb.Replace（"",""）;Response.Write（sb.ToString（））;
VB.NET示例:
DimsbAsStringBuilder=NewStringBuilder（_HttpUtility.HtmlEncode（input））sb.Replace（"",""）sb.Replace（"",""）sb.Replace（"",""）sb.Replace（"",""）Response.Write（sb.ToString（））
Java示例:
publicstaticStringHTMLEncode（StringaTagFragment）{finalStringBufferresult=newStringBuffer（）;finalStringCharacterIteratoriterator=newStringCharacterIterator（aTagFragment）;charcharacter=iterator.current（）;while（character!
=StringCharacterIterator.DONE）{if（character=='<'）{result.append（"<"）;}elseif（character=='>'）{result.append（">"）;}
14
elseif（character=='\"'）{result.append（"""）;}elseif（character=='\"）{result.append（"'"）;}elseif（character=='\\'）{result.append（"\"）;}elseif（character=='&'）{result.append（"&"）;}else{//thecharisnotaspecialone//addittotheresultasisresult.append（character）;}character=iterator.next（）;}returnresult.toString（）;}
以下建议可帮助构建能够抵御跨站脚本攻击的web应用。
定义允许的内容。
确保web应用对所有输入参数（cookies、头、查询字符串、表单、隐藏字段等）验证严格定义的预期结果。
检查POST和GET请求的响应,确保返回内容是预期的且有效。
经过编码用户提供的数据从用户输入中删除冲突字符、括号、单双引号。
这能够防范以可执行的方式向终端用户发送注入的脚本。
在可能的时候将所有客户端提供的数据仅限于字母数字的数据。
使用这种过滤方案时,如果用户输入了,就会被减少为scriptalertdocumentcookiescript。
如果必须使用非字母数字字符,在HTTP响应中使用之前将其编码为HTML实体,这样就无法将其用于修改HTML文档的结构。
使用双重用户认证机制而不是单重认证。
在修改或使用脚本之前确认其来源。
在自己的代码中使用时不要明确的信任任何来自她人的脚本,无论是从web下载还是来自熟人。
大多数服务器端脚本语言都提供了内嵌方式将输入变量的值转换为正确的不
15
可解释HTML。
应使用这种方式在将输入显示给客户端之前过滤所有输入。
PHP:
stringhtmlspecialchars（stringstring[,intquote_style]）ASP/ASP.NET:
Server.HTMLEncode（strHTMLString）
对于安全操作============服务器端编码指的是首先经过编码函数发送所有的动态内容,使用所选择字符集中的代码替换Scripting标签,这能够帮助防范跨站脚本攻击。
服务器端编码的缺点是可能耗费资源,对一些web服务器的性能产生负面影响。
如果必须允许站点用户使用HTML标签,如允许用户使用的格式化标签的公告栏,则应限制可使用的标签。
创立可接受标签的列表,如粗体字、斜体字或下划线,并仅允许使用这些,拒绝任何其它标签。
以下是一些可帮助检测跨站脚本的正则表示式。
简单跨站脚本攻击的正则表示式:
/（（\%3C）|<）（（\%2F）|\/）*[a-z0-9\%]+（（\%3E）|>）/ix
应如下将上述正则表示式添加到新的Snort规则:
alerttcp$EXTERNAL_NETany->$HTTP_SERVERS$HTTP_PORTS（msg:
"NIICross-SiteScriptingattempt";
flow:
to_server,established;pcre:
"/（（\%3C）|<）（（\%2F）|\/）*[a-z0-9\%]+（（\%3
16
E）|>）/i";classtype:
Web-application-attack;sid:
9000;rev:
5;）
跨站脚本攻击的偏执行正则表示式:
/（（\%3C）|<）[^\n]+（（\%3E）|>）/I
这条特征仅仅查找起始的HTML标签及其对等的16进制,之后的一个或多个字符为非换行符,再之后为结尾标签或其对等的16进制。
这可能导致一些误报,具体取决于Web应用和Web服务器的架构。
但这种方式能够确保捕获任何攻击,甚至远程类似的跨站脚本攻击。
对于公众方面,能够加强教育程序,帮助用户防范可用于帐号劫持和其它形式身份窃取的在线欺诈,如网络钓鱼。
对于质量保证============修复跨站脚本漏洞最终要求基于代码的修复。
”对于开发”和”对于安全操作”部分所述步骤可为开发人员提供修复这些问题所需的信息。
以下步骤概括了如何对应用程序手动测试跨站脚本。
步骤1.在浏览器中打开任意Web站点,查找可接受用户输入的位置,如搜索表单或某些登录页面。
在搜索框中输入test并发送给Web服务器。
步骤2.寻找返回类似于Yoursearchfor'test'didnotfindanyitems或Invalidloginte
升级会员 