m_sy530
m_sy530

【前端安全】常见安全性问题及解决方案

常见安全性问题

    • 一.XSS 跨站脚本攻击
        • XSS分类
    • 二、CSRF 跨站请求伪造
        • 例子
        • 解决方案
    • 三、SQL注入攻击
        • 特点
        • 注入过程
        • 防范措施
    • 四、OS命令注入攻击
        • 防范措施
    • 五、点击劫持
        • 防范措施
    • 六、HTTP请求劫持
        • 防范措施
    • 七、DDOS攻击
        • 原理
        • 防范措施
    • 总结

一.XSS 跨站脚本攻击

  XSS攻击（Cross Site Scripting）是Web应用程序中最常见的漏洞攻击之一，通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、VBScript、ActiveX、Flash或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（比如执行一些操作）、私密网页内容、会话和cookie等各种内容。所以xss漏洞关键就是寻找参数未过滤的输出函数。
  常见的输出函数有： echo printf print print_r sprintf die var-dump var_export。

XSS分类
  1. 非持久型跨站
      反射型跨站脚本漏洞，最普遍的类型。用户访问服务器——跨站链接——返回跨站代码，一般容易出现在搜索页面。
      ①不要信任用户的输入。对用户输入的数据进行过滤，例如禁止输入( )英文圆括号、< >尖括号等。但是此方法只是在web端进行了初步过滤，攻击者可能通过工具绕过前端的输入限制，因此还需后台服务器在接收到数据后，对特殊危险字符进行过滤或者转义，再存储到数据库。
      ②输出过滤。在PHP中，有htmlentities( )函数和htmlspecialchars( )函数对服务端输出到浏览器的数据进行编码或转义来防范XSS攻击。相应的JavaScript的编码可以使用JavaScriptEnode。
      ③安全编码。尽量使用innerText（IE）和textContent（Firefox），也就是jQuery的text( )来输出文本内容，尽量避免Web客户端文档重写、重定向或其它敏感操作。
      ④HttpOnly Cookie。在设置cookie时，加上HttpOnly参数，就可以避免该网页被XSS攻击时，cookie信息被盗取（可兼容至IE6）；缺点是，作用有限，只能保证cookie的安全。
  2. 持久型跨站
      跨站代码存储在服务器（数据库），最直接的危害类型，容易造成蠕虫，大量窃取cookie。如在个人信息或发表文章等地方。
1.攻击者发送恶意脚本请求
2.恶意脚本被保存到数据库中
3.用户正常浏览页面
4.从数据库读取
恶意脚本
5.将恶意脚本返回用户
构造页面
6.浏览器解析
执行恶意脚本
发起攻击
攻击者
PC
数据库
用户

  存储型XSS对用户输入进行过滤的方式和反射型XSS相同。

  • htmlspecialchars( )和htmlentities( )的区别：
      htmlspecialchars只转义 & 、" 、' 、< 、> 这几个html代码；
      而htmlentities却会转化所有的html代码，连同里面的它无法识别的中文字符也会转化。
  1. DOM跨站（DOM XSS）
      基于文档对象模型的一种漏洞，指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置，而使得攻击脚本被执行。因为DOM中有很多对象，其中一些是用户可以操纵的，如URL、location、referer等。
      过滤函数。vaildURL、HtmlEncode、HtmlAttributeEncode等函数方法。

二、CSRF 跨站请求伪造

  CSRF攻击（Cross-site request forgery）是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。与XSS相比， XSS利用的是用户对指定网站的信任，而 CSRF 利用的是网站对用户网页浏览器的信任。

1.登录某银行网站且没有退出
4.将伪造的转账请求连同
身份认证信息发送到银行网站
2.将伪造的转账请求包含在帖子中
3.银行网站保持登录的情况下去浏览帖子
银行网站看到身份认证信息
认为是小明的合法操作
浏览器中包含着小明在
银行的身份认证信息
小明
xxxbank.com
攻击者
tieba.com
例子

  假如一家银行用以运行转账操作的URL地址如下：http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
  那么，一个恶意攻击者可以在另一个网站上放置如下代码：
  如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。
  这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛、博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。
  通过这个例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义运行操作。

