web 安全核心防御机制

  • A+
所属分类:安全闲碎

每日学习打卡计划是信安之路知识星球开启的每天读书一小时,挑战打卡一百天的活动,能够坚持学习打卡 100 天的同学可以获得信安之路提供的百分成就徽章和证书,学习书籍可以自选,主要目的是养成每日读书学习的好习惯,并将自己的学习心得分享出来供大家学习,如下是本周打卡榜单:

web 安全核心防御机制

同时在信安之路知识星球同步进行的奖励活动,每周会奖励周榜获赞数第一的小伙伴赠送一种腾讯 VIP 月卡,以鼓励分享优质分享的小伙伴,如下是我关于《黑客攻防技术宝典:web 实战篇》的学习总结。

打卡一(P56-60)

第二章开启了核心防御机制的讲解,主要包含四部分:对于用户访问的处理、对于用户输入的处理、应对攻击者的攻击行为、管理应用程序,这几页主要讲第一部分的对于用户访问的处置。

对于用户而言,大多应用都会存在用户分级,比如最常见的匿名用户、普通用户以及管理员,不同用户对应的应用访问权限不同,可以获取的资源和数据有所区别,那么如何区别用户呢?大概需要三个流程:身份验证、会话管理、访问控制,这也算是应用程序的安全机制,也是最容易出现安全问题的地方,比如绕过认证、越权访问、身份伪造、撞库、爆破、逻辑漏洞等。

在身份验证阶段,大家都有登录的经验,几乎所有应用系统都存在登录,比如淘宝,登录之前可以看一些商品信息,但是想要下单购买就需要登录验证之后才可以操作,淘宝的商品发布就需要店主来操作,游客、买家和卖家对于淘宝的使用是有不同的权限和功能使用的。

除了最基本的账号密码登录外,以前的银行系统会给予每一个开网银的客户一个硬件智能卡,也有些系统需要证书认证,验证的方式很多,核心就是解决验证用户身份的问题。

登录框存在的安全问题比较多,比如:万能密码(sql 注入)、弱口令(默认口令)、可重复提交(爆破、撞库)、信息泄漏(提示过于详细)等。

在会话管理阶段,认证之后如何标识用户身份呢?这里就用到了 cookie 和 session 的技术,cookie 是保存在客户端的 header 中,而 session 的内容在服务器,cookie 中会保留一个 session id,用来对应客户端和服务器中的 session 内容。有些程序员为了方便会把标识身份的特征写入 cookie,通过过去 cookie 中的关键字来确定用户身份,本身客户端提交的任何信息都是不可信,可以伪造的,所以就出现了修改 cookie 来达到越权的目的。

在访问控制阶段,会根据用户的身份信息来开放不同的资源,当游客可以访问认证用户的身份信息时就造成了垂直越权的问题,当认证用户可以访问其他用户的身份信息时就造成了水平越权,这类问题的出现都是因为程序员在设计和开发过程中,对于资源的获取做身份验证的时候没有做或者做的比较粗力度,毕竟做的越细工作量越大,很多时候还是以保证功能为主。

打卡二(P60-68)

这部分内容主要讲的是对于用户的输入如何处置,通常的处理办法有以下几种:

1、黑名单:比如在注册的时候,如果参数里包含单引号时就禁止提交,通过检测参数中是否包含指定的关键词或者关键字符,来判断请求是否正常,对于参数中存在恶意字符时对该请求进行拦截。

2、白名单:这种方式是最安全的,比如在参数是固定格式时,比如纯数字,如果判断参数非纯数字则拦截该请求,但是往往需要用户提交的参数是多样化的,基本上允许输入任意字符,所以这种方式仅在特定的场景可用。

3、过滤:对于用户的输入,根据自己定义的恶意关键词进行过滤,这种方式对于用户体验会好点,不会因为无意识的触发拦截,而是默默的过滤,这里要注意不能只过滤一次,而是要递归过滤,否则很容易绕过过滤的方法。

