一、使用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特殊字符串做净化处理，然后将博对错误请求做了反射型处理时也没有做输出净化造成之。这个问题很严重，他可能会诱惑你泄露帐号密码。
攻击者通过在请求中嵌入一个标签引用自一个伪造的站点登录界面，诱使用户误以为已经登出系统，从而合法用户将被骗取重新输入用户名和密码。
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伪装攻击，原理是将目标系统重要操作页面，如：登录、转账、创建新用户等通过