看好你的门-确保验证机制的安全(3)-正确处理验证信息

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考。

1、 前提

执行安全的验证机制,不仅仅要同时满足几个关键安全目标,许多的时候也需要牺牲其他目标。比如易用性、成本、还有功能。

2、 正确处理验证信息的基本要求

一些基本要求,写下来,以后也可以参考。

1. 要确认完整的用户名和密码等信息;也就是说,要区分大小写,不过滤或者修改任何字符,不添加也不截断密码;

2. 应用程序要在处理验证信息的过程中,主动防御无法预料的时间。重要的是,如果系统无法通过正常的验证,那么这个默认的返回值就是“false”,不要把成功作为默认值;

3. 对验证登陆信息的核心代码要进行全面的代码审查(这一块经常没人做,大家都认为用户登陆是一个极其简单的工作;最重要的大门往往是团队中最没有经验的实习生在开发)

4. 如果应用程序支持用户伪装功能(也就叫做用户变更)功能,应该要严格控制这种功能,防止攻击者滥用他获得未授权的访问。因为这种功能极度危险,最好从面向公众的应用程序彻底删除,最多在CN2、DCN等内部网之间有限放开;

5. 和登录阶段进展和各种验证结果都应该保存在服务器端,不能传送给客户端或者让客户端读取;

6. 禁止用户多次提交一项登陆信息;禁止用户修改已经被确认的数据;

7. 任何一个登陆阶段,都要核实前面的阶段是否顺利完成,而不是信任referer等类似可以被擅改的情况;一旦发现前面的阶段没有完成,应该要立即将验证尝试标记为恶意尝试;

8. 如果为了进一步提升安全需要,可以在登陆过程中让用户回答一个随机变化的问题,尽量提升攻击者的难度;

9. 如果对某一个用户提出一个特定的问题,那么对该问题进行长期存储,对用户每一次的失败登陆都用这个问题,一直到用户正确回答为止。(避免攻击者便利题库或者类似情况)

时间: 2024-08-16 12:57:05

看好你的门-确保验证机制的安全(3)-正确处理验证信息的相关文章

看好你的门-确保验证机制的安全(5)-防止滥用密码修改和密码找回功能

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考. 1. 前提 执行安全的验证机制,不仅仅要同时满足几个关键安全目标,许多的时候也需要牺牲其他目标.比如易用性.成本.还有功能. 2. 防止滥用密码修改的基本要求 一些基本要求,写下来,以后也可以参考. 1. 加一个简单图片验证码,基本确保是人在操作,而不是机器: 2. 只能从已经通过验证的会话中访问该功能: 3. 不要以任何方式直接提供用户名,也不要使用隐藏表单字段或者cookie提供用户名:

看好你的门-确保验证机制的安全(2)-安全处理敏感信息

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考. 1. 前提 执行安全的验证机制,不仅仅要同时满足几个关键安全目标,许多的时候也需要牺牲其他目标.比如易用性.成本.还有功能. 我们需要综合考虑下面这些因素: 系统所提供功能的安全程度: 用户对不同类型的验证控制的容忍和接受程度: 支持一个不够友好的界面需要的整体成本(便捷和安全往往是一个事物的两个方向) 系统所保护的信息或者资产的价值. 2. 安全处理敏感信息 一些基本要求,写下来,以后也可

Linux用户安全及Linux PAM验证机制

一.Linux身份验证 1.用户与系统管理员     >用户分为系统管理员与普通管理用户两大类.            >每个用户在系统中都有唯一的用户名,是用户使用系统的凭证.     >系统管理员(System Manager) 又称之为超级用户,账号为"root",也叫根用户,拥有系统操作最高行使权.         >在系统中具有最高权限,主要负责系统管理工作.     >普通用户的账号可以随意取,通常的要求是不能以数字和下划线作为第一个字符.  

看好你的门-验证机制被攻击(2)-JAVA蛮力攻击登陆

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考. 1. 简单说明 攻城的时候,城门总是最容易被攻破的地方. 而登陆功能的公开性,让无数的攻击者都试图猜测用户名和密码,从而获得未授权访问系统的权利. 这种攻击几乎无处不在,有系统的攻击,也有无聊人士的攻击,设置一些搞错了用户名用户的无聊尝试. 2. 前提和准备 我们首先需要有一个弱密码的系统,这样才可以去尝试蛮力攻击. 不要用这种方法去攻击第三方的应用,这是不道德和不友好的行为.分享这种方法,

看好你的门-客户端传数据(10)-不安全的HTML禁用元素

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考. 1. 简单说明 继续说故事,某一天产品经理策划了一个方案,要搞一个促销.一个用户最多只能用一次鸡蛋优惠券. 开发人员需要对系统进行修改和调整. 让我们脑补一下,传统行业搞互联网电商的场景: 产品经理:赶快改,赶快上,赶快搞活动 运维经理:版本升级,提交上线评估报告,风险测试报告,系统测试报告,各位负责领导签字文件--: 开发人员A:靠,老子一早从9点干到晚上9点,还要老子去写那么多报告,让我

看好你的门-客户端传数据(2)-URL参数

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考. 1. 简单说明 应用程序通常以终端用户无法直接查看或者修改的方式向服务器传送数据.很多的时候,开发者都优先考虑实现基本效果,而很少去考虑我们所采用的传输机制能够确保数据在传输过程中不会被修改. 在互联网中,大量的数据通过URL参数的方式进行传递,大部分的数据,是没有通过加密进行传输.在我所了解到的情况,大部分的数据是通过明码进行- 2. 优点: 不用追踪用户会话中的数据,减少保持在服务器上的

看好你的门-客户端传数据(3)-http信息头

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考,请勿用与非法用途. 1. 简单说明 在互联网中,大量的数据通过URL参数的方式进行传递,大部分的数据,是没有通过加密进行传输.在我所了解到的情况,大部分的数据是通过明码进行- 当然,现在大家都知道,URL参数,安全性不是特别高,于是http信息头(包含referer等属性)进入了大家的视野. Referer用来表明,浏览器向 WEB 服务器表明自己来自哪里. 2. 观点: 不知道从什么时候起,

通过扩展改善ASP.NET MVC的验证机制[使用篇]

原文:通过扩展改善ASP.NET MVC的验证机制[使用篇] ASP.NET MVC提供一种基于元数据的验证方式是我们可以将相应的验证特性应用到作为Model实体的类型或者属性/字段上,但是这依然具有很多的不足.在这篇文章中,我结合EntLib的VAB(Validation Application Block)的一些思想通过扩展为ASP.NET MVC提供一种更为完善的验证机制.[源代码从这里下载] 目录: 一.扩展旨在解决怎样的验证问题 二.一个简单的消息维护组件 三.多语言的支持 四.基于某

通过扩展改善ASP.NET MVC的验证机制[实现篇]

原文:通过扩展改善ASP.NET MVC的验证机制[实现篇] 在<使用篇>中我们谈到扩展的验证编程方式,并且演示了本解决方案的三大特性:消息提供机制的分离.多语言的支持和多验证规则的支持,我们现在来看看这样的验证解决方案最终是如何实现的. 目录: 一.为验证创建一个上下文:ValidatorContext 二.通过自定义ActionInvoker在进行操作执行之前初始化上下文 三.为Validator创建基类:ValidatorBaseAttribute 四.通过自定义ModelValidat