学习心得
做渗透也有大半年了，还是需要写点东西总结一下。在前面几个月主要是web渗透，也算是把大学后期的知识复习了一下，算是比较简单的。
web渗透
web渗透很多，网上更是很多思维导图，这里就用列表简单叙述一下：
- SQL注入（高危）： 对于参数检查不严格（不仅仅是用户可输入部分），恶意参数放入sql语句中得到执行，作用对象为web层调用后的数据库。
- XSS（存储性高危，反射型为低危）： 同样因用户输入过滤不严格导致代码在前端js执行，由于是js执行，效果范围有限，一般来说可以盗取cookie，若客户端主机上浏览器或第三方插件存在漏洞，可以通过漏洞控制客户端主机。
- 越权（数据泄露属于高危）： 水平越权和垂直越权，一般来说水平权限容易忽略，修改一下参数中的id值，即可检查出来。
- 文件上传（结合最后利用，严重可获取数据并获得服务器权限）： 文件上传在ctf中考察比较多，上传木马再加上web服务启动的高权限，攻击者可以获取服务器权限。
- 命令执行（视 web执行权限而定）： 由于过滤不严格，参数可以当作代码使用，执行相应命令，若权限较高，则可以执行任意命令。
- 文件包含，远程文件包含（高危）： 让用户，或者公开入口引用文件，并执行了，可用于挂载本身目录无执行权限的文件和外来网站文件，可getshell。
- 密码、随机数不安全（使用一些并强度不是很高，并容易猜解的密码）： 比如数据库使用md5存储密码，或重要信息加密时，模式使用ECB等容易猜解的模式。随机数比较简单，容易猜解。遇到这种情况概率比较低，不过若能破解，则可以达到不错的效果。
- 变量覆盖（视入侵情况而定 ）： 一些全局变量覆盖后，会产生不一样的效果，可能越权执行更多功能。
- 更多
扫描器
一般来说，简单web应用，有一些特色字符套用可以直接检查出来，如果将参数过滤了，也需要遍历各种绕过姿势找到绕过方法。所以自动化填充对一个web狗来说相当重要，也是我下一步安全方向的目标之一。
目前扫描器的了解不是很多，看了几个ppt，传统扫描器的原理和上述一样，不知道会不会有“下一代扫描器”，哈哈哈哈。
这里介绍一下扫描器需要发现的常用漏洞，和上述的漏洞结构分类不同。
信息泄露：
配置文件，测试文件，目录遍历，备份文件，SVN，GIT，压缩包，临时文件，接口暴露，心脏滴血等
错误配置：
WebServer配置失误，中间件配置失误，容器配置失误
前端漏洞：
XSS；CSRF；ClickJacking；Jsonp劫持；HTTP头注入CRLF；URL跳转
弱口令：
SSH，FTP等
WEB注入漏洞：
SQL注入，命令注入，代码注入，SSR网络漏洞，表达式注入，JAVA EL表达式注入命令执行，发序列化漏洞，XPATH注入
文件包含漏洞：
任意文件读取，任意文件上传，XXE，任意文件删除
逻辑漏洞：
jsonp数据劫持，身份认证安全，验证码限制绕过，业务一致性安全，业务数据篡改，认证权限找回逻辑，业务流程乱序，业务接口调用安全
简单编写扫描器，使用脚本调用脚本，各种指纹等特征信息作为可配置文件标准化入库
记录一下各种扫描器的文章链接：
https://github.com/boy-hack（京东同事）
https://x.hacking8.com/ （京东同事个人网站）
https://www.freebuf.com/sectool/162120.html（扫描器开发笔记，可看）
https://github.com/lijiejie/BBScan（简单的遍历扫描器）
https://github.com/We5ter/Scanners-Box（开源扫描器合辑）
https://github.com/0xbug/Hawkeye（github监控平台）
https://github.com/0xbug/SQLiScanner（集成sqlmap可视化）
https://www.freebuf.com/sectool/176562.html（刷SRC经验之批量化扫描实践）
https://github.com/boy-hack/poc-t（遍历脚本）
平台集成思路（网上的）
（注：扫描器很考验安全人员编程能力）
数据分析（日志分析）
我接触过的数据分析主要是日志分析，根据各种各样的系统中出现的异常日志，进行关联分析，当时初学时使用的是es6.0版本，那时的es并不支持直接的关联查询，没有mysql的表关联功能，关联逻辑只能自己写。
日志收集分析的框架主要就是那么几种，没有很多变化，
https://mp.weixin.qq.com/s/K44-L0rclaIM40hma55pPQ（多es集群参考实践）
我对日志收集分析的了解大多还是基于理论，实践经验不是很多。
在少量实践中，我发现最重要的还是规划问题，估计的每日日志量，预留日志量，保留天数等都需要合适的计算。
而且，在系统运行过程中就算是es也会出现各种高可用及性能问题，简单说，日志收集这一块很难做成非单点的，日志收集的完整性也得不到保障，这是日志收集工作出现的问题。
在日志分析中，由于日志的种类多种多样，需要花费大量人力和时间解析日志。同时，需要理解日志含义，决定日志是否存入es中进行处理。我觉得最少在操作系统层面，有很多日志无需录入es，为满足合规规定，用文本形式存储在日志存储服务器中即可，毕竟高配机还是很贵的。
上面说的是日志的问题，还有查询的问题，由于es就不是关系型数据库，就没有关联关系，所以关联关系需要自己根据场景自己进行自己开发。出了上述说的自己写关联关系，还有一种方法，利用es的特性——只能条条查询来完成所谓的关联：将符合某些条件所有日志都查出来放入一个索引中，再进行进一步查询或拉出来再封装一个索引，以数量是否符合正常值为判断标准（只能完成一些简单的关联逻辑）。
对了，还得提一下，在解析的时候，字段名称和索引名称需要使用统一规范进行固定，避免以后不必要的麻烦。
展示阶段，kibana的使用到无太多技巧，如何好看，如何展示，是门艺术，暂时不讲。
除了上述中使用es套件对日志进行猜解外，还有其他很多好用的脚本可以对日志进行简单分析，场景为应急的时候，效率比es套件来的高，思路也更清晰。
最常用的手段，就是linux的awk，grep等过滤命令。具体的另外有笔记记载。
SDL流程
这半年来，我除了做一些安全测试以外，也思考了一下SDL的流程，SDL主要是为了在开发流程中对各个角色（产品，研发，测试，安全）进行提醒，注意安全相关问题，并给出相应的指导意见和注意事项。架构上的安全，我个人其实不太觉得属于SDL。当然，项目初期，安全团队肯定需要对架构进行安全评审。现在SDL不比原来，没有一个统一注意事项，现在SDL注意事项提醒和要求，完全可以按照《网络安全法》，《网络安全等级保护要求》及《网站经营要求》来进行设定。
具体表格也另外有笔记记录。