解决方案
  1. 添加验证码
      在一些敏感操作的页面（如账户交易），增加验证流程（比如指纹、密码、短信验证码等），强制用户输入验证码，才能完成最终请求。这种方案在一般情况下可以很好地遏制CSRF攻击，但是验证流程会大大地降低用户体验，网站不可能给每一步操作都加上验证流程，所以这只能作为一种辅助手段，在一些关键操作点设置。
  2. 尽量使用POST，限制GET
      但是POST并不是万无一失，攻击者可以通过如构造form表单的形式进行攻击，不过会增加暴露的可能性。
  3. 检查Referer字段
      HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。
      这种方法简单易操作，工作量低，但是有一定的局限性，因为其完全依赖浏览器发送正确的Referer字段，虽然HTTP协议对此字段的内容有明确的规定，但无法保证浏览器没有安全漏洞影响到此字段。
  4. token请求验证
      发送请求时在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会校验该请求当中的token和cookie中的token值是否都存在且相等，才认为这是合法的请求；否则认为这次请求是违法的，拒绝该次服务。这种方法要比Referer检查安全很多。

三、SQL注入攻击

  SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

特点
特点 概述
广泛性

任何一个基于SQL语言的数据库都可能被攻击，很多开发人员在编写Web应用程序时未对从输入参数、 Web表单、 cookie等接受到的值进行规范性验证和检测，通常会出现SQL注入漏洞。
隐蔽性

SQL注入语句一般都嵌入在普通的HTTP请求中，很难与正常语句区分开，所以当前许多防火墙都无法识别予以警告，而且SQL注入变种极多，攻击者可以调整攻击的参数，所以使用传统的方法防御SQL注入效果非常不理想。
危害大

攻击者通过SQL注入获取到服务器的库名、表名、字段名，从而获取到整个服务器中的数据，对网站用户的数据安全有极大的威胁。攻击者也可以通过获取到的数据，得到后台管理员的密码，然后对网页页面进行恶意篡改。这样不仅对数据库信息安全造成严重威胁，对整个数据库系统安全也影响重大。
操作方便

互联网上有很多SQL注入工具，简单易学，攻击过程简单，不需要专业知识也能自如运用。
注入过程
  1. SQL注入点探测
      探测SQL注入点是关键的一步，通过适当的分析应用程序，可以判断什么地方存在SQL注入点。通常只要带有输入提交的动态网页，并且动态网页访问数据库，就可能存在SQL注入漏洞。如果程序员信息安全意识不强，采用动态构造SQL语句访问数据库，并且对用户的输入未进行有效性验证，则存在SQL注入漏洞的可能性很大。一般通过页面的报错信息来确定是否存在SQL注入漏洞。
  1. 收集后台数据库信息
      不同数据库的注入方法、函数都不尽相同，因此在注入之前，我们先要判断一下数据库的类型。判断数据库类型的方法很多，可以输入特殊字符，如单引号，让程序返回错误信息，我们根据错误信息提示进行判断；还可以使用特定函数来判断，比如输入“1 and version( )>0”，程序返回正常，说明version( )函数被数据库识别并执行，而version( )函数是MySQL特有的函数，因此可以推断后台数据库为MySQL。
  1. 猜解用户名和密码
      数据库中的表和字段命名一般都是有规律的。通过构造特殊SQL语句在数据库中依次猜解出表名、字段名、字段数、用户名和密码。
  1. 查找Web后台管理入口
      WEB后台管理通常不对普通用户开放，要找到后台管理的登录网址，可以利用Web目录扫描工具（如：wwwscan、AWVS）快速搜索到可能的登录地址，然后逐一尝试，便可以找到后台管理平台的登录网址。
  1. 入侵和破坏
      一般后台管理具有较高权限和较多的功能，使用前面已破译的用户名、密码成功登录后台管理平台后，就可以任意进行破坏，比如上传木马、篡改网页、修改和窃取信息等，还可以进一步提权，入侵Web服务器和数据库服务器。
