膜大佬博客笔记

对于安全测试

越早越好 伴随SDL整个过程
培养开发人员安全意识 特别是从甲方角度来看,培养安全意识 弄好安全开发规范,才是一劳永逸的办法 否则修修补补 还要推动整改 不是好事
业务分级 不在低级别的业务上投入太多 投入产出比
测试过程具有针对性 每个环境都不太一样 所以在不同的环境下 可能有独特的 适合去测试的手法
对于测试目标 争取拿到所有文档 争取覆盖所有 可能 或者不可知的 流程
有白盒尽量白盒 可以覆盖更多 还有就是可以 弄到黑盒忽略的东西 比如就不用猜后面代码怎么写的,根据怎么写的有什么绕过方式 而不是 瞎几把猜和试,还有就是逻辑,就可以一眼看出是否正确。(但是目前我的代码审计经验 可能还是黑盒会更顺手一些)

源代码审计1

安全规范合规性检查VS代码漏洞检查 后者 耗时耗力 且不一定长期有效(版本更新 特性拉之类的)
而开发规范 只用检查是否采用了安全的开发方式 只要规范合适 就可以默认采用了的就是安全的 然后只检查是否合规 消耗小
(强调数据来源不可信原则)

源代码审计2

黑名单VS白名单 黑名单正则 没人可以保证一定就是正确的没有可绕过方式
想起P牛小密圈哪个 D修饰符 导致的上传文件\r\n可以绕过的问题 是由于本身.默认不匹配\r\n 划重点

看了看中间的几个 思路分享 感觉漏洞还是从 来源 经过 结果 这几个部分来考虑 不管是考虑防御 还是考虑攻击 这样每个环节来想一想会更全一些

接下来的部分是大佬的漏洞分享

多线程漏洞

处理代码没加同步锁和并发同步处理
悲观锁 版本号更新 会增加性能消耗 或异步处理

硬件设备问题

预留串口后门
删掉关闭限制

小米测试

过程没啥 但是 风险分析和风险等级的具体评定是之前没接触过的,之后做渗透测试的时候要注意 主要是利用难度和结果的严重性

业务逻辑漏洞

业务逻辑漏洞是跟业务自身强相关的,必须结合业务本身进行分析。
可能有些 不是和安全技术强相关的 一些风险项也会作为一个点来报 但是像我们这种乙方厂商的话做这些 不会太被客户认可
在向客户 接触的时候 项目管理也不太好去 多余的去指导客户做什么,总体还是客户提需求 在技术的角度上把一些安全问题扼杀掉,至于push和其他思量都是客户在做
文中是提的 越权和刷回复的问题

手动分析反射XSS看待安全设计原则

讲的主要是代码复用的问题 没有处理好之前的代码 安全问题引到另一个上面去了
之前在做某客户的测试的时候也有差不多的情况 ,出了漏洞 修补 但是修复是按最简便的临时修复方式来的,这样虽然节省了精力,但是之后系统做了一次迁移 原来的代码直接搬过去,漏洞原封不动出现。

insert型sql注入利用

发现困难,因为是订单的接口 所以可能复现困难,利用的话可以试试报错 或者 延时应该都可以
其余的一些注入 根据注入点在语句中的位置 实在不行就查语法表 看看后面可以跟什么 然后查一下语句怎么构造从这方面去思考
这里有一点就是 虽然从技术上来看该注入为SQL注入影响大,但是实际上影响的只有运费的部分,风险比较小, 在判定一个点对业务的影响风险的时候 需要结合影响来看 。
但是在乙方中或者传统行业中 比如运营商这种 因为有上级的管理 所以完全按照技术来分,导致针对上级检查做的安全检测并起不到很好的作用,因为总是可能存在无风险项被定为漏洞的情况存在

其余的

影响到业务持续性的 和具有安全风险的 都算安全问题 以及 数据安全问题
初入一个甲方做安全的时候 可以更加详细的把战果扩大 以增加对自己的信服度
xssshell 还是类似 服务器用ajaxws之类的方式传输命令 用js来实现吧感觉 数据安全啊 入口和出口 存储的为了未来的安全也需要做一些措施
逆向有时候也是需要的,反正技多不压身
安卓 数据安全 沙箱 权限
物联网 用户隐私 传输
验证码安全 有效期长 错误次数多 长度短 多重验证 甚至加一些其他相关策略
DNS余传送漏洞 拓扑泄漏
在内网环境中如果抓取不到密码 可以尝试使用WinlogonHack一类的工具记录管理员密码,旁站很重要 纵深防御 任何小漏洞 在环境合适的情况下 会为后面的大利用提供便利

应急部分

如果业务使用了第三方的东西 或者数据危险 应当做好隔离 因为本身风险就大,放进来以后出问题就更不好控制
SDL过程中 就应该做好 做完善 还是之前提到的 不然会大大加大后期出问题后的处理成本
使用第三方的东西 要做好对采用什么框架系统的安全性的调研 要么就增加提升安全要求和规范 之后的测试投入也需要到位
然后是上线后的 告警检测手段要及时
看了看后续 源代码自带有马 hhhhxswl
大佬总结是 选产品 还是大的好

传统行业设备和互联网设备的区别:
云平台
没有云平台的通信 其余部分在安全问题上,厂商有点不可控啊
结论:主动推送 如果来不及 紧急临时处理
在我目前接触到的项目中,感觉就是类比为经常推送漏洞预警提醒打好补丁这种吧。。

再接下来是安全测试规范 争取下周看完吧,如果毕设来得及

顺便想到一个东西 以前觉得 响应包的内容是不怎么需要过多关注的,毕竟所有需要的请求都会在burp上被拦截,但是今天看到一个就是说 有可能是根据响应的内容 用js写了一些隐藏的接口 如果不满足条件发出这些请求,本身也没有提供应用的帐号能走到那步的话,可能就找不到相关的问题。以后这点要注意下
另外就是 自己还是接触内网太少了 经验少 完全不熟练 想一想如果真的进去了,说不定刚开始扫就被搞出来了 还是需要熟练手速快 平时如果有练手的就应该去深挖而不是直接把外部的点堵死就行,也能积攒一些 增加速度的工具

大佬的思路 一开始在测试的时候就是想的很广的 毕竟是做整一个项目 所有接手的软件 应用 各方各面能猜测能有问题的地方都会去思考是否存在问题然后上东西去进行测试,向大佬学习

测试规范部分

敏感信息泄露 要注意事先定义好什么算敏感数据范围,在一些上级检查过程中 ,对这点就不太清晰,会导致在测试的时候把很多 无风险项都提出来 影响对接和修补安全工作的推进
sessionid感觉现在基本上都是 使用成熟的框架来生成的 都不会有什么复杂度的问题(根据我测试过的内容)
可预测性也比较上 比较容易碰到的是固定会话 或者url里带sessionid的情况,在接下来就容易是碰到登录过程的问题了
原来超时还分闲置不操作的超时和 绝对时间的超时.
权限问题 一个是 未授权 一个是 鉴权不严

参考链接

大佬博客


发表评论 暂无评论

*