javascript入侵业务安全浅谈

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

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

       

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

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

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

xml 代码

a href="#">添加a>      <a href="#">删除a>
<hr size="1" width="100%">
<input id="isDel" type="checkbox" value="张三">  张三   男  石家庄  本科<br>
<input id="isDel" type="checkbox" value="李四" disabled="disabled">  李四  女  太原市  专科<br>
<input id="isDel" type="checkbox" value="王五">  王五  女   北京市    硕士<br>
<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这种组件。如果有业内的大牛对这方面有研究那就和我们分享一下吧。

       谢谢您耐心看完此文。

评论

20 楼 afcn0 2007-11-18  

这个东西也不能太认真,毕竟很多东西不是需要那么安全的,各位又不是搞007那工作的,js验证本来不错,服务器信赖客户端在客户端足够健壮安全情况下也不是不可以,当然就是服务器验证很好,但是就能说安全了吗,远远不够,这个web基本就没有完全安全的东西,想要安全,基本是个非常困难的东西,大概只有007可以实现吧

19 楼 ctfzh 2007-11-18  

up2vs 写道

前端非异步请求的JS验证，仅仅是为了第一时间告诉用户一些操作上的失误信息。如果完全放手到客户端脚本。而服务器端不错任何安全认证措施。我想这个系统不能称作是一个完善的系统。

非常认同up2vs的观点.支持

18 楼 up2vs 2007-11-17  

spiritfrog 写道

可以根据项目需求而定，如果安全要求较高，就在js前端和s系统都作验证，一般情况下只要js验证就够了，ajax验证也是个不错的方式，但也不宜滥用。

前端非异步请求的JS验证，仅仅是为了第一时间告诉用户一些操作上的失误信息。如果完全放手到客户端脚本。而服务器端不错任何安全认证措施。我想这个系统不能称作是一个完善的系统。

17 楼 spiritfrog 2007-11-17  

可以根据项目需求而定，如果安全要求较高，就在js前端和s系统都作验证，一般情况下只要js验证就够了，ajax验证也是个不错的方式，但也不宜滥用。

16 楼 fyting 2007-11-14  

标题党,鉴定完毕

15 楼 afcn0 2007-11-14  

但是目前也不能完全这么说,javascript的角色已经有点变化了,Ajax里面js可不是验证这么简单,已经变成客户端可以信赖的逻辑程序语言,拥有大量类库,所以很多人过度信赖js也是有原因的,但是验证说到底还是s系统的问题,只不过现在很多时候这个问题比较模糊,在大量复杂js操作下不容易发觉

14 楼 wsx860529 2007-11-14  

afcn0 写道

后台验证是最基本的.基本可以说任何web请求都是不可信的,任何get post都是可以伪造的,所以s系统一定要是一个验证非常严谨的系统,而UI只不过是为了使用户更加快速知道自己输入的信息有误一种方法,不用等待一次一次提交后再修改数据的麻烦了,这才是b系统和s系统

正解，javascript是为了达到前台更加人性化的手段，后台验证才是基本。

13 楼 afcn0 2007-11-13  

后台验证是最基本的.基本可以说任何web请求都是不可信的,任何get post都是可以伪造的,所以s系统一定要是一个验证非常严谨的系统,而UI只不过是为了使用户更加快速知道自己输入的信息有误一种方法,不用等待一次一次提交后再修改数据的麻烦了,这才是b系统和s系统

12 楼 laiseeme 2007-11-13  

总不能前台验证一次，后台验证一次，这个是js的硬伤了

11 楼 lunch 2007-11-13  

但是js有能力破坏原有的DOM的Attribute、State、 Value。所以js就像把双刃剑。

10 楼 sp42 2007-11-12  

没有js 也是有DOM;
有js，也是有DOM，
反正B/S表示层的本质工作都是在DOM上呈现
所以，JS/AJAX这个角度看只是控制UI的辅助手段,和安全没有直接联系。

9 楼 boom 2007-11-12  

既然从页面过来的数据都是可以伪造的，那么页面上的验证还有没有必要，个人认为根据情况重要数据操作在后台+前台验证，无关紧要的操作，就不要再后台加了，如果每个操作都要验证，无疑增加了后台代码量，每多一行代码，就多一分BUG存在的可能性

8 楼 lunch 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在开发过程中扮演着越来越多的角色，但这也带来了不少的问题，所以我们必须选择一个合适的折中点。

7 楼 unifly 2007-11-12  

呵呵，还是有人提出来了，自己也想过此问题，限于水平也没想出个道道儿……
搬凳子等达人给说道说道……

6 楼 heimu 2007-11-12  

增强后台验证机制，UI不管怎么说也不过是给人看得

5 楼 myy 2007-11-12  

afcn0 写道

web根本就没什么安全,地址栏写js太菜鸟了,firebug或者append一个textarea再eval那更加方便,简单来说,任何一个get或者post请求都是不可信,都是可以伪造的

说到根子上了！

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

B/S安不安全，不在于你的防范措施有多强，而在于想高破坏的人的水平有多高！

4 楼 afcn0 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的保护力度呢

3 楼 lunch 2007-11-11  

afcn0 写道

web根本就没什么安全,地址栏写js太菜鸟了,firebug或者append一个textarea再eval那更加方便,简单来说,任何一个get或者post请求都是不可信,都是可以伪造的

呵呵，地址栏写js也不是为了调试：） 只是为了说明问题，firebug着实好用。

2 楼 LucasLee 2007-11-11  

是啊，改HTML，JS完全都可行。多年前我用的方法是下载网页，直接修改内容，再打开执行（可能需要修改一些URL链接，因为原来可能用的是相对路径）。

1 楼 afcn0 2007-11-11  

web根本就没什么安全,地址栏写js太菜鸟了,firebug或者append一个textarea再eval那更加方便,简单来说,任何一个get或者post请求都是不可信,都是可以伪造的