Web安全基础
2023-03-29 15:00:36 1 举报AI智能生成
登录查看完整内容
白帽子讲安全思维导图整理，涵盖常见基础漏洞的攻击与防御，基本的安全原则，
作者其他创作
大纲/内容
是一种约定，限制了来自不同源的“document”或脚本，对当前“document\"读取或设置某些属性
同源策略
挂马：在网页插入一段恶意代码，利用浏览器漏洞执行任意代码的攻击方式
沙箱：资源隔离模块浏览器模块值让不受信任的代码运行在一个受限制的而环境中，从而保护桌面系统的安全
浏览器沙箱
将浏览器各个功能模块分开，各个浏览器模块实例分开，一个进程崩溃，不影响其他的
多进程架构
周期性从服务器端获取一份最新的恶意网址名单
恶意网址黑名单
EV SSL证书
恶意网址拦截
浏览器安全
简单的将用户输入数据反射给 浏览器
反射型
会把用户输入的数据存储在服务端
存储型/持久型
通过修改页面的DOM节点形成的XSS
DOM型
XSS攻击成功后攻击者能对用户页面植入恶意脚本，这些用来完成各种具体功能的恶意 脚本叫做XSS Payload
Cookie劫持
构造POST与GET请求
识别用户浏览器
识别用户安装软件
xss payload
用户之间发生交互行为的页面，如果存在存储型XSS，则比较容易引起Worm攻击
百度空间蠕虫
XSS Worm
百度在一个<script>标签中输入变量时转义了双引号，GBK/GB2312 %c1与\\会组成新的Unicode字符
利用字符编码
利用事件 onclick等
将XSS payload写在别的地方，然后加载这段代码， location.hash
利用注释符绕过长度限制
绕过长度
作用是定义页面上所有使用的”相对路径”标签的hosting地址
使用<base>标签
对当前窗口的window.nam赋值没有特殊字符 的限制，window是浏览器的窗体不是document对象，很多时候不受同源策略的影响
window.name的妙用
XSS构造技巧
Falsh XSS、回旋镖
攻击
禁止页面的javaScript访问带有HttpOnly属性的cookie
HttpOnly解决的是 Xss后的cookie劫持攻击
HTTPOnly
XSS、sql注入都需要构造一些特殊字符
格式检查、XSS filter（没有结合渲染页面的代码，对 语境的理解不够）
输入检查
除富文本的输出外，在变量输出到HTML页面时，可以使用编码或转义来防御XSS
HtmlEncode（将字符转换成HTMLEntities）、JavaScriptEncode
在Html属性中使用
HtmlEncode
在<script>中使用、在事件中输出、在CSS中输出
JavaScript
在地址中输出，先检查是否以http开头
URLEncode
安全的编码函数
输出检查
标签选择上使用白名单
开源项目对富文本的XSS检查
富文本
DOM的防御
防御
XSS
分类
攻击者诱使用户访问一个页面，就以用户的身份在第三站点里执行一些操作
Session Cookie 临时Cookie
Third-party Cookie 本地Cookie
浏览器的Cookie策略
如果网站返回给浏览器的HTTP头中包含P3P头，则在某种程度上，允许浏览器发送第三方Cookie
由于P3P在网站中被广泛应用，CSRF的防御不能依赖于对第三方Cookie的拦截策略
P3P
进阶
验证码
常用与防止图片盗链同理也可用于检查请求是否来自合法的源
缺陷在于，服务器并不是什么时候都可以取到Referer
Referer Check
加密重要参数 或 使用随机数缺点URL不可读、不能收藏等
CSRF攻击能成功的本质原因是重要擦操作的所有参数都可以被攻击者猜测到
防御SCRF的Token是根据不可预测性原则设计的，所以Token的生成要足够随机
Token
CSRF攻击是攻击者利用用户的身份操作用户账户的一种攻击方式，，根据不可预测性原则，常使用Anti SCRF Token来防御CSRF，要注意Token的随机性和保密性
CSRF 跨站请求伪造
是一种视觉上的欺骗手段，攻击者使用一个透明的、不可见的iframe覆盖在网页上，诱使用户在网页上操作
XSIO
图片覆盖攻击
拖拽不受同源策略的限制
拖拽劫持与数据窃取
触屏劫持
禁止iframe嵌套
使用HTTP头---X-frame-Options
点击劫持
新标签的XSS
iframe的sandbox
标签指定noreferrer后，浏览器在请求指定地址时不在发送referrer
处于保护敏感信息和隐私的考虑
Link types:noreferrer
canvas标签能让JavaScript在页面内直接操作图片对象 甚至是像素
验证码的识别
Canvas
新标签
跨窗口传递信息，不受同源策略的 限制
postMessage
其他安全问题
HTML5安全
客户端脚本
点击劫持相对于XSS与CRSF来说 ，因需要诱使用户与页面产生交互行为，实施攻击的成本较高
业务安全
1、培训：覆盖 安全设计、威胁模型、安全编码、安全测试、隐私等方面
培训
确保安全的要求和需要做的事情。确认项目计划和里程碑，关键节点、避免延期
2、确认安全需求
3、质量门和bug栏
安全风险评估和隐私风险评估是必须的；哪些部分发布前需要的威胁模型；那些部分需要进行安全设计评审；哪些部分需要双方认可的小组进行渗透测试；是否存在安全顾问认为需要增加的测试或分析；模糊测试要求的具体范围；隐私影响评级如何；
4、安全和隐私风险评估
需求
在设计阶段要再仔细考虑安全和隐私问题，在项目初期确立安全需求，避免安全引起的需求变更
5、设计要求
减少攻击面与威胁模型紧密相关，减少攻击面通过减少攻击者利用潜在漏洞的机会来降低风险；主要包括关闭或限制对系统服务的访问，用最小权限原则，分层防御
6、减少攻击面
为项目产品面临的威胁建立模型，明确可能的攻击来源，微软提供的STRIDE（伪装、篡改、抵赖、信息泄露、拒绝服务、权限提升）模型 DREAD 造成的损失有多大、重现的可能性、可利用性、受影响的用户、发现的容易程度
7、威胁建模
设计
使用的编译器、链接器等，使用的版本需要提前与安全团队沟通
8、使用指定的工具
9、弃用不安全的函数
代码静态分析可用相关辅助工具完成
10、静态分析
实施
动态分析是静态分析的补充，用于测试环节验证程序的安全性
11、动态分析
模糊测试是一种专门形式的动态分析，通过故意向程序引入不良格式或随机数诱发程序故障。
12、模糊测试
项目可能会因需求变更导致最终产出偏离原定的目标，所有在项目后期重新进行威胁模型和攻击面评审是有必要的。
13、威胁模型和攻击面评审
验证
受SDL要求每个软件发布时都需要包含事件响应计划。即使发布时不包含任何已知漏洞的产品。如包含第三方的代码，也需要留下第三方的联系方式，加入到事件响应计划，以便迅速找到负责人
14、事件响应计划
15、最终安全评审
通过FSR发布的产品也需要同时对各类问题和文档进行存档，为紧急响应和产品升级提供帮助
16、发布存档
最终安全评审FSR是在发布前仔细检查对软件执行的所用安全活动
发布
安全开发周期
SDL适用于采用瀑布模型进行软件开发的团队
敏捷开发往往采用小步快跑的方式，不断完善产品，没有非常规范的流程。
敏捷SDL思想就是以变化的观点实施安全工作。需求和功能一直在变，代码也在变。要求在实施SDL时在每个阶段更新威胁模型和隐私策略，在必要环节迭代模糊测试、代码安全分析等工作
敏捷SDL
与项目经理沟通、排出足够的时间
规范公司立项流程、确保所有项目都通知到安全团队、避免遗漏
树立安全部门的权威、项目必须有安全部门审核完成后才能发布
将技术方案写入开发、测试的工作手册
给工程师培训安全方案
记录所有的安全BUG，激励程序员编写安全的代码
SDL实战
安全开发流程 SDL
安全运营
安全问题的本质是信任问题
安全的本质
机密性
完整性
可靠性
安全三要素
白名单、黑名单，如果能更多的使用白名单，那么系统会更加安全
最小权限原则：系统只授予主体必要的权限
Security By Default原则
一层含义：在各个层次、不同方面实施安全方案
另一层含义：要在正确的地方做正确的事
纵深防御原则：Defense in Depth
适用于个各种“注入”攻击
数据和代码分离
能有效对抗基于篡改，伪造的攻击
其实现往往需要用到加密算法、随机数算法、哈希算法等
微软缓冲区溢出：使用DEP保证堆栈不可执行，ASLR让进程栈基址随机变化
不可预测性原则
兵法
资产等级划分
可能造成危害的来源叫做威胁
互联网安全的核心 是数据安全
可能会出现的损失叫做风险
STRIDE模型：S：伪装 T:篡改 R:抵赖 I:信息泄露 D：拒绝服务 E:权限提升
威胁分析
DREAD模型
风险分析
有效解决问题；用户体验好；高性能；低耦合；易于扩展
确认解决方案
如何实施安全评估
安全观
security By Default 是时刻牢记的总则纵深防御是要更全面、更正确的看待问题数据和代码分离是从漏洞成因上看问题不可预测性是从克服攻击方法的角度看问题
一般构造简单的条件语句，看返回的页面是否变化
盲注：在服务端没有错误回显时完成注入攻击
Mysql benchmark()函数 让同一个函数执行若干次
sqlmap
LOAD_FILE 读取系统文件 INTO DUMPFILE写入文件
利用用户自定义函数 UDF来执行命令
攻击存储过程
编码问题
攻击技巧
使用预编译语句，绑定变量
使用存储过程，先将SQL语句定义在数据库中
检查数据类型
使用安全函数
最小权限原则，避免高权限账户直连数据库
sql注入
XML注入
代码注入
CRLF注入 CR(\)和LF(\)是两个字符 \\两个字符表示换行
其他注入攻击
注入攻击
都是 违背了数据和代码分离的原则
文件上传漏洞是指用户上传了一个可执行脚本文件，通过脚本获取执行服务端命令的功能
Apache文件解析问题 从后往前解析
IIS文件解析 windows环境下截断符号为';' 处理文件扩展名错误
将文件上传目录设置为不可执行
判断文件类型时结合使用MIME Type、后缀检查等方式，推荐使用白名单检测文件类型处理图片时使用压缩函数或者resize函数处理图片时可以破环包含的HTML代码
使用随机数改写文件名和路径
单独设置 文件服务器的域名
文件上传
认证的目的时为了认出用户是谁 ；授权的目的是为了决定用户能够做什么
认证实际上是一个验证凭证的过程
密码必须以不可逆的加密算法或者是单向散列函数算法加密后存储在数据库中
多因素认证：动态口令、数字证书、宝令[采用基于时间同步的双因素动态密码认证技术，每分钟能够生成一个新的、且不重复使用的“动态密码”]、第三方证书
Session与认证 SessionID加密后存在Cookie中
Session保持攻击 通过不断发起访问请求，让Session一直活下去
单点登录 SSO
认证与会话管理
某个主体对某个个体需要实施某种操作，而系统对这种操作的限制就是权限控制
操作系统中给文件设置的ACL[Access Control List]访问控制列表
基于url的访问控制
基于方法的访问控制
基于数据的访问控制
Web应用中常见的访问控制
访问控制就是建立用户和权限之间的对于关系
Spring Security
现在广泛应用的一种方法---基于角色的访问控制(RBAC)
两种权限管理方式：基于URL的访问控制、基于方法的访问控制、还支持基于表达式的访问控制
Spring Security
垂直权限管理
水平权限管理
访问控制
1
2
不要使用ECB模式
不要使用流密码 如RC4
使用HMAC-SHA1代替MD5
不要使用相同的key做不同的事情
salts与IV需要随机产生
不要自己实现加密算法，使用已经存在的库
不要依赖系统的保密性
不建议
使用CBC模式的AES256用于加密
使用HMAC-SHA512用于完整性检测
使用带salt的SHA-256或SHA-512用于Hashing
建议
加密算法与随机数
Web框架安全
应用层拒绝服务攻击
PHP安全
Web Server配置安全
服务端应用安全
注入的本质是把用户输入的数据当代码执行。两个关键的条件：1、用户能 控制输入；2、原本程序要执行的代码，拼接了用户输入的数据
是静态 的、白盒软甲源代码安全测试工具。
通过内置五大主要分析引擎：数据流、语义、结构、控制流、配置流等对应用软件的源代码进行静态分析，通过与软件安全漏洞规则进行匹配、查找、宠儿将源代码中存在的安全漏洞导出，可导出报告。最后的结构 不包括安全漏洞的详细信息、相关的修复意见
通过调用语言对应的编译器，把语言代码转换成中间媒体文件NST，将其源代码之间的调用关系，执行环境，上下文等分析清楚通过分析不同类型问题的静态分析引擎分析NST文件，同时匹配所有规则库中的漏洞特征，抓出漏洞，形成包含详细漏洞信息的结果文件
fortify
dependency-check
sonarlint
工具
Web安全
收藏
职业：暂无
0 条评论
回复 删除
下一页