防范措施
  1. 分级管理
      对用户进行分级管理，严格控制用户的权限，对于普通用户，禁止给予数据库建立、删除、修改等相关权限，只有系统管理员才具有增、删、改、查的权限。
  1. 参数传值
      程序员在书写SQL语言时，禁止将变量直接写入到SQL语句，必须通过设置相应的参数来传递相关的变量，从而抑制SQL注入。数据输入不能直接嵌入到查询语句中，同时要过滤输入的内容，过滤掉不安全的输入数据（如' '单引号、" "双引号、:冒号等字符），或者采用参数传值的方式传递输入变量。这样可以最大程度防范SQL注入攻击。
  1. 漏洞扫描
      系统管理员可以通过采购一些专门系统的SQL漏洞扫描工具，通过专业的扫描工具，可以及时的扫描到系统存在的相应漏洞。漏洞扫描工具只能扫描到SQL注入漏洞，不能防范SQL注入攻击。
  1. 多层验证
      增加黑名单或者白名单验证。黑名单指：若用户在输入中，包含明显的恶意内容则拒绝该用户的请求；而白名单指：检查用户输入是否符合预期的类型、长度、数值范围或其它格式标准。在使用白名单验证时，一般会配合黑名单验证。
  2. 数据库信息加密
      传统的加解密的方法大致可以分为三种：
类型 解析
对称加密

即加密方和解密方都使用相同的加密算法和密钥，这种方案的密钥的保存非常关键，因为算法是公开的，而密钥是保密的，一旦密匙泄露，黑客仍然可以轻易解密。常见的对称加密算法有：AES、DES等。
非对称加密

即使用不同的密钥来进行加解密，密钥被分为公钥和私钥，用私钥加密的数据必须使用公钥来解密，同样用公钥加密的数据必须用对应的私钥来解密，常见的非对称加密算法有：RSA等。
不可逆加密

利用哈希算法使数据加密之后无法解密回原数据，这样的哈希算法常用的有：md5、SHA-1等。

四、OS命令注入攻击

  OS命令注入（OS Command Injection）类似于上述的SQL注入，区别于应用场景不同。OS 注入攻击是指程序提供了直接执行Shell命令的函数的场景，比如在构造OS命令时使用了外部输入的数据，如果没有对外部输入中可能影响OS命令的特殊元素进行过滤，或是过滤不充分，就有受到OS命令注入攻击的风险。
  OS命令注入漏洞的形成需要同时满足以下三个条件：

  1. 使用了内部调用Shell的函数（system、open等）
  2. 将倍加传入的参数传递给内部调用的shell的函数
  3. 参数中shell的元字符（如*、？、[]、\等）没有被转义
防范措施
  1. 白名单校验
      对用户输入的参数进行过滤校验。当然黑名单也不是不可以，只是需要考虑的情况比较多，相比之下还是白名单简单高效。当然，如果可以的话，最好不要允许用户输入参数。
  2. 使用 execFile / spawn
      在 Node.js 中除了 exec()之外，还有 execFile() 和 spawn() 两个方法也可以用来执行系统命令。它们和 exec() 的区别是后者是直接将一个命令字符串传给 /bin/sh 执行，而前者是提供了一个数组作为参数容器，最后参数会被直接传到 C 的命令执行方法 execve() 中，不容易执行额外的参数。
      不过这个方法也不是绝对安全，因为这个只是利用了执行的命令只接收普通参数来做的过滤，但某些命令（如/bin/find）提供了-exec参数，后续的参数传入后会被其当成命令执行。

五、点击劫持

  点击劫持（click jacking），也被称为UI-覆盖攻击，顾名思义，和点击事件有关，利用用户的点击操作，来完成非用户本意的操作。
  这种攻击利用了HTML中