4、安全编码:像 sql 注入,产生注入的原因是因为程序员将用户输入的参数拼接在数据库的查询语句中,将参数当数据库查询语句来执行,对于编码来说正确的方式是使用参数化查询的方式,参数就是变量,不能作为语句执行,从而避免 sql 注入。

5、身份验证:前几种都是对于用户的输入做验证,而有些漏洞,比如越权访问,所有参数都是正常的,只是用户访问了本来自己无法访问的他人信息,对于用户的每一个操作都应该验证其是否真的有权限访问指定的数据和功能。

除了用户直接输入恶意参数外,之前还出现过二次注入的情况,在首次提交的参数无法直接造成注入,当用户构造的参数被存入数据库之后,在另外一个组件执行查询时会把用户构造的参数当作语句来执行,从而导致注入的产生,所以对于不同组件之间的参数调用,也都要坚持默认不信任的原则,对于输入的参数不管来源都要进行检查。

打卡三(p68-77)

这部分内容主要讲如何应对攻击者的攻击,核心思想就是加固、审计、告警、处置四个部分。

首先加固,我们在做开发的时候通常会设置生产模式、调试模式,在开发的过程中,那面会出各种各样的问题,但是排查问题一定需要设置很多异常处理的流程和提示信息,对于开发者而言,详细的错误提示能够帮助他们快速定位问题,但是如果这部分信息被攻击者获取,那么对于系统而言是非常危险的,所以在上线发布之后一定要对错误信息作处置,尽量避免详细的错误信息,越简洁越好,只能看出正确和不正确,无法得知其核心是为什么触发的异常。在 sql 注入中,有报错注入和盲注,报错注入就是借助报错信息可以快速获得数据库的信息,而盲注就是因为没有详细的错误信息,只能看出也没是否正常,需要用猜解的方式获取数据,难易程度不是一个量级。

关于审计,我们需要将应用的所有日志记录都进行保留,在发生攻击事件时可以做审计,而且要保证日志的完整性,国家的网络安全法就对此做了要求,要求日志保留六个月以上,关于采集日志,需要将应用的访问日志从服务器实时导出,以防攻击者获取服务器权限之后将日志删除或者破坏,从日志中可以分析出很多安全相关的攻击事件,对于这部分事件我们可以重点关注,做一些防御性的措施。

关于告警,就是基于前一步获取的日志,然后审计之后的事件进行实时告警,分析日志属于事后的措施,入侵很多网站都有 web 防火墙也就是 waf,可以做到实时监测和告警,根据告警信息及时跟进,然后进入下一步的处理。

处置的话,属于应急响应的流程,根据告警信息分析事件是否入侵成功,然后分析溯源攻击的有效性,然后分析出那里出了问题,做相应的加固,有临时的拦截,还有漏洞修复,主机加固,然后定损,根据事件的严重程度决定是否对攻击者提出诉讼,走法律程序等等。

总体来说,对于攻击事件,我们无法做到杜绝,只能在攻击的通道上增加阻碍,然后在攻击成功之后可以做到及时止损、加固,用管理和法律的手段对攻击者实施惩罚,这是作为防御者的底线。

之前很多系统的前后台都在一起,所有有很多目录扫描的工具,通过前台的注入漏洞,获取后台管理员的账号密码,因为前台的功能有限,拿 webshell 的难度大,通常会通过目录扫描和猜解的方式找管理后台地址,然后用获取的管理员账号密码登录后台,往往后台的安全性很低,而且权限比较大,甚至有编辑文件的功能,轻松获取 webshell。

现在的很多网站都做了前台和管理后台分离,都操作统一数据库,但是前台对外开放,而后台则只能内网访问,这样就避免由于管理员账号密码泄漏而导致进一步的权限提升,拿到服务器的权限。

web 安全核心防御机制

本文始发于微信公众号(信安之路):web 安全核心防御机制

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: