论坛首页 Web前端技术论坛

javascript入侵业务安全浅谈

浏览 10337 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2007-11-11  

        大家好,等会我说的大家可能都已经遇到过了,也或许没有遇到过,再或许没有从这方面考虑过.接下来我们通过一个小例子来说明一下。

        我们在每个项目中,几乎都会用到[checkbox]组件。比如批量删除,批量审核等等...,举个简单的例子,如下图:

       

        这是一个简单的批量删除演示,大家可以看到其中"李四"和"刘六"二人是禁止删除的,因为其对应的checkbox组件是禁用的。此我们稍微考虑一下,我们能否在浏览器端将李四对应的checkbox修改成可用。如果能那显然就破坏了正常的业务逻辑和系统的安全性,当然有人会说我会在后台验证,对没错!但我们今天只是拿来讨论一下前台的东西*^_^*

        大家肯定都晓得可用在地址栏直接运行js代码,不过大家有想过通过在地址栏运行的js代码来改变页面中某些组件的状态或者value吗?

        我们先看一下对应上面那个批量删除的HTML代码:

xml 代码
           
  1. href="#">添加a>      <a href="#">删除a>  
  2. <hr size="1" width="100%">  
  3. <input id="isDel" type="checkbox" value="张三">  张三   男  石家庄  本科<br>  
  4. <input id="isDel" type="checkbox" value="李四" disabled="disabled">  李四  女  太原市  专科<br>  
  5. <input id="isDel" type="checkbox" value="王五">  王五  女   北京市    硕士<br>  
  6. <input id="isDel" type="checkbox" value="刘六" disabled="disabled">  刘六  男  石家庄  博士<br>  

         我们可用看到checkbox的id为[isDel],此时我便可用通过id在地址栏得到该对象。比如我们使用document.all.isDel来得到的是一个数组,包含了上面四个checkbox,同样我们也可以得到具体的某个checkbox。比如document.all.isDel[1],用这句代码来得到对应李四的checkbox,因为数组下标是从零开始的。如图:

       

         我们在得到该对象之后想再修改其状态或修改它的value就易如反掌,我们只需运行alert(document.all.isDel[1].disabled="") ;就可用将李四的禁止删除状态改为可用删除状态,如图:

        

        这样看来李四就可用删除了,当然,前提是你后台的验证不是很完善的情况下,所以这也对我们的后台验证提出了更高的要求。这里说明一下在地址栏运行javascript的时候一定使用alert语句,呵呵,如果不使用的话可用自己试一下效果。

       写这篇短文也没有别的意思,就是想和大家讨论交流一下类似的问题,像这种情况举一反三可用落实到很多具体的场景,也不仅仅局限于checkbox这种组件。如果有业内的大牛对这方面有研究那就和我们分享一下吧。

       谢谢您耐心看完此文。

   发表时间:2007-11-11  
web根本就没什么安全,地址栏写js太菜鸟了,firebug或者append一个textarea再eval那更加方便,简单来说,任何一个get或者post请求都是不可信,都是可以伪造的
0 请登录后投票
   发表时间:2007-11-11  
是啊,改HTML,JS完全都可行。多年前我用的方法是下载网页,直接修改内容,再打开执行(可能需要修改一些URL链接,因为原来可能用的是相对路径)。
0 请登录后投票
   发表时间:2007-11-11  
afcn0 写道
web根本就没什么安全,地址栏写js太菜鸟了,firebug或者append一个textarea再eval那更加方便,简单来说,任何一个get或者post请求都是不可信,都是可以伪造的


呵呵,地址栏写js也不是为了调试:) 只是为了说明问题,firebug着实好用。
0 请登录后投票
   发表时间:2007-11-11  
楼主这个web安全讨论如果扩大一点,可以讨论
1.web基于cookie认证是否在级线器或者共享上网或者wifi当中带来重大问题,是否需要加入密钥验证
2.目前web开发有依赖js的趋势,导致bs不分,导致安全隐患大幅度增加,是否应该改变开发模式成为b系统和s系统,如果s系统能够保证为安全,那b系统至少不会加入s系统不存在的安全问题,当然和b平台相关问题不是s系统可以预见的
3.web到底适合不适合一些需要极度安全的场景,web这种匿名,无状态,发cookie,基于无连接的post get请求是否符合安全系统的要求
只是个人看法,当然还没包括各种js解释器是否存在安全隐患,溢出activex各种问题了,以及是否浏览器应该加大对于html js的保护力度呢
0 请登录后投票
   发表时间:2007-11-12  
afcn0 写道
web根本就没什么安全,地址栏写js太菜鸟了,firebug或者append一个textarea再eval那更加方便,简单来说,任何一个get或者post请求都是不可信,都是可以伪造的


说到根子上了!

所以整天讨论 js安不安全啊,ajax安不安全啊,逻辑放在前端安不安全啊...这些根本没有意义!

B/S安不安全,不在于你的防范措施有多强,而在于想高破坏的人的水平有多高!
0 请登录后投票
   发表时间:2007-11-12  
增强后台验证机制,UI不管怎么说也不过是给人看得
0 请登录后投票
   发表时间:2007-11-12  
呵呵,还是有人提出来了,自己也想过此问题,限于水平也没想出个道道儿……
搬凳子等达人给说道说道……
0 请登录后投票
   发表时间:2007-11-12  
afcn0 写道
楼主这个web安全讨论如果扩大一点,可以讨论
1.web基于cookie认证是否在级线器或者共享上网或者wifi当中带来重大问题,是否需要加入密钥验证
2.目前web开发有依赖js的趋势,导致bs不分,导致安全隐患大幅度增加,是否应该改变开发模式成为b系统和s系统,如果s系统能够保证为安全,那b系统至少不会加入s系统不存在的安全问题,当然和b平台相关问题不是s系统可以预见的
3.web到底适合不适合一些需要极度安全的场景,web这种匿名,无状态,发cookie,基于无连接的post get请求是否符合安全系统的要求
只是个人看法,当然还没包括各种js解释器是否存在安全隐患,溢出activex各种问题了,以及是否浏览器应该加大对于html js的保护力度呢


afcn0分析的更加深入一些,关于b/s系统的见解也和fins的差不多,就是只有b系统和s系统。
见:世上没有B/S系统,只有B系统和S系统
我们现在面临的问题都是这样,随着客户体验要求的提高,和整个行业的发展趋势,js在开发过程中扮演着越来越多的角色,但这也带来了不少的问题,所以我们必须选择一个合适的折中点。
0 请登录后投票
   发表时间:2007-11-12  
既然从页面过来的数据都是可以伪造的,那么页面上的验证还有没有必要,个人认为根据情况重要数据操作在后台+前台验证,无关紧要的操作,就不要再后台加了,如果每个操作都要验证,无疑增加了后台代码量,每多一行代码,就多一分BUG存在的可能性
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics