将博CMS安全分析报告-橘皮书
一、使用IBM的AppScan和Acunetix应用程序漏洞扫描将博CMS5.5，得出一些漏洞。
此番扫描大小共23种类型问题，其中高危漏洞有三个，中危漏洞9个，低级漏洞11个。注意这些漏洞级别很有可能根据具体项目不同而会变得不同。总的来说这两个工具扫描出的漏洞差别还是蛮大的，有些同类型的漏洞命名也不一样，甚至他有而它无的情况。所以综合这两款工具一起扫描变的十分重要。
虽然漏洞比较多，但高危漏洞基本也是常见的几个Web应用程序漏洞，如：XSS、明文传输、CSRF等。下面我们就具体分析一下这些漏洞产生的原因和解决方法。
1、 已解密的登录请求（高）。/admin/login.aspx
将博后台原始登录页使用flash制作，在登录中，其将密码在客户端进行了md5加密后再发送到服务端，看似做到了中途以明文方式传输带来被窃听的风险，而实际上无异于“掩耳盗铃”罢了！虽然使用了md5加密，但自2005年后md5已经变得很不安全了，普通微机得到散列码后，无需花费太多时间就可以解密，现在该加密算法，一般用于数据校验。即便我们可以使用更强的加密算法，如：SHA系列，虽然这样大大提高了解密难度，但任然防止不了被动攻击（窃听），人家无需解密散列码，照样可以以管理员身份登录。因为将博后台身份验证登录只是比较一下客户端散列码和数据库中散列码是否一致而已。要彻底防止被动攻击，需要使用SSL协议传输，它使用安全的证书对话，具有抗抵赖、抗窃听、抗篡改、抗泄密的特性。
关于这个漏洞的级别也是有争议的，其视具体情况而定，如果是一个一般性的企业或个人网站，一般都不会使用SSl通信，因为SSL协议证书需要花钱的。而像支付宝、银行等行业，安全性就很高了。是需要强制使用证书的。
下图表明将博使用MD5在客户端将密码加密传输。
2、跨站点脚本编制（高）。/admin/login.aspx
这个就是有名的XSS漏洞了，他分为反射型、保存型以及基于DOM的XSS攻击三种类型。
将博在检测到有潜在危险请求输入时，将原始请求中的危险字符串原原本本的返回给客户端，而中间却没有任何净化措施，这样会易受“反射型跨站点脚本攻击”。但现在很多浏览器都有防范这类攻击的措施，除非用户关闭的浏览器的这个功能。建议对这段代码实施JS脚本字符串净化后输出。
千万别小看这个漏洞，一旦用户不小心允许了浏览器执行它，那攻击者就可以通过专门设计的以盗取盗取当前用户会话Cookie为目的的JS代码，它可以获取当前用户会话的Cookie，从而可以实施“会话劫持攻击”。会话劫持攻击可以在攻击者完全不知道用户名和密码的情况下像当前被劫持的管理员一样操作系统。
下图表明将博直接将博客户端错误请求的字符串原原本本的返回给客户端。
3、Unicode transformation issues（高）
这个问题，是说针对某些Unicode解码器有将长格式转化为段格式的特点，通过特殊设计的小于号Unicode长型式编码在向Web发动Get请求时，可以绕过普通的过滤检测系统（对于'<>'这类JS代码符号），从而仍然可以达到XSS攻击目的。
我自己亲自测试了一下，貌似特殊设计的字符，传输到服务端后，并没有转化成'<>'类似的脚本特殊符号，但也确实发现这些特殊设计的字符，转化成了另外的字符形式，这说明系统中任然可能会存在字符串编码解码带来的漏洞。
因为还不清楚具体哪些会导致这样的错误转码，所以也没法提供一套特殊字符过滤器。
4、客户端（JavaScript）Cookie 引用（中）
将博大量使用Cookie保存一些身份验证信息，经查看，虽然将博将用户名保存到了Cookie中，但其密码却没有保存在其中。
之所以扫描工具会认为这里有漏洞，是因为，其认为这样做可能让攻击者利用XSS漏洞从而实施会话劫持攻击，而实际上这里不会。
作为Cookie来跟踪用户会话，不应该将任何敏感信息（用户名、密码）放入其中，无论你是否加密。
下图表明将博Js脚本本件中存在大量对于Cookie的访问。
5、链接注入（便于跨站请求伪造）（中）
这个漏洞和上面的“跨站点脚本编制”出现之原因是一样的，皆因服务端对错误请求“反射”造成之。欲彻底杜绝此类攻击，需要对反射回来之Html标签特殊字符进行过滤或转码。
若攻击者一旦链接注入成功，则可造成OSRF或CSRF攻击，某种情况之下，攻击者可创建特殊帐号或修改商品价格。
下图表明可以在将博系统中实施OSRF或CSRF攻击。
6、通过框架钓鱼（中）
这个漏洞与请求伪造攻击一样，都是利用程序未对输入之Html特殊字符串做净化处理，然后将博对错误请求做了反射型处理时也没有做输出净化造成之。这个问题很严重，他可能会诱惑你泄露帐号密码。
攻击者通过在请求中嵌入一个<ifram>标签引用自一个伪造的站点登录界面，诱使用户误以为已经登出系统，从而合法用户将被骗取重新输入用户名和密码。
7、Microsoft IIS tilde directory enumeration （中）
这是一个IIS漏洞，可以通过Get的请求使用波浪符“~”来 猜解网站的目录结构和文件，如果目录文件名称都比较短的话，通过枚举法，可以猜解。这个问题不算严重，注意不要将敏感文件直接暴露在项目中文件夹中，最好确认查看的权限。
8、 Application error message （中）
此问题意曰，将博应用程序未做异常处理，出现错误后，直接报黄页，并带有调试的堆栈信息，从而也就泄露了应用程序的某些代码信息。建议对应用程序做异常处理并给出友好页面提示。
9、ASP.NET error message （中）
此为应用程序未定义错误页面，则系统遇到错误之时报黄页，泄漏应用程序某些信息。建议配置应用程序错误页面。
10、会话标识未更新（中）。
此报告完全谓之“扯蛋”，AppScan他认为登陆前和登陆后如果Cookie中ASP.NET_SessionId没有变化，其即认为有此危险。其实这是没有什么太了不起的事情，我们知道访问ASP.net程序，默认给每个浏览者分配一个ASP.NET_SessionId（会话标识），以便可以准确跟踪该用户的数据，而如果我们系统使用了Membership权限框架的话，登陆后Cookie中会多了一个“权限标识”（.ASPXROLES），和会话标识类似的，但他是用于表明一个登录的用户身份。虽然将博没有使用Membership框架，但将博一样在Cookie中写下了类似的权限标识“jcmsV6.6.0.0601admin”来表示一个已登录的用户。所以不管何种情况，ASP.NET_SessionId都是不会变化的。
11、跨站点请求伪造 （中）。
他这里说登录会有这种危险，我也不太明白危险在哪里？一般说来，重要操作需要防范CSRF攻击，显然将博中创建用户中页面没有使用令牌，而只是单纯的依靠Cookie中身份标识来确定请求的合法性，致使站点易受CSRF攻击。
虽然我们可以对于用户的请求做Html特殊检测，从而防范CSRF，事实上是可以防范，但这是第一道防线，而在重要操作页面中使用令牌机制，则为第二道防线。这个叫做“深度防御”或“分层多点防御”。
12、Autocomplete HTML Attribute Not Disabled for Password Field
（低）
这个的意思是密码输入框没有禁用记住密码功能，一般来说，密码属于敏感信息，最好不要让浏览器记住。将密码框的 Autocomplete 属性设置为关闭状态即可。
13、已解密的 __VIEWSTATE 参数（低）
一般来说，这个隐藏字段保存的都是一些表单的信息，不加密也造成不了什么 危险，即便加密，也只是这个隐藏域的值加密了，但页面中的数据表单并没有加密。如果确实想在整个传输过程中加密，请使用SSl协议。
14、无签名的 __VIEWSTATE 参数 （低）
一般来说，这个隐藏字段保存的都是一些表单的信息，不加密也造成不了什么 危险。这里所谓的签名，也就是“数字签名”，但这种安全措施，一般在SSl协议通信中才能使用，数字签名涉及到公钥证书那一套去了。如果确实想在整个传输过程中加密、签名，请使用SSl协议。
15、发现可能的服务器路径泄露模式
（低）
报告建议是安装服务器软件的最新补丁，实际上是将博返回错误信息时将堆栈信息返回给客户端，其中包含了服务器上文件的绝对路径造成的。只需灭掉这个堆栈信息返回即可。
下图表明将博向客户端返回错误的堆栈信息。
16、检测到隐藏目录（低）
对于普通用户无权访问的资源，无论其是否存在，都应该返回404错误码，这样攻击者也就难以探测到应用的目录结构，从而降低攻击风险。以往的做法是将无权访问的页面跳转到登录页或给出提示信息，这样的不好之处就是攻击者使用扫描工具可以根据服务端响应信息，得知该文件或目录是否存在。如果无权访问都返回404错误，则攻击者将无法确认服务端是否存在该目录。
17、Login page password-guessing attack（低）
这个就是所谓的“蛮力密码攻击”，由于将博后台登录系统并没有验证码之类的防范措施，所以有可能激发攻击者的蛮力破解欲望。建议使用验证码功能，从而增强攻击难度。
虽然将博使用了一种所谓的防范频繁登录机制（“请想想密码再来”），这其实又上演出了一场“掩耳盗铃”的把戏罢了！将博在前端使用JS来记忆用户登录错误的次数，当尝试次数大于4次时，将向用户显示“请想想密码再来”，他以为这样能防止攻击者的蛮力破解，真是一个天真的娃！黑客才不会笨到如此地步呢，他们肯定是绕过所有的JS验证区直接向服务器发送N多请求的，所以将博这个办法是形同虚设！除非他能在服务端来验证这个登录的次数才可能是个有效的办法。
下图表明将博使用前端JS防范蛮力攻击。
18、OPTIONS method is enabled（低）
这个问题是说，我们经常使用Get或Post的Http请求方法，但同时应该禁止其他的方法，如：
PUT、
DELETE、
TRACE、
OPTIONS、
CONNECT。因为这些方法，被攻击者利用后，会泄漏服务器的某些信息。此漏洞修复方法，可以为IIS安装URLSCAN工具。
19、 Password field submitted using GET method （低）
这个问题是说，将博之普通用户登录使用的Get请求方式，不安全，因为Get请求会暴露在请求的Referer头中，从而可能泄漏密码。将博确实使用的是Ajax的Get请求，因为其本身处理并没有在一个页面中，从来也就不可能恶意的被第三方劫持到这个带有用户名和密码的原始链接地址。
下图表明Referer字段会泄密一些信息。
20、Session Cookie without Secure flag set（低）
这个问题的意思是，应用程序在写Cookie时，没有使用“secure”标记Cookie，因为这样浏览器提交Cookie时总是使用明文，而设置了这个标记，浏览器就总是使用Https方式提交，但这个设置的前提是我们的网站使用了SSl协议对话。
二、自发现安全问题
1、点击劫持攻击（高）
这个也叫UI伪装攻击，原理是将目标系统重要操作页面，如：登录、转账、创建新用户等通过<iframe>框架签入到了攻击者的网站里面，而攻击者的界面使用全透明方式显示，从而诱使用户填写表单盗取用户重要信息，因为用户误以为自己还在目标系统中。还有一种是将目标页面完全透明显示，而攻击者网站使用很具有诱惑的信息诱使用户点击鼠标确认，而实际上用户点击的是自己目标系统的某个重要操作，如：确认转账按钮，这种攻击实在是恶毒。
将博对于点击劫持攻击具有一定的防范措施，它采用常见的”破坏框架“技术防御，以便防止登录页面被嵌入某个第三方的网站页面中。但我不得不说，这个防御技术早已经过时了，因为攻击者具备反”破坏框架“技术了。所以这种防范措施几乎没什么用，而自IE8引入HTTp响应头字段：X-Frame-Options，许多其他浏览器也开始纷纷支持此字段，因为这个才能彻底防御这种攻击，但这也是一新的标准，说白了也就是原来的Http协议不足造成的。这个字段可以告知浏览器该页面是否可以被其他页面嵌入，这也就从根本上解决了这个难题。但不好的消息是，IE8以下版本浏览器不支持这个特性，所以任然可以遭受这种攻击。
下图表明将博使用了”破坏框架“防御技术。
2、富文本编辑器中XSS攻击（高）
经过我亲自测试,将博的富文本编辑器存在保存型XSS漏洞，如下图所示，我已经成功注入了JS脚本代码于正文之中。因为其采用了.net3.5架构，，系统默认启用了危险字符输入检测系统，将博许多表单中如果输入危险的字符，.net危险检测系统可以拦截集合所有的潜在危险输入。但其富文本输入区却比较例外，允许用户输入危险的字符串，如：JS脚本标记、Html。虽然正常输入可能都被编辑器自动进行HTML编码了，但在查看源代码试图下，任然可以嵌入脚本。当然黑客可以完全绕过页面的所有客户端验证直接请求发表文章。
这说明将博没有处理好富文本编辑器里面的内容，这样就会很容易导致跨站点脚本攻击和本地或跨站点请求伪造攻击。黑客只需发表一篇经过特殊设计的JS代码或链接注入代码，其采用“守株待兔”的方式坐等其它访问该文章的已登录用户，就可以轻松的劫持其会话等等。
此类问题的修复，就应该在服务端对JS特殊脚本字符串进行过滤检测，为了防范请求伪造之”链接注入“，要特别的确认路径有效性和合法性，尤其是图片链接地址。
下图表明将博富文本编辑器存在XSS漏洞。
3、数据库链接字符串加密（中）。
数据库链接字符串写在web.config配置文件中存在一定的安全隐患，虽然外部人员难以查看 到里面的信息，但出入服务器机房的管理员却容易看到。目前微软提供一些较好的加密算法可以对这些敏感信息配置节点加密，使管理员看不到明文的信息。但可悲的是，只要管理员了解asp.net配置节点加密方法，他也可以对其进行解密，因为他有管理员权限，而密钥又必须在服务器系统中。
4、将博验证码，形同虚设。(5.5版本，6.6版本已经解决）。（中）
在之前的老版本5.5中发现这一漏洞，将博普通用户登录页虽然有验证码用来防止“蛮力攻击”，但其在验证验证码的时候，真可谓是“掩耳盗铃”！将博将服务端生成的验证码“偷偷”的发送到客户端Cookie中，然后又在服务端将其取出来比较。哈哈，不知是哪个傻B的思路，这不是多此一举吗？
3、表单字符串类型，后台未做净化过滤措施。
三、总结
首先，对于这些所谓的Web应用漏洞扫描工具。应该怀着一种辩证的观点看待之，独立漏洞扫描工具目前大约能发现常见漏洞的一半样子，因为其本身的技术局限性，有些漏洞是其无法突破的痛楚，因为他只是按照程序的规则做事情，没有人类的大脑智慧。目前据了解，这类产品的厂商也在努力改进之中。据有关数据显示，在同类产品中Acunetix评分最高，而IBM的AppScan却屈居第五位。甚至还出现某些售价数千美元的还不如一个免费的。所以公司在选择相关产品时一定要谨慎选择。
其次，我们Web安全范围比较广，各类安全问题比较多，计划跟不上变化，安全措施也面临着巨大挑战。总的来说，为了防范XSS、CSRF、SQL注入等常见漏洞，我们应该养成对应用程序各种途径输入的字符串做过滤检查，又么拒绝、又么净化之。其他之安全问题，我们应该根据需要来加以防范，而不是一味企图策划一个“完美的、牢不可破”的安全方案。
另外，此次扫描可能是工未能配置好，貌似没有登录到系统后台进行扫描，原因是我对这个工具不太熟悉。总之也发现了不少问题，也肯定还存在不少问题！