web安全开发指南--访问控制

2.1               访问控制安全规则


1


访问控制必须只能在服务器端执行。


2


只通过session来判定用户的真实身份,避免使用其它数据域的参数(比如来自cookie、hidden域、form和URL参数等)来做访问控制。


3


对web/应用服务器进行安全配置以防止用户对静态文件的无鉴权访问(参考附录11.6)。


4


对每一个请求页面都执行严格的访问控制检查(参考附录11.2)。


5


应建立集中式的权限验证接口(参考附录)

2.2               纵向越权


简要描述


如果一名用户能够执行某项功能,但分配给他的角色不具有这种权限,就表示出现了纵向越权漏洞。


解决方案


建议使用基于角色访问控制机制来防止纵向越权攻击,即预先定义不同的权限角色,为每个角色分配不同的权限,每个用户都属于特定的角色,即拥有固定的权限,当用户执行某个动作或产生某种行为时,通过用户所在的角色判定该动作或者行为是否允许(参考附录11.2.1)。


备注


 

 

2.3               横向越权


简要描述


如果一名用户能够查看或修改他没有资格查看或修改的资源,就表示出现了横向越权漏洞。


解决方案


2.3.1、可通过建立用户和可操作资源的绑定关系,用户对任何资源进行操作时,通过该绑定关系确保该资源是属于该用户所有的。

2.3.2、对请求中的关键参数进行间接映射,避免使用原始关键参数名,比如使用索引1代替id值123456等(参考附录11.2.2)。


备注


 

时间: 2024-11-04 02:48:59

web安全开发指南--访问控制的相关文章

Web安全开发指南 PDF

<Web安全开发指南> PDF 只需一元 链接:https://pan.baidu.com/s/1beqor1MxDJiM1cstfpXZew 密码:5zvg 原文地址:https://www.cnblogs.com/luoshuifusheng/p/9305181.html

Web安全开发指南--异常错误处理与日志审计

1.异常错误处理与日志审计 5.1.日志审计系统安全规则 1 日志系统能够记录特定事件的执行结果(比如 成功或失败). 确保日志系统包含如下重要日志信息: 1.  日志发生的时间: 2.  事件的严重等级: 3.  能够标识该事件为安全事件的标签: 4.  导致事件产生的对象: 5.  导致事件产生的IP地址: 6.  事件的结果(成功或失败): 7.  关于事件的描述. 2 如果使用浏览器查看日志,确保先对日志数据进行净化.(item1.2请参考附录11.8) 3 不要在日志中存储任何敏感数据

Web安全开发指南--会话管理

1.会话管理 3.1.会话管理安全规则 1 避免在URL携带session id. 2 使用SSL加密通道来传输cookie. 3 避免在错误信息和调试日志中记录session id. 4 使用框架自带的或业界公认的安全函数来生成session id(参考附录11.4). 5 开发或引入无状态的模块(比如shipin7 nodejs和视频留言模块)时,应与web模块的session机制结合,防止越权或无授权攻击. 6 当使用加密通道SSL/TLS传输cookie时,为其设置“secure”属性.

Web安全开发指南--文件系统

6.1.上传文件功能 简要描述 文件上传漏洞是由于文件上传功能实现代码没有对用户上传的文件进行正确处理,导致允许攻击者向服务某个目录上传文件. 解决方案 上传文件功能只对登录用户开放: 同时通过文件头和文件扩展名来判断文件类型: 判断文件类型时尽量使用黑名单的方式,可以使用较粗粒度方式,比如过滤".php"字串(忽略大小写)来防止php文件的上传: 过滤上传路径或文件名中的NULL字符,防止NULL字符截断: 如果上传的文件为图片,可对图片进行压缩处理再存储: 不要将上传文件的绝对路径

web安全开发指南--认证

1.认证 1.1.       认证和密码管理安全规则 1 认证控制必须只能在服务器端执行. 2 除了指定为公开的资源,对所有其它资源的访问都必须先经过认证. 3 为所有关键凭证实施防"暴力破解"策略(参考暴力破解). 4 当业务系统需要连接到第三方系统并存取敏感信息时,必须要求进行认证,认证的凭证不允许硬编码到代码中. 5 只使用HTTP POST请求来发送认证凭证,并且服务器只接受POST请求. 6 口令必须通过加密通道来传输.注:所有敏感数据都要满足此规则. 7 执行口令长度和复

Web安全开发指南--数据验证

1.数据验证 4.1.输入数据验证安全规则 1 数据验证必须放在服务器端进行. 2 至少对输入数据的数据类型.数据范围和数据长度进行验证. 3 所有来自不可信数据源(比如网络.用户命令.数据库和文件系统等)的数据都要进行有效验证(参考11.7 ESAPI方案). 4 来自客户端的所有参数的数据都要进行验证,比如HTTP header的键值对. 5 数据验证不通过时应默认拒绝处理该请求. 6 应尽可能地使用"白名单"而非"黑名单"的方式对数据进行验证. 4.2.输出数

移动应用安全开发指南(Android)--完结篇(http://www.bubuko.com/infodetail-577312.html)

1.认证和授权 概述 认证是用来证明用户身份合法性的过程,授权是用来证明用户可以合法地做哪些事的过程,这两个过程一般是在服务器端执行的,但也有的APP出于性能提升或用户体验等原因,将其做在客户端完成,由此导致客户端绕过等问题. 安全准则 在客户端做认证和授权是很难保证安全的,所以应该把认证和授权做在服务器端.如果确实有特殊的需求,可以和安全工程师进行沟通做单一case分析. 尽可能避免在设备上存储用户名和密码,可以使用登录认证后获得的token进行鉴权(同时注意控制token的有效期). 详细描

移动应用安全开发指南(Android)--完结篇

如果IE显示格式不正常,请使用chrome浏览器 1.认证和授权 概述 认证是用来证明用户身份合法性的过程,授权是用来证明用户可以合法地做哪些事的过程,这两个过程一般是在服务器端执行的,但也有的APP出于性能提升或用户体验等原因,将其做在客户端完成,由此导致客户端绕过等问题. 安全准则 A.      在客户端做认证和授权是很难保证安全的,所以应该把认证和授权做在服务器端.如果确实有特殊的需求,可以和安全工程师进行沟通做单一case分析. B.      尽可能避免在设备上存储用户名和密码,可以

七日Python之路--第十二天(Django Web 开发指南)

<Django Web 开发指南>.貌似使用Django1.0版本,基本内容差不多,细读无妨.地址:http://www.jb51.net/books/76079.html (一)第一部分 入门 (1)内置数字工厂函数 int(12.34)会创建一个新的值为12的整数对象,而float(12)则会返回12.0. (2)其他序列操作符 连接(+),复制(*),以及检查是否是成员(in, not in) '**'.join('**')   或  '***%s***%d' % (str, int)