WEB常见安全问题及解决方案（一）

    由于自己工作阶段主要从事路由器相关开发工作，重点看护模块为web模块。因此后面说的WEB更多的是以网关维护界面的WEB为例。

    WEB的功能最初是只需要实现对应的功能，可以实现配置管理，可是随着网关频繁的被攻击，公司也慢慢开始对web安全重视了起来，于是开始了很长一段时间的整改之路，即使整改过程中会引入了许多功能问题也没有办法阻挡安全整改之路。常见的WEB安全攻击有以下几种。

    1.CSRF跨站请求伪造；2.XSS跨站脚本攻击; 3.越权访问。

    CSRF跨站请求伪造

    CSRF（Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。不过在讨论防御CSRF攻击之前，首先要明确CSRF攻击的对象。CSRF攻击是黑客借助受害者的cookie来验证服务器的信任，但是黑客并不能拿到cookie，也看不到cookie的内容。另外，对于服务器返回的结果，由于浏览器同源（域名、协议、端口）策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他能够做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值。而非窃取服务器中的数据。因此，我们要保护的对象是那些可以直接改变数据改变的服务，而对于读取数据的服务，则不需要进行CSRF防御。比如网关中修改WAN的参数，会改变FLASH中的数据，此时就会遭到CSRF攻击，需要进行CSRF保护。而像查询网关设备信息这样的读取操作，不会改变数据，CSRF攻击无法解析服务器结果，不需要保护。

    因此要抵御CSRF，关键在于在请求中，且基本上是post请求中（前提是开发时get请求只用于获取数据，post用于下发数据），放入黑客所不能伪造的信息，并且该信息不存在于cookie之中。一般网关常见的是在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。另外一种就比较少见，一般是一些运营商的特殊定制，比如加入验证码，这个验证码是服务器端随机生成的，实际数据下发之前必须验证验证码是否正确。

    下面就用一个实例来演示如何进行csrf攻击

    目标站：某家庭网关，维护地址192.168.1.1，通过查看源码发现，网关中所有post操作都存在csrf攻击风险，以简单的配置upnp参数来演示；

    开启burpsuite抓包，点击保存，选择下发upnp参数的post报文，按如下格式生成构造csrf的表单，保存到本地

 

 表单内容如下所示

在网关成功登录的情况下，开一个tab页，本地把该html打开，显示结果如下

    修改upnp的value,如将0修改成1,点击Submit request，会发现数据可配置成功。当时这种方式只是模拟，而且这里只是演示了如何利用csrf漏洞篡改网关的一个数据，如果黑客想攻击，可能构造任何报文，将网关配置的无法上网甚至死机。试想一下，如果是换成漏洞出现在银行之类的网站，黑客构造了一个钓鱼网站，很有可能你账户的钱就在你不知情的情况下就到了黑客的账户当中。

    而加入了token之后，由于token值是随机生成的，用完一次即失效，黑客就无法模拟，因为可以达到防御csrf的目的。

    2.XSS跨站脚本攻击

    跨站脚本（cross site script）为了避免与样式css混淆，所以简称为XSS。

    XSS是一种经常出现在web应用中的计算机安全漏洞，也是web中最主流的攻击方式。那么什么是XSS呢？XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些代码，嵌入到web页面中去。使别的用户访问都会执行相应的嵌入代码。从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。网上对XSS的介绍有许多，会对XSS攻击进行分类，就不再具体介绍，其实仔细分析下，简单总结”在页面渲染过程当中，由于代码未做XSS处理，导致攻击脚本可以执行。早期由于有一些开发人员未搞清楚XSS攻击原理，只是简单的限制输入，不允许特殊字符的配置，这样确实可以解决因用户输入限制不全导致的xss，但是这样也会影响用户的体验，比如有些用户就是想配置一些特殊的字符；并且也并不能完全解决XSS的漏洞，因为网关当中并非所有的数据都是用户输入的，有一些数据可能就只是做一些简单的透传显示在页面上，比如wifi设备名，有一些网关支持挂载U盘，U盘里面的文件名等，都不是由用户配置的，如果黑客通过类似的方式构造攻击，都有可能导致XSS。

    下面就举两个简单的例子来演示XSS攻击的两种情况。

      第1类：通过用户的输入注入脚本

      如某家庭网关可配置以下字符

    配置成功之后然后去可查看ssid名字的界面查看，发现注入脚本可以执行，说明存在xss风险

   第二类:非用户输入注入xss

    由于并非所有的数据来源都是用户输入，还可存在以下方式注入xss脚本。

    比如网关有一个界面有一个功能是显示连接wifi的设备，其中就包括显示wifi设备名称，而这个设备名称并不是通过网关进行配置的，如下图所示

    如果设备名称通过修改为xss脚本<script>alert('xss')</script>，当用户界面这个界面的时候，xss脚本就可以执行，从而导致xss。

    对于这类型攻击一般从两个方面进行防护，第一个是针对输入进行控制；第二个则是在输出端控制，而对输出端控制也是防护xss的根本，输出端控制则是主要是一些特殊字符转义，涉及的特殊字符如下图所示

3.越权访问

    网关经常涉及到二级甚至三级账户，每级账户的配置或者查看参数的权限，一般在开发过程中，如果不注意权限的保护，很容易出现越权的问题，比如客户要求普通用户隐藏某个界面或者隐藏某个界面的参数，只有高级账户才可以访问和配置，可是如果后台未做校验，仅仅只是在界面上做了隐藏或者置灰，并未将限制做到后台，这样就攻击者就可以简单的在浏览器调试窗口修改html属性，或者利用报文拦截工具（如常用的burpsuit）达到普通用户越权修改参数的目的，不过这类问题在国内一些客户其实并没有太注重，可是对于国外一些信息安全比较重视客户，一旦出现，他们就会觉得我们想留后门，引起客户投诉。

    这类问题防范的思路也一般比较固定，就是第一次安全整改的时候比较麻烦，非常容易遗漏，需要将所有用户可以访问的界面以及接口进行梳理，哪些接口登录前可以访问（配置），哪些接口登录后才可以访问（配置），哪里是只有普通用户才可以访问的界面和接口，整理好之后在后台严格控制对每个权限和接口进行控制，尤其注意这个权限的控制需要控制在后台，前端所做的权限控制可能只是用户体验上的改变，实际通过工具很容易可以饶过限制。此外，由于涉及的测试点比较多，比较容易遗漏，整改过程当中接口的整理以及自验证就需要非常的认真。然后根据整理出来的权限列表在底层根据用户级别进行权限控制，比如普通用户可以访问哪些restful接口、管理员可以访问哪个restful接口，路由器当中主要是通过C代码在web后台当中控制，需要明白一点原则：一切在前台的的校验都不是安全的，前台的校验一般只是用于提高用户体验。