WEB 安全开发与渗透测试
0706
本课程: 安全的价值所在与技术层面如何解决 和策略(解决优先级 逐步解决),不是安全设备和网络层面
一 SDL全生命周期
安全开发: js jsp前端漏洞
安全测试: 白盒测试和黑盒测试 渗透测试
安全部署与响应: 社区最新漏洞
内因
开源项目 漏洞延续
外因
开发者缺乏知识,安全教育 ;缺乏安全开发工具
安全保障
apikey不能明文显示
开发测试密码不能一致
cicd环节: 程序员开发过程中及时发现
而不是准备上线扫描出一堆问题
规避:
1 写的时候规避 2开发过程中扫
可预见性: 前端UI组件 涉及底层api 对开源框架自身源代码研究
风险管理:需要有标准 等级
传统软件开发的局限性
非功能性需求部分占比少
没有安全需求分析 安全需求评审
安全性高的重点项目 1 系统设计 2 高并发 高可用设计 3 安全设计
例:
输入 限制 :文件上传
跨站访问 ;
软件安全开发生命周期SDL
权限:最小化 root账号很危险 ,日常开发用普通权限
docker 容器化1.2后被放弃 必须用root访问
关于镜像安全: 自己编译 除了基础镜像
华军软件下载: mysql下载安全问题
软件供应链下载: 有安全的下载渠道
出现问题如何解决 如何验证==>
devSecOps
软件安全发现时间早,成本越低
5+2阶段 ..
16项安全活动 ..
证书 双向SSO认证
sonar安全扫描
组织级认可开发方法,业务部门不关心安全需求与评审
SDL
浏览器内核coding 千万集
第三方浏览器收藏夹纯明文
保存密钥和密码部署同一个人
从官网下载 不要从第三方
软件开发生命周期模型
SDL : 适合全生命周期 BSI BISMM .. 五种
CMMI: x
安全需求设计
有些字段不应该展示给用户,比如权限
0706下
安全设计
达到目标: 安全与性能平衡
威胁建模工具: thread model
问题: 既要沃云又要内网怎么保障
涉密数据如何加密存储
二 重点: 安全清单
==xls文档重点关注== SDL安全设计
输入验证
| 校验跨信任边界传递的不可信数据(策略检查数据合法性,含白名单机制等) |
|---|
| 格式化字符串时,依然要检验用户输入的合法性,避免可造成系统信息泄露或者拒绝服务 |
| 禁止向Java Runtime.exec()方法传递不可信、未净化的数据(当参数中包含空格,双引号,以-或者/符号开头表示一个参数开关时,可能会导致参数注入漏洞),建议如果可以禁止JVM执行外部命令,未知漏洞的危害性会大大降低,可以大大提高JVM的安全性。 |
| 验证路径之前应该先将其标准化为实际路径(特殊的文件名,比如“..”,symbolic links、hard links、shortcuts) |
| 从ZipInputStream提取文件,如果不在程序预期计划的目录之内时,应拒绝将其提取出来,或者将其提取到一个安全的位置 |
| 从ZipInputStream提取文件,若解压之后的文件大小超过一定的限制时,必须拒绝将其解压 |
| 在处理以前,验证所有来自客户端的数据,包括:所有参数、URL、HTTP头信息(比如:cookie名字和数据值),确定包括了来自 JavaScript、Flash 或其他嵌入代码的post 返回信息 |
| 如果任何潜在的危险字符必须被作为输入,请确保您执行了额外的安全控制,比如:输入转义、输出编码、特定的安全 API等。部分常见的危险字符,包含但不限于: < > " ' % ( ) & + \ ' " |
| 如果您使用的标准验证规则无法验证下面的输入,那么它们需要被单独验证,比如验证空字节 (%00); 验证换行符 (%0d, %0a, \r, \n); 验证路径替代字符“点-点-斜杠”(../或 ..\);如果支持 UTF-8 扩展字符集编码,验证替代字符: %c0%ae%c0%ae/ (使用规范化验证双编码或其他类型的编码) |
| 严格验证来自重定向输入的数据(一个攻击者可能向重定向的目标直接提交恶意代码,从而避开应用程序逻辑以及在重定向前执行的任何验证) |
| 验证数据类型 |
| 验证数据范围 |
| 验证数据长度 |
输出编码
| 为每一种输出编码方法采用一个标准的、已通过测试的规则 |
|---|
| 通过语义输出编码方式,对所有从服务端返回到客户端的数据进行编码。比如HTML编码、URL编码等,编码形式需根据具体的应用场景选择 |
| 除非对目标编译器是安全的,否则请对所有字符进行编码 |
| 针对 SQL、XML 和 LDAP 查询,语义净化所有不可信数据的输出 |
| 对于操作系统命令,净化所有不可信数据输出 |
异常处理
| 禁止在异常中泄露敏感信息(敏感数据的范围应该基于应用场景以及产品威胁分析的结果来确定。典型的敏感数据包括口令、银行账号、个人信息、通讯记录、密钥等) |
|---|
| 禁止在异常中泄露应用服务器的指纹信息(如版本,路径,架构) |
| 方法发生异常时要恢复到之前的对象状态(业务操作失败时,进行回滚业务;或者避免去修改对象状态,维持对象状态一致性) |
I/O操作
| 临时文件使用完毕应及时删除 |
|---|
| 不要将Buffer对象封装的数据暴露给不可信代码 |
| 在多用户系统中创建文件时指定合适的访问许可,以防止未授权的文件访问 |
| 当一个外部进程通过其输出流对外输出信息或错误时,必须及时清空其输出流,以防止输出流中的缓冲区被耗尽而导致外部进程被阻塞。 |
| 白名单控制共享目录操作文件权限,比如读/写/可执行权限 |
运行环境
| 不要使用危险的许可与目标组合(比如不要将AllPermission许可赋予给不信任的代码,不要将ReflectPermission许可和suppressAccessChecks目标组合使用,不要将java.lang.RuntimePermission许可与createClassLoader目标组合) |
|---|
| 不要禁用JVM字节码验证,如果使用的字节码,如class文件被恶意篡改过,将会存在安全风险 |
| 建议监控平台不要对互联网开放,仅限于内网环境访问;如果监控平台存在远程执行漏洞,将会给所监控的应用带来安全风险 |
| 建议将所有安全敏感代码(例如进行权限控制或者用户名密码校验的代码)都放在一个jar包中 |
| 生产代码不能包含任何调试代码或接口 |
身份验证
| 除了那些特定设为“公开”的内容以外,对所有的网页和资源都要求进行身份验证,并正确设计身份验证功能 |
|---|
| 所有的身份验证过程必须在服务器后端上执行 |
| 在任何可能的情况下,建立并使用标准的、已通过安全测试的身份验证服务(比如 C4A) |
| 所有的身份验证控制应当安全的处理未成功的身份验证,比如给出错误模糊提示,隐藏敏感信息 |
| 登录入口应具有防止暴力猜解及撞库猜解(利用已泄漏的密码字典进行批量登录尝试)的措施,超过设定失败次数需要启用锁定或图片随机码进行访问限制 |
| 采用https post请求方式传输身份验证的凭据信息 |
| 身份验证的失败提示信息采用模糊处理,比如可以使用“用户名或密码错误”,而不要使用“用户名错误”或者“密码错误”明确提示。 |
| 涉及敏感信息或功能的外部系统连接应配置身份验证功能,并进行有效身份验证控制 |
| 在执行关键操作(如个人信息密码修改操作)时,应对用户身份进行再次验证 |
| 为高度敏感或重要的交易账户使用多因子身份验证机制,如支付密码、短信验证码等 |
短信验证码
| 一次一用 |
|---|
| 发送频率控制(建议60s获取一次) |
| 验证码有效期(建议60s内有效,发短信时进行友好提示) |
| 复杂度(短信验证码建议6位数字) |
| 安全提示:是否是个人自己操作等风险提示信息 |
| 在前端校验(客户端的校验只能作为辅助手段,很容易被绕过),必须使用服务端代码对输入数据进行最终校验 |
图形验证码
| 一次一用 |
|---|
| 验证码有效期(10分钟内有效,可根据场景兼容安全和体验灵活设置) |
| 复杂度(4位及以上数字、字母交替),根据需要也可采用当下流行的拖拽验证码或计算值的验证方式 |
| 服务器端进行认证 |
| 从用户体验和安全角度出发,可设计为当用户输3次错误密码后自动弹出验证码输入框进行验证操作 |
密码管理
| 禁止使用私有或者弱加密算法(比如禁止使用DES,SHA1等,推荐使用AES: 128位,RSA: 2048位,DSA: 2048位) | |
|---|---|
| 采用基于哈希算法和加入盐值(salt)方式安全存储口令信息 | |
| 密码输入框,可设计为显示密码和隐藏密码切换功能 | |
| 密码重设和更改操作,需要进行二次合法身份验证 | |
| 密码重设时,应对注册手机号和邮箱进行有效验证,链接只能发送到预先注册的邮件地址或预先绑定的手机号 | |
| 临时密码和链接应设计一个短暂的有效期(比如5分钟),防止暴力破解 | |
| 当密码重新设置时,应短信通知用户是否是本人在操作,告知安全风险 | |
| 密码复杂度设置:建议8个字符以上,包含字母、数字及特殊字符等 | |
| 密码设置场景中应具有密码复杂度检查功能 | |
| 密码不能输出到日志和控制台 | |
| 数据库连接配置中的用户密码要以加密的形式存储 | |
| 建议设计密码定期修改提醒机制 | |
会话安全
| 用户登出后应立即清理会话及其相关登录信息 | |
|---|---|
| 注销功能应当完全终止相关的会话或连接 | |
| 增加Cookie 安全性,添加“HttpOnly”和“secure”属性(当“secure”属性设置为true时表示创建的 Cookie 会被以安全的形式向服务器传输,也就是只能在HTTPS 连接中被浏览器传递到服务器端进行会话验证,在 HTTP 连接中不会传递该信息,也就不会存在Cookie被窃取的问题;设置了"HttpOnly"属性,通过程序(JS脚本、Applet等)将无法读取到Cookie信息,这样也能减少XSS跨站脚本攻击风险) | |
| 会话cookie应设计有效期,超时后立即失效 | |
| 当设计允许用户在多渠道终端同时登录时,建议应进行常用设备登录限制 | |
| 为包含已验证的会话标识符的 cookie 设置域和路径,为站点设置一个恰当的限制值。默认cookie的域是当前域名,默认cookie的路径是当前页面的目录路径。如果想要跨域或者在其他的路径下访问cookie就必须要重新设置这两个属性,domain和path。 | |
| 注销功能应当可用于所有受身份验证保护的网页 | |
| 在平衡风险和业务功能需求的基础上,设置一个尽量短的会话超时时间。通常情况下,应当不超过几个小时。 | |
| 不要在URL、错误信息或日志中暴露会话标识符,会话标识符应当只出现在http头信息中,不要将会话标识符以 GET 参数进行传递 | |
| 定期生成一个新的会话标识符并周期性地使上一个会话标识符失效(这可以缓解那些原标识符被获得的特定会话劫持情况) | |
| 在身份验证的时候,如果连接从 HTTP 变为 HTTPS,则会生成一个新的会话标识符。在应用程序中,推荐持续使用 HTTPS,不应在 HTTP 和 HTTPS 之间来回转换,有效避免切换过程会话被劫持篡改。 | |
| 为服务器端的操作执行标准的安全会话管理,为每个会话执行合法的身份验证和权限控制,防止存在CSRF跨站点请求伪造漏洞 | |
访问控制
| ------------------------------------------------------------ | 将具有特权的逻辑从其他应用程序代码中隔离开 | | 限制只有授权的用户才能访问文件资源 | | | 限制只有授权的用户才能访问受保护的URL | | | 限制只有授权的用户才能访问受保护的功能或服务 | | | 建议只有授权的用户才能访问直接对象引用 | | | 限制只有授权的用户才能访问受保护的应用程序数据 | | | 限制只有授权的用户才能访问与安全相关的配置信息 | | | 限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源 | | | 服务器端执行的访问控制规则和前端实施的访问控制规则必须匹配 | | | 服务器中创建文件时需指定合理的访问权限(读/写/可执行) | | | 当权限重新设置发生变更时,应记录好日志,并短信通知用户是否是本人在操作,告知可能存在的安全风险 | | | | |
日志规范
| 不要在日志中保存敏感信息,包括系统指纹信息、会话标识符、账号密码、证件、ID等 | |
|---|---|
| 确保日志记录包含了重要的日志事件数据 | |
| 记录所有失败和成功的输入验证 | |
| 记录所有失败和成功的身份验证记录 | |
| 记录所有失败和成功的访问和操作记录 | |
| 记录明显的修改事件,包括对于状态数据的修改 | |
| 记录连接无效或者已过期的会话令牌尝试 | |
| 记录所有的管理功能操作行为,包含但不限于安全配置设置的变更 | |
| 记录所有失败和成功的后端连接 | |
| 记录加密模块的错误信息 | |
敏感信息
| 临时产生的敏感数据(写入内存或文件),应具有及时清除和释放机制 | |
|---|---|
| 不要在 HTTP GET 请求参数中包含敏感信息,如用户名、密码、卡号、ID等 | |
| 禁止表单中的自动填充功能,因为表单中可能包含敏感信息,包括身份验证信息 | |
| 不要在客户端上以明文形式保存密码或其他敏感信息 | |
| 为所有敏感信息采用SSL加密传输 | |
| 禁止将敏感信息(包含加密秘钥等)硬编码在程序中 | |
| 禁止明文存储用户的密码、身份证号、银行卡号、持卡人姓名等敏感信息 | |
| 不要在日志中保存敏感信息,包含但不限于系统详细信息、会话标识符、密码等 | |
| 禁止在异常中泄露应用服务器的指纹信息,如版本,路径,组件版本等 | |
| 禁止将源码或sql上传到开源平台或社区,如github、开源中国等 | |
| 请求中含有敏感参数(如订单号、ID等),应进行混淆方式处理,防止产生参数遍历获取信息风险 | |
| 敏感信息需要展示在web页面上时,应在后台进行敏感字段脱敏处理 | |
| 请求返回数据不应包含请求之外的业务数据,特别是敏感信息数据 | |
| 检查类型 | 检查项(Checklist) |
密码找回安全
| 服务器端要做认证,避免绕过前端控制 | |
|---|---|
| 增加二次认证因子,如验证码 | |
| 涉及登录验证token之类的,不要直接将验证内容直接返回给用户 | |
| 认证凭证加密,推荐强算法(推荐使用AES: 128位,RSA: 2048位,DSA: 2048位) | |
| 认证凭证中的参数应进行混淆处理 | |
| 在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后一步认证的安全风险 | |
| 手机短信码验证,需同时校验手机号和短信是否对应 | |
| 输入框中,应校验输入数据合法性,防止产生XSS跨站脚本攻击 |
SQL注入
| 永远不要信任用户的输入,要对用户的所有输入进行校验,包含SQL语句的过滤和转义 | |
|---|---|
| 永远不要使用动态拼装SQL,可以使用参数化的SQL或者使用存储过程进行数据查询存取 | |
| 永远不要使用管理员权限进行数据库连接,为每个应用使用单独的非特权权限,且配置有限的数据库连接数 | |
| 不要把敏感信息明文存放,采用加密或者哈希、混淆等方式对敏感信息进行脱敏存储 | |
| 应用的异常信息应不带有敏感信息,给出尽可能少的提示;建议使用自定义的错误信息对原始错误信息进行包装,可把异常信息存放在独立的数据库表中 | |
XML注入
| 不要使用字符串/StringBuffer/StringBuilder/StringFormat组装XML | |
|---|---|
| 建议对XML元素属性或者内容进行转义 | |
XSS跨站脚本攻击
| 对输入的数据进行过滤和转义,包含但不限于< >" ' % ( ) & + \ ' "等危险特殊字符 | |
|---|---|
| 数据添加到html元素属性或者内容中时,对数据进行HTML转义 | |
| 数据添加到script脚本中时,对数据进行script转义 | |
| 数据添加到style中时,对数据进行css转义 | |
CSRF跨站请求伪造
| 建议在每个关键表单中引入了CSRF Token验证(会话中生成的随机串,提交后校验) | |
|---|---|
| 在关键表单提交时要求用户进行二次身份验证(录入密码、插KEY、输入图片验证码、短信验证码) | |
| 对请求refer做验证(比如跨域、系统内部应用) | |
文件上传安全
| 上传操作应设计身份验证机制,并进行合法身份校验 | |
|---|---|
| 只允许上传满足业务需要的相关文档类型 | |
| 通过检查文件头信息,比如JPEG (jpg)文件头信息(十六进制):FFD8FF,验证上传文档是否是所期待的类型 | |
| 不要把文件保存在与应用程序相同的 Web 环境中,建议将文件保存在专用的文档服务器中,单独给文档服务器配置域名访问更好 | |
| 限制上传任意可能被 Web 服务器解析的文件 ,比如jsp、php等 | |
| 上传文件以二进制形式下载,建议不提供直接访问(防止木马文件直接执行) | |
| 禁止授予上传文件存储目录的可执行权限 | |
组件安全
| 在使用随机数函数时,推荐使用强随机数函数(例如java.security.SecureRandom类) | |
|---|---|
| 精简组件中不需要的功能、方法,以免带来未知的安全风险 | |
| 不可将系统内部使用的锁对象暴露给不可信代码 | |
| 建议使用SSL Socket代替Socket来进行安全数据交互 | |
| 封装本地方法调用(所有的本地方法都应该被定义为私有的,然后仅通过一个封装方法来调用) | |
| 使用安全管理器(比如java.security或第三方安全组件)来保护敏感操作 | |
| 编写自定义类加载器必须覆盖getPermissions()函数时,在为代码源分配任意权限前,应调用超类super.getPermissions()函数,实现除了自定义策略外,系统全局的默认安全策略也被应用。 | |
| 避免完全依赖URLClassLoader和java.util.jar提供的默认自动签名认证机制,应从加载类的代码源(Code-Source)中获取证书链,然后检查证书是否属于本地密钥库(KeyStore)中的受信任签名者 | |
接口安全
| 调用方来源IP控制,比如可通过防火墙、主机host deny、Nginx deny等技术措施进行实施 | |
|---|---|
| 调用方身份认证,比如key、secret、证书等技术措施进行实施 | |
| 调用参数认证,需设计参数容错机制,避免出现参数可遍历敏感数据安全问题 | |
| 采用数字签名保障接口身份来源可信,数据防篡改 | |
| 调用方权限控制设置 | |
| 调用频率、有效期进行控制 | |
| 调用行为实时检测,对异常阻拦 | |
| 幂等性校验,保持数据一致性 | |
| 采用应用接入安全网关,实现APPID/KEY身份认证,加密传输,摘要签名安全保障 | |
Dubbo调用安全
| 采用token验证访问控制,防止消费者绕过注册中心访问提供者;在注册中心控制权限以决定要不要下发令牌给消费者 | |
|---|---|
| 采用filter IP白名单访问控制,同时也可预防生产系统和测试系统之间Dubbo混乱调用问题 | |
| 在必要情况下(如敏感信息操作),连接注册中心Dubbo时要进行用户名和密码校验 | |
| Redis调用安全 | 应启用客户端IP访问控制验证功能 |
| 应启用客户端身份验证功能 | |
| 敏感信息不要明文存储于Redis |
分析软件攻击面 ->降低
禁止远程访问 受限访问 本地访问
仅管理员访问 用户访问 匿名访问
三 安全红线
| 分类 | 名称 | 潜在安全风险 | 安全要求 | 备注 |
|---|---|---|---|---|
| 帐号安全 | 验证帐号是否存在接口 | 利用此接口批量获取已存在帐号列表 | 此类接口必须提供验证码,并且验证码需要满足相应安全要求 | |
| 注册功能 | 垃圾/恶意注册 | 注册页面必须提供验证码,并且验证码需要满足相应安全要求 | ||
| 登录功能 | 暴力破解 | 同一帐号固定时间范围(比如1分钟)内登录失败次数达到特定次数(比如5次), 24小时内该帐号登录都强制启用验证码验证,并且验证码需要满足相应安全要求 | ||
| 撞库攻击 | 同一IP地址固定时间范围(比如1分钟)内登录失败次数达到特定次数(比如60次), 24小时内该IP登录都强制启用验证码验证,并且验证码需要满足相应安全要求 | |||
| 修改密码 | 密码被攻击者恶意修改 | 修改密码时采用双因素认证方式,除了验证原密码是否正确, 还应该同时验证用户绑定邮箱、手机号等 | ||
| 错误提示 | 攻击者利用返回错误信息进行攻击 | 用户名或密码错误时,返回的提示信息必须一致(比如:输入的用户名或密码错误) | ||
| 登录与注销 | 用户无法主动注销 | 有登录功能的系统必须同时提供注销功能 | ||
| 验证码安全 | 图形/短信/邮箱验证码 | 1、验证码被破解或绕过 2、验证码发送接口被滥用 | 每次请求消耗一个图形验证码 | |
| 图形验证码生成足够随机,具有不可预测性 | ||||
| 必须在服务端验证图形验证码是否正确 | ||||
| 验证码必须设置有效期(有效时间和错误次数),过期失效 | ||||
| 使用短信/邮件验证时,必须限制同一手机号或邮箱的验证码发送频率 | ||||
| 会话安全 | 会话超时 | 会话一直有效 | 会话token/session必须设置超时机制 | |
| 会话更新 | 存在会话固定漏洞 | 帐号登录成功后,必须更新会话ID;帐号注销后,必须强制session/token过期 | ||
| http only | 当系统存在XSS漏洞时导致用户cookie泄露 | 身份认证相关cookie必须设置http only | ||
| 访问控制 | 页面访问控制 | 未授权访问漏洞 | 1、后台页面必须在登录状态下才可访问; | |
| 2、验证当前登录帐号是否有权限访问当前页面 | ||||
| 用户访问控制 | 垂直权限、水平权限漏洞 | 验证当前登录帐号是否有权限访问当前功能、数据、页面等 | ||
| 传输安全 | 可信传输通道 | 流量劫持、信息泄露 | 核心业务系统采用全站https | |
| 敏感参数提交方式 | 造成敏感数据泄露 | 敏感参数(如帐号密码、用户身份认证token、身份证号等)必须通过http post方式提交,严格禁止通过http get方式提交 | ||
| 存储安全 | 密码安全存储 | 敏感数据泄露 | 禁止数据库、日志文件中使用不安全算法【1】存储用户密码 | |
| 敏感数据脱敏存储 | 除用户密码外,其他用户敏感数据(如手机号、邮箱、身份证号等)应脱敏存储 | |||
| 上传下载 | 文件判断 | 任意文件上传、下载漏洞 | 对上传文件后缀进行白名单限制,严格判断文件内容与类型是否匹配 | |
| 目录跳转 | 禁止客户端自定义文件下载路径(如:使用../../../../进行跳转) | |||
| 目录权限 | 存储上传文件的目录必须禁止脚本执行权限 | |||
| 日志审计 | 审计内容 | 无法记录、审计用户操作行为 | 自建用户系统,必须记录用户所有敏感操作日志;要求可以通过记录日志查询到 谁、什么时间、做过什么操作 | |
| 日志清除 | 日志被恶意删除 | 除审计用户外,其他人员不应具备日志修改、删除或清空的权限,必须记录日志清空的行为 | ||
| 日志存储 | 日志被攻击者非常获取 | 禁止将日志直接保存在可被浏览器访问到的WEB目录中 | ||
| 其他 | 后门 | 系统中被预留后门 | 禁止在代码中留置后门 | |
| 备注【1】 | 不安全算法 | 明文、标准MD5算法、Base64编码、私有算法等 |
四 STRIDE威胁建模
Edward: 有点像visio,是一个Microsoft 威胁建模工具 官网: docs.microsoft.com/zh-cn/azure…
简介:
保障安全: 内网安全如果暴露到外网 会提升很多 威胁建模针对这些六各类的威胁STRIBE=>对应用(数据库等)进行6类威胁建模(工具),评估(..性,潜在破坏性)
STRIDE 研发体系自上而下做变革 对现有研发体系全面导入安全,项目管理上支持对安全管理投入的时间
作为当前最流行的威胁建模方法,是值得研发团队引入的威胁建模的方法。 STRIDE 是以下英文 的首字母缩写,把威胁分为6类,基本上涵盖了所有的威胁类型,帮助建模者对威胁进行建模。
S : Spoofing (假冒)
T : Tampering (篡改)
R : Repudiation (抵赖)
I : Information Disclosure (信息泄露)
D : Denial of Service (拒绝服务)
E : Elevation of Privilege (权限提升)
建模识别环节验证
对用户和公有云连接需要有安全保障 ,如果vpn被攻破 没有双因素认证(密码加手机验证码) 会有很大问题
屏幕和键盘输入记录 进入银行系统 oa强密码认证很有必要
API网关 ?
常用缓解方法
IP间隔很短: 500 管控
流量清洗: 挡住恶意访问
抵赖: 根据mac地址溯源
篡改: 高考志愿 应采取数字证书
威胁验证
安全实现
私服下jar包
对依赖库做安全扫描 依赖库不能完全信赖
springboot一个项目有50+框架
dependencyCheck
安全编码:
验证输入:所有输入都是罪恶的
浏览器做校验
尤其是第一次接收数据时候 和 第一次使用数据时候
常用输入: 命令行 环境变量 文件 网络
避免缓冲区溢出
禁用不安全函数 strcpy等
java之所以没有做病毒,运行在虚拟机中,jre中,有沙箱机制,改变不了别人的jre,除非控制jre的分发,所以.java安全性搞,而c++不行,linux安全机制更高,不会root账号运行,病毒需要有感染条件,整体Linux病毒少点
安全编译
好的源代码分析工具
安全审核 !
code review 分轻量级和重量级
轻量级: podrequest 至少>=2人看过合并代码 避免危险
软技能: 在podrequest时候进行code review,重要模块一定要团队内部更多人看到
日常代码sql语句 所有查询都要review,复杂sql要看是否有风险
安全部署与响应
安全部署
安全响应:
->安全应急响应预案
->评估安全漏洞的严重级别
->开发/测试/发布安全补丁的流程
SDL成熟度
安全测试/安全确认
SDL治理
重点关注: 清单, SDL实践, 安全设计, 红线这几个文档
0707
复习:
安全需求与设计
攻击从整个应用攻击
清单 STRIDE
SDL生命周期
1 培训
2 需求
材料
输出: 应用程序安全需求表
工具: 知识管理系统(wiki) 工作进度管理系统 Bug跟踪管理系统(bug栏)
PMO 安全bug纳入安全管理
应用程序安全需求
9`
xx信息涉密 如何处理
3 设计
ASA ASR
材料
安全规范(使用什么加密技术 敏感数据文件长期备份及恢复措施 数据库明文或加密存储等安全级别 第三方软件使用许可控制)
安全部署方案
威胁分析模型(建模工具 网络拓扑 信息流 有哪些威胁和应对策略 => )
4 开发
安全开发工具清单 (虚拟机 IDE 第三方包)---安全工具库 及 常用安全漏洞 不安全函数 危险API列表
包括发现漏洞的API需要及时更新版本
安全开发规范 ---培训考试
安全开发最佳实践 --指导编码
5 测试
安全白盒测试 使用代码扫描工具
安全黑盒测试 模拟攻击渗透测试
6 发布
运维方面
安全应急响应预案
7 上传评审
checklist
peer code review
8 上线
巡检
0707下
安装虚拟机进行练习
1 使用SonarQube实施源代码安全扫描
一、安装JDK
执行以下程序安装JDK 11 \1.JDK\jdk-11.0.15.1_windows-x64_bin.exe
二、安装Apache-maven
创建目录:c:\java 将apache-maven-3.8.6.zip复制到c:\java目录,并解压缩。
增加新的系统环境变量:
M2_HOME=c:\java\apache-maven-3.8.6
修改已有的系统环境变量,增加以下内容:
PATH=%M2_HOME%\bin
配置c:\java\apache-maven-3.8.6\conf\settings.xml文件中私服
验证安装配置结果 运行CMD,执行下命令 mvn --version mvn help:system
三、安装SonarQube
SonarQube docs.sonarqube.org/latest/user… 1、解压缩sonarqube \2.sonar\sonarqube-8.9.3.48735-2022-7-5.zip 到目录c:\java\
2、启动SonarQube c:\java\sonarqube-8.9.3.48735\bin\windows-x86-64\StartSonar.bat
登录SonarQube应用 http://127.0.0.1:9000 admin/admin 修改密码:Passw0rd
四、案例准备
1、将文件解压缩到指定目录 安装文件:\4.case\spring-petclinic-new-main.zip 将文件解压缩到指定目录 安装路径:c:\java\
2、安装文件:\4.case\WebGoat-8.2.2.zip 安装路径:c:\java\
五、SonarQube基本配置
1、配置代码安全扫描规则 定义“质量配置”->Security_Test_1.0,并设置为默认。
六、以Maven方式实施源代码安全扫描
1、Maven中的配置文件,在\apache-maven-3.6.3\conf\settings.xml文件中增加以下内容: sonar true
<sonar.host.url>
http://127.0.0.1:9000
</sonar.host.url>
<sonar.sourceEncoding>UTF-8</sonar.sourceEncoding>
<sonar.login>admin</sonar.login>
<sonar.password>admin</sonar.password>
2、执行扫描:
cd spring-petclinic-new-main
mvn install -Dmaven.test.failure.ignore=true
mvn sonar:sonar -Dsonar.scm.disabled=true
cd c:\java\WebGoat-8.2.2
mvn install -Dmaven.test.failure.ignore=true
mvn sonar:sonar -Dsonar.scm.disabled=true
2 使用dependency-check 插件进行开源框架扫描
用途:用于识别项目依赖项并检查是否存在任何已知的,公开披露的漏洞。开源
结论: 升级开源框架可以解决90%的问题,但是项目升级会报错,出现重大漏洞可以选择单独升级某个包
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>7.1.1</version>
<configuration>
<autoUpdate>true</autoUpdate>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
在target会生成一个html报告
阅读报告要点:
查看high漏洞 根据cve编号在官网查询漏洞详情及解决方案
3 OWASP TOP10
漏洞类型
2021版本相较于2017版本顺序和名称有了更新
4 java编码常见问题
==安全检查清单==: SDL安全设计Checklist-v1.0.xlsx
5 DevSecCops
0708上
1 javascript常见问题
2 网站
developer.mozilla.org/zh-CN/docs/…
3 扫描镜像工具 trivy
code: github.com/aquasecurit…
overView: aquasecurity.github.io/trivy/v0.29…
4 查cve漏洞 cnnvd
编号查询:例
CVE-2022-28391
1 启动docker
systemctl restart docker
2 创建镜像
创建新的镜像文件
vi Dockerfile
插入:
FROM debian:buster
RUN apt-get update && apt-get install nginx -y
docker build -t security_scan_example:latest .
3 扫描Docker镜像漏洞
trivy security_scan_example:latest
4 导出文件
trivy image nginx:alpine >imagevul.txt
解决spring web漏洞
0708下
渗透测试 appscan
4 模拟攻防 webgoat
1 docker安装镜像
2 启动镜像
对打镖程序案例做渗透测试,可以模拟做攻击 docker run -d -p 8080:8080 -p 9090:9090 -e TZ=Asia/Shanghai webgoat/webgoat
3 http://192.168.100.101:8080/WebGoat/
打开页面后,先Register new user
username: owaspadmin1
password: Passw0rd
http://192.168.100.101:9090/login 使用上面注册的账户登录
有通关攻略文档
其他: burpsuit 社区版
5 使用Appscan进行渗透测试
1、运行被测试程序
linux中
cd /opt/app/case/spring-petclinic-new-main
mvn spring-boot:run -Dcheckstyle.skip=true
2、使用AppScan执行扫描
版本10.7
修改为中文
打开程序进行安全扫描
mdtuchuang.oss-cn-beijing.aliyuncs.com/img/2022070…
6 burpsuit pro版本可以完整进行拦截
正常访问web是从浏览器访问
所有请求都会留数据
攻击:正常请求一次 返回响应 获得payload报文,然后绕过js验证
需要装jdk18
7 JWT token认证
JWT主要用于用户登录鉴权