javascript入侵业务安全浅谈

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

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

       

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

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

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

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

       

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

        

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

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

       谢谢您耐心看完此文。

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

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

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

楼主这个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的保护力度呢

说到根子上了！

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

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

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

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

afcn0分析的更加深入一些，关于b/s系统的见解也和fins的差不多，就是只有b系统和s系统。
见：世上没有B/S系统,只有B系统和S系统
我们现在面临的问题都是这样，随着客户体验要求的提高，和整个行业的发展趋势，js在开发过程中扮演着越来越多的角色，但这也带来了不少的问题，所以我们必须选择一个合适的折中点。

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