当前位置: 代码迷 >> Java Web开发 >> 关于WEB开发的安全性的有关问题
  详细解决方案

关于WEB开发的安全性的有关问题

热度:8519   发布时间:2013-02-25 21:10:52.0
关于WEB开发的安全性的问题
小弟目前是一名初级的JSP程序员,接触开发只有几个月的时间,经验尚浅。关于WEB开发的安全性的问题,有一点疑问想请教大家,希望大侠们给予解答。

我目前只完整地做过一个项目中的部分功能。在我们公司做的这个项目中,我感觉它安全性有一些问题。单单针对我能想到的地方而言就有不少问题。

这个项目是一个企业的非核心业务项目。系统中可以设定多种角色人员,不同的人员权限不同,可以看到和更改的数据都是不同的。

我们假定这个系统的用户中有一些网络高手,他们做过WEB开发。

我这个问题是突然想到要来这发帖问的,语言表述和行文条理可能有些问题,希望大家将就着看,多多见谅。背景介绍完毕。

我想到的问题是,我们在项目中有不少的地方是在调用后台JAVA方法的时候加入参数来实现的(后台可能用request.getParameter( )之类的方法来得到这个参数),而这个参数在一些情况下是在浏览器的地址栏可见的,大致相当于“xxxx action.do?method=xx&parameter=yy”,里面的这个xx 和 yy就是参数,参数的改变直接就可以导致用户看到不同的数据,而这些数据可能是本来不该被这些用户看到的。即使打开的网页去掉了浏览器地址栏,用户也可以通过查看网页属性来看到这个网址;即使参数在提交到后台前进行了转码,那么用户也随便可以到网上找个转码工具来看到实际的参数值,然后再把自己想用的参数转码之后再放到地址栏里去。

也就是说,我们做的某些功能的权限控制,对于比较了解网络的人来说基本就是形同虚设。我问过我们的项目经理这个问题,但是我们项目经理没有给我一个明确的回答,只是说了个“看情况”,然后说“session里面的东西你肯定不能用这种方法做参数”,别的什么也没说。

然后我们公司用的一套框架,有代码生成器,可以根据数据库的表结构自动生成工程的基本的增、删、改、查功能的原始模型,我们做的东西实际都是以生成的代码为基础来做的。里面的某些方法,可能我们实际不用,但是我们不会删掉它,用户假如知道(或者猜到,因为各种功能命名的方法很相似)这个方法,那么他就可以做一些本来不应该由他做的事情。这个事情也问了我们项目经理,他想了一下,然后说不用管,因为“他首先要知道这个方法的名称,而且他还要知道这个ID”。实际上那个ID只是在数据库中设定为自增的一个列,里面的值全是数字递增排下来的,假如有人比较了解这套东西,把1-100的数字作为参数遍历一遍,基本上这个系统就全毁了。

然后我也帮别人做了一点功能,里面也发现了类似的问题,也问过项目经理,他看了一眼就说不用管。项目做完后测试人员来测,我说你们会不会用在浏览器地址栏上改参数的方法来测试它呢,测试人说不会那么测的。我终于觉得公司在这个事情上根本就不关心。

至于我自己那一块,我就在调用后台方法的时候先把参数验证一遍,每个可能用参数的地方都要写相应的验证代码,很麻烦。

现在我的问题来了。有以下几个:
1、一般的做 JSP 的公司,对安全性方面有多高?一般的公司会不会考虑这样的问题?什么样的公司会考虑这样的问题?我这样的考量是不是对于诸多的公司来讲很多余?
2、一般什么样的客户、什么样的业务才会考虑这样的问题?他们在项目验收的时候一般会不会这样去测一遍?
3、如何解决这样的问题?有没有什么长效机制?总不可能每个方法在接收参数的时候都验证一遍吧。
4、听说有些高手能“绕过”JS ,可不可以给我举一个例子?另外还有哪些方法可以绕过系统的权限控制?
5、关于法律层面的:侵入计算机系统是非法的,但是如何界定一个人是不是“侵入”到计算机系统的呢?就假如发生了用户改了地址栏参数这样的情况,算不算他非法入侵呢?什么情况才算非法的?

望大家解答,谢谢大家。

------解决方案--------------------------------------------------------
数据通过表单提交的 <form method="get"//默认方式,推荐用post方式数据被保存到请求体而不是在地址栏后面,安全你考虑太多了,先把业务做好吧,绕过js 很容易的可以将html源码,有个js修改除去验证有可以啦,点击提交不会验证啦,通过技术保证安全性,地址栏参数这样的小伎俩,对程序员不是什么问题了把
------解决方案--------------------------------------------------------
嗯。地址栏参数对用户而言就是公开的,哪怕做成post进来,用户想要模拟一个post请求进来,是不难的。
所以LZ的担心是实际存在的,
不过这问题可以利用session+filter解决。
总之,不符合用户session里面表明的用户身份的事情,包括参数越权,严谨的应用应该考虑到要禁止这种行为发生。
就像我们提供客户端数据验证后Server端一定要再验证一遍一样。
客户端是不可信的,这一点是要谨记于心。
------解决方案--------------------------------------------------------
探讨

我给的分也不算少啊 为什么答的人只有两个~

------解决方案--------------------------------------------------------
如果权限通过 URL 参数来决定的话,那这套系统基本上没有任何安全可言。

一般来说一个基本于数据库应用的权限至少有以下几张表:

用户表(存放用户基本信息、登录数据)
角色表(存放系统角色信息)
权限表(存放系统权限信息,每个功能模块、甚至是按钮的权限)
用户角色表(用户与角色的对应关系)
角色权限表(角色与权限的对应关系)

更完善一点的话,还可以有用户权限表

基本关系是一个用户对应多个角色,一个角色对应着多个权限

对于用户来说,其拥有的角色、权限是管理员给分配好的。

假如某一用户 user 给他分了个 manager 角色,而 manager 角色有对 A 功能的增删改查权限。这样当 user 登录后,就可以获得他拥有什么权限,在进行 A 功能操作的时候检查一下 user 是否拥有该权限即可。
------解决方案--------------------------------------------------------
6楼说的有意思嘛,同时客户端的是完全不可靠的、
lz没事儿去银行网站逛逛,你把你的技术都拿出来哈,看看是不是你想的那样的、
对了,不成功是不被叫做非法 的

------解决方案--------------------------------------------------------
post的方式提交可以不在URL上显示参数
而且request也可以获取到
------解决方案--------------------------------------------------------
回楼主:除了对内的,一般对外的都不会把敏感的信息用GET来取参的,用SESSION,POST安全很多,
可能我这样说很模糊,其实对于一写神人,人家要HACK我门,总是能的,我自己都对这个问题投了降
------解决方案--------------------------------------------------------
用网址传递参数的时候可以加密的啊,看看淘宝的网址,一大串,你怎么去修改参数?
  相关解决方案