读<白帽子讲WEB安全>摘要
文章目录
我的安全世界观
安全三要素-CIA
-
机密性 Confidentiality
- 数据不被泄漏
- 加密
- 数据不被泄漏
-
完整性 Integrity
- 保护数据内容完整的、没有被篡改
- 数字签名
- 保护数据内容完整的、没有被篡改
-
可用性 Availability
- DOS-Denial Of Service 攻击会破坏可用性
-
拓展:可审计性、不可抵赖性
如何实施安全评估
互联网安全的核心问题,是数据安全的问题。
-
资产等级划分
- 了解公司最重要的资产是什么,他们最看重的数据是什么 。通过访谈的形式,安全 部门才能熟悉、了解公司的业务,公司所拥有的数据,以及不同数据的重要程度,为后续的安 全评估过程指明方向
- 信 任域和信任边界,网络逻辑上来划分。比如最重 要的数据放在数据库里,那么把数据库的服务器圈起来; Web 应用可以从数据库中读/写数据, 并对外提供服务,那再把 Web 服务器圈起来;最外面是不可信任的 Internet
-
威胁分析
危害的来源称为威胁(Threat)
可能会出现的损失称为风险(Risk)
-
威胁建模
什么是威胁分析?威胁分析就是把所有的威胁都找出来。怎么找?一般是采用头脑风暴 法。当然,也有一些比较科学的方法,比如使用一个模型,帮助我们去想,在哪些方面有可能 会存在威胁,这个过程能够避免遗漏,这就是威胁建模。
-
STRIDE 模型
-
-
威 胁 | 定 义 | 对应的安全属性 |
---|---|---|
Spoofing(伪装) | 冒充他人身份 | 认证 |
Tampering(篡改) | 修改数据或代码 | 完整性 |
Repudiation(抵赖) | 否认做过的事情 | 不可抵赖性 |
InformationDisclosure(信息泄露) | 机密信息泄露 | 机密性 |
Denial of Service(拒绝服务) | 拒绝服务 | 可用性 |
Elevation of Privilege(提升权限) | 未经授权获得许可 | 授权 |
-
风险分析
我们判断风险高低的过程,就是风险分析的过程 .
风险由以下因素组成:
Risk = Probability * Damage Potential
-
DREAD 模型
-
等 级 高(3) 中(2) 低(1) Damage Potential 获取完全验证权限;执行管理员操 作;非法上传文件 泄露敏感信息 泄露其他信息 Reproducibility 攻击者可以随意再次攻击 攻击者可以重复攻击,但有时间 限制 攻击者很难重复攻击 过程 Exploitability 初学者在短期内能掌握攻击方法 熟练的攻击者才能完成这次攻击 漏洞利用条件非常苛刻 Affected users 所有用户,默认配置,关键用户 部分用户,非默认配置 极少数用户,匿名用户 Discoverability 漏洞很显眼,攻击条件很容易获得 在私有区域,部分人能看到,需 要深入挖掘漏洞 发现该漏洞极其困难 -
确认解决方案
-
安全评估的产出物,就是安全解决方案 。
-
设计解决方案不难,难的是如何设计一个好的解决方案。设计一个好的解决方案,是真正 考验安全工程师水平的时候。 很多人认为,安全和业务是冲突的,因为往往为了安全,要牺牲业务的一些易用性或者性 能,笔者不太赞同这种观点。从产品的角度来说,安全也应该是产品的一种属性。一个从未考 虑过安全的产品,至少是不完整的。
-
没有不安全的业务,只有不安全 的实现方式。
-
安全方 案必须能够有效抵抗威胁,但同时不能过多干涉正常的业务流程,在性能上也不能拖后腿。
-
,一个优秀的安全方案应该具备以下特点:
- 能够有效解决问题;
- 用户体验好;
- 高性能;
- 低耦合;
- 易于扩展与升级
白帽子兵法
-
Secure By Default 原则 ,也可以归纳为白名单、黑名单的思想
- 黑名单、白名单
- 最小权限原则
-
纵深防御原则
不同的层面、不同的角度对系 统做出整体的解决方案。
我们常常听到“木桶理论”这个词,说的是一个桶能装多少水,不是 取决于最长的那块板,而是取决于最短的那块板,也就是短板。设计安全方案时最怕出现短板, 第 1 章 我的安全世界观 19 木桶的一块块板子,就是各种具有不同作用的安全方案,这些板子要紧密地结合在一起,才能 组成一个不漏水的木桶。
在常见的入侵案例中,大多数是利用 Web 应用的漏洞,攻击者先获得一个低权限的 webshell, 然后通过低权限的 webshell 上传更多的文件,并尝试执行更高权限的系统命令,尝试在服务器上 提升权限为 root;接下来攻击者再进一步尝试渗透内网,比如数据库服务器所在的网段。
Web 应用 安全、 OS 系统安全、数据库安全、网络环境安全等。在这些不同层面设计的安全方案,将共 同组成整个防御体系,这也就是纵深防御的思想。
纵深防御的第二层含义,是要在正确的地方做正确的事情。 如何理解呢?它要求我们深入 理解威胁的本质,从而做出正确的应对措施。
-
数据与代码分离原则
这一原则广泛适用于各种由于“注入”而 引发安全问题的场景。
实际上,缓冲区溢出,也可以认为是程序违背了这一原则的后果——程序在栈或者堆中, 将用户数据当做代码执行,混淆了代码与数据的边界,从而导致安全问题的发生。
在 Web 安全中,由“注入”引起的问题比比皆是,如 XSS、 SQL Injection、 CRLF Injection、 X-Path Injection 等。此类问题均可以根据“数据与代码分离原则”设计出真正安全的解决方案, 因为这个原则抓住了漏洞形成的本质原因。
-
不可预测性原则
不可预测性原则,可以巧妙地用在一些敏感数据上。比如在 CSRF 的防御技术中,通常会 使用一个 token 来进行有效防御。这个 token 能成功防御 CSRF,就是因为攻击者在实施 CSRF 攻击的过程中,是无法提前预知这个 token 值的,因此要求 token 足够复杂时,不能被攻击者 猜测到。
-
客户端安全
浏览器安全
同源策略
same origin policy 时浏览器也是最核心的功能。如果缺少同源策略,浏览器的正常功能都会受影响。
浏览器只是同源策略的一种实现。
浏览器的同源策略,限制了来自不同源的"document" 或脚本,对当前的“document ”读取或者设置某些属性。
影响源的由 host (域名或ip地址)、子域名、端口、协议。
但浏览器中
XMLHttpRequest受到同源策略的约束,不能跨域访问资源。
随着业务的发展,跨域请求越来越迫切。因此W3C委员会制定了XMLHttpRequest跨域访问的要求,他需要通过目标域返回的HTTP头来授权是否允许跨域访问,因为http头对于javascript来说一般是无法控制的,所以这个方案是可以实施的,这个跨域方案的安全基础:javaScript 无法控制该Http头。如果信任基础被打破。则此方案将不在安全。
对于浏览器来说,处理DOM、cookie、XMLHttpRequest受到同源策略的限制外。浏览器加载的一些第三方插件也有各自的同源策略。最常见的插件有 flash、java applet、silverlight、 google gears等都有自己的控制策略。
浏览器沙箱
采用sandbox技术,让不受信任的脚本允许在一个受限制的环境中,从而可以保证本地桌面系统的安全。
恶意网址拦截
挂马 攻击是在正常的网页中,通过 script 或 iframe 等标签加载恶意的网址。
钓鱼网站、诈骗网站对用户来说也是一种恶意网址。
恶意网址的拦截非常简单,定期从服务器端获取一份最新的恶意网址清单。用户在浏览恶意网站时会弹出警告。
常见的恶意网址分两类:一类是挂马网站、一类是钓鱼网站。
高速发展的浏览器安全
IE 推出Xss filter
firefox 推出的csp
XSS 跨站脚本攻击
XSS简介
XSS = cross site script
XSS 通常指黑客通过 “html注入” 篡改了网页,插入了恶意的脚本。而从在用户浏览网页时,控制用户浏览器的一种攻击。这种攻击的演示案例是跨域的,所以叫跨站脚本,但是发展到今天,是否跨域已经不在重要。
- 反射型XSS
简单的把脚本反射给浏览器,黑客 往往要诱使客户‘"点击"一个恶意链接。才能攻击成功。
- 存储型XSS
把用户输入的数据存储在服务器端,这种XSS具有很强的稳定性。
- DOM Based XSS
通过修改页面的dom节点形成的XSS,称之为DOM based XSS
XSS 攻击进阶
初探XSS Payload
从攻击者的角度来体验下XSS的威力。
XSS攻击成功后,攻击者能够对当前浏览器的页面植入恶意脚本,通过恶意脚本。控制用户的浏览器,用于完成具体功能的恶意脚本。被称之为“xss payload”。
常见的payload就是cookie劫持。
cookie中一般保存了当前用户的登录凭证。如果cookie丢失,往往意味着用户的登录凭证丢失。换句话说,攻击者可以不通过密码,而直接登录进用户的账户。
攻击者获取到用户的cookie后,可以使用此cookie发起攻击。
强大的xss payload
构造GET和POST请求。
一个网站只接受http协议中的get和post请求,对攻击者来说,只通过JavaScript就可以让浏览器发送此请求。
此不需要劫持用户的cookie,只要构造 网站的现有get或post方法。即可控制客户的浏览器。
XSS钓鱼
- xss的攻击过程都是JavaScript自动进行的,也就是说缺少交互过程。
-
如果在构造post请求是,加上验证码,但也不能彻底防止。
攻击者:对于验证码可以把验证码图片发送到攻击者后台识别。
-
此外在大多数修改密码的功能会要求输入旧密码。但是这也不能防止xss payload。
修改密码问题稍微复杂,需要将XSS与"钓鱼"相结合。
实现思路:使用javascript在当前页面上"画出"一个伪造的登陆框,当用户在登录框输入用户名与密码,将密码发送至黑客的服务器上。
-
识别用户浏览器
-
识别用户安装的软件
CSS history hack
利用style的visited属性,如果用户曾经访问过某个链接,那么这个链接的颜色会变的与众不同。
获取用户的真实IP
xss攻击框架 “attack ip” 由可以获取本地api
XSS 攻击平台
- attach api
- BeEF
- XSS-Proxy
终极武器 XSS Worm
一般来说,用户之间发生发生交互行为的页面,如果存在存储型XSS,比较容易发起XSS Worm
调试JavaScript
- firebug
- ie 8 developer tools
- fiddler
- httpwatch
XSS构造技巧
- 利用字符编码
- 绕过长度限制。
- 利用事件,加载location.hash的值
- 利用注释,合并2个input标签
- 使用base标签。 在设计XSS 安全方案时 一定要过滤这个非常危险的标签
- window.name 的妙用。
window 对象时浏览器窗体
- 变废为宝 Mission Impossible
-
apache expect header xss
-
anehta的回旋镖
-
flash xss
-
JavaScript 开发框架 真的安全么
dojo
yui
jquery
XSS 防御
XSS的本质是HTML注入。将用户的数据当作代码执行。
HttpOnly
解决XSS攻击中的cookie劫持问题。
服务器可以设置多个cookie,可以给制定的cookie设置HttpOnly。
respone.setHeader("Set-Cookie","cookieName=value;Path=/;Domain=domainValue;Max-Age=seconds;HTTPOnly");
- 1
输入检查
XSS攻击和Sql Injection。需要对输入进行检查。这种检查被称为“XSS Filter”。
对 script 和 javascript onclick alert 等以下关键字处理。
输出检查
一般来说,除了富文本输出外,在变量输出到HTML页面时,可以使用编码或转义的方式来防御XSS攻击。
-
安全的编码函数
编码分为很多种,针对html代码的编码方式是
HtmlEncode
。HtmlEncode
不是专有名字,是一种函数的实现。作用就是将字符转换成HTMLEntries
,对应的标准是ISO-8859-1
。在
javascript
可以使用JavaScriptEncode
。& -> & > -> > < -> < " -> " ' -> ' / -> /
- 1
- 2
- 3
- 4
- 5
- 6
正确的防御XSS攻击
1. HTML 标签中输出。`HtmlEncode`解决 。 2. HTML 属性中输出。`HtmlEncode`解决。 3. script标签中输出。`javascriptencode`解决 4. 事件中输出。`javascriptencode`解决。 5. css标签中输出。`encodeforcss`解决。 6. 在地址中输出。`URLEncode`解决。
- 1
- 2
- 3
- 4
- 5
- 6
处理富文本
1. 过滤富文本,比较危险的标签,比如<iframe>、<script>、<base>、<form>等。
- 1
防御 DOM Base XSS
javascript 输出到html页面,相当于一次XSS输出的过程。需要分语境使用不同的的编码函数。 >`javascript`输出到html event 或 script tag需要JavaScriptEncode >`javascript`输出到html content 或 script attribute 需要 JavaScriptEncode. ```javascript 1. javaScript输出到html页面 document.write() document.write() xxx.innerHtml() doucument.attachEvent() window.attachEvent() document.location.replace() documment.location.assign() 2. 可能出现dom base xss 页面所有的输入框 windows.location href hash window.name window.refer document.cookie localstorage XMLHttpRequest 返回的数据 ```
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
CSFR跨站请求伪造
cross site request forgery
CSRF 进阶
浏览器的cookie策略
cookie分为:
- “session cookie” 又叫 “临时cookie”。浏览器关闭就失效。
- “third party cookie” 也称为"本地cookie"、第三方cookie。在set-cookie时设置了Expire时间,到了Expire时间,cookie失效。
出于安全考虑,
IE
默认禁止了浏览器在<img>
、<iframe>
、<script>
、<link>
等标签发送第三方cookie。Firefox chrome 默认会发送第三方cookie。
P3P
the platform for privacy preferences
如果http返回的 header中含有P3P头,在某种程度上将允许浏览器发送第三方cookie,在IE下即使是>&#12289;
但是如果设置了P3P 头可以允许跨域访问隐私数据, 从而使跨域set-cookie成功。
在网站业务中,P3P头主要用于类似广告的等需要跨域的访问页面。但遗憾的是P3P头设置后,对cookie的影响到 了整个域的页面,因为cookie是以域和path为单位的。这并不符合“最小权限”原则。
cookie是以域和path为单位的
诱导用户访问恶意链接。可调用系统的现有的接口,导致出现一些客户不知情的操作。
get or post
get和post都能发起csrf攻击。
Flash CSRF
IE6 IE7,flash发送的网络请求可以带上本地cookie,从ie8起,flash发起的网络请求不再发送本地cookie。
CSRF worm
CSRF防御
-
验证码
-
Referer check
常见的应用就是"防止图片盗链"。Referer check 也可以被用于检查请求是否来自合法的源。
常见的互联网应用,页面与页面之间都具有逻辑关系,这使得每个正常的请求Referer具有一定的规律。
缺陷:服务器并非任何时候都能获取Referer。
refer policy说明
https://w3c.github.io/webappsec-referrer-policy/#referrer-policies
-
Anti CSRF Token
CSRF 为什么能成功,因为重要操作的所有参数是可以被攻击者猜测到的。
新增一个参数Token,token是安全的随机数生成算法。
提交表单时,带上随机token,token的值也存在session中,在提交处理中校验token是否存在
-
Token 的使用原则
-
防御CSRF的Token,是根据“不可测性原则”设计的方案,需要使用安全的 随机数生成Token.
-
Token的目的不是为了防重复提交。虽然可以达到此效果。
-
Token 应保持保密性,如出现在URL中,可能会在Referer中泄漏。应该使用ajax或post提交。
还有一些XSS漏洞或者跨域漏洞可能让攻击者窃取到Token值。
-
Token 仅仅是用于对抗CSRF攻击,当网站还有其他XSS漏洞时,这个方案会变得无效。因为XSS可以模拟客户端浏览器执行任意操作。攻击者完全可以请求页面后,读出页面token的值,然后再构造一个合法的请求,这个过程可以称为 XSRF和CSRF区分开。
-
点击劫持
ClickJacking
点击劫持是一种视觉上的欺骗。往往使用透明的iframe嵌入目标网站。欺骗目标网站用户,窃取客户信息。
flash点击劫持:
图片覆盖攻击
拖拽劫持和数据窃取
触屏劫持
智能终端上的触屏劫持
防御点击劫持
可以写一段JavaScript代码,以禁止iframe嵌套,这种方法是 frame busting。
frame busting
是指利用js判断location以防止网页被别人iframe内嵌的一个实现
比如以下代码:
if(top.location != location){ top.location=self.location; }
- 1
- 2
- 3
常见的frame busting 条件判断
1. if (top != self)
-
if (top.location != self.location)
-
if (top.location != location)
-
if (parent.frames.length > 0)
-
if (window != top)
-
if (window.top !== window.self)
-
if (window.self != window.top)
-
if (parent && parent != window)
-
if (parent && parent.frames && parent.frames.length>0)
-
if((self.parent&&!(self.parent===self))&&(self.parent.frames.length!=0))
如果frame busting 条件判断为真,常见的动为以下:
-
top.location = self.location
-
top.location.href = document.location.href
-
top.location.href = self.location.href
-
top.location.replace(self.location)
-
top.location.href = window.location.href
-
top.location.replace(document.location)
-
top.location.href = window.location.href
-
top.location.href = “URL”
-
document.write(’’)
-
top.location = location
-
top.location.replace(document.location)
-
top.location.replace(‘URL’)
-
top.location.href = document.location
-
top.location.replace(window.location.href)
-
top.location.href = location.href
-
self.parent.location = document.location
-
parent.location.href = self.document.location
-
top.location.href = self.location
-
top.location = window.location
-
top.location.replace(window.location.pathname)
-
windowwindow.top.location = window.self.location
-
setTimeout(function(){document.body.innerHTML=’’;},1);
-
window.self.onload = function(evt){document.body.innerHTML=’’;}
-
var url = window.location.href; top.location.replace(url)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
几种攻击方法:
- 二次frame(不能针对 top.location,只能针对 parent.location)
- 利用 onbeforeunload 事件
- xss
- 构造referer绕过js referer检查
- 浏览器漏洞。
- iframe security属性(仅IE支持)
- iframe sandbox属性(HTML5)
- 浏览器designmode
- 部分手机站点
相关总结:
http://seclab.stanford.edu/websec/framebusting/
X-Frame-Options
-
DENY 拒绝当前页面记载任何iframe
-
SAMEORIGIN iframe只能是同源域名下的页面
-
ALLOW-FROM origin 可以定义iframe可以加载的地址
- X-Frame-Options
- firefox 的content security policy和noscript 也能有效防御click-jacking
- 用hidden 元素的方法,有点山寨,不过有用且通用
HTML5安全
html新标签的xss
可嵌入javascript实现xss攻击。
有研究者建立了一个html5 security cheatsheet项目。
iframe 的sandbox属性
“” 应用以下所有的限制。 allow-same-origin 允许 iframe 内容被视为与包含文档有相同的来源。 allow-top-navigation 允许 iframe 内容从包含文档导航(加载)内容。 allow-forms 允许表单提交。 allow-scripts 允许脚本执行。 link types : noreferer
html5的标签 可以指定noreferer,浏览器在请求该标签指定的地址时不再发送Referer.
这是出于保护敏感信息和隐私的考虑,因为通过referer可能会泄露一些敏感数据。
canvas的妙用
canvas可以使javascript可以操作图片的像素。
其他安全问题
cross-origin resource sharing CORS
浏览器的同源策略 same origin policy 限制了脚本的跨域请求。互联网的趋势越来越开放。跨域访问需要越来越急迫。出现很多跨域的技术
jsonp
、iframe
等。-
XMLHttpRequest 在ie中可以使用XDomainRequest来跨域。
-
使用response的header中设置
Access-Control-Allow-Origin的值*
,但是很不安全。https://w3c.github.io/webappsec-referrer-policy/#referrer-policies
可以使用request中header中origin
。origin
不像referer一样容易被伪造或者置为空。
postMessage 跨窗口传递消息
在跨站脚本攻击 一章中,曾经提到利用 window.name 来跨窗口,跨域传递信息。window对象几乎不受同源策略限制。很多脚本都利用了window对象这一个特点。
服务器端应用安全
注入攻击
注入攻击的本质是将用户的数据当作代码来执行。
两个关键条件- 用户能控制输入
2.程序原本要执行的代码,拼接了用户输入的数据。
sql注入
-
盲注
-
timing attack
数据库攻击技巧
常见的攻击技巧 命令执行 攻击存储过程 编码问题 sql cluumn truncation
- 1
- 2
- 3
- 4
- 5
数据库防御
找到所有的sql注入漏洞
修补这些漏洞- 使用预编译语句
- 使用存储过程
- 检查数据类型
严格过滤检查 用户的输入数据。
- 使用安全函数
其他注入
- xml注入
xml注入越要满足注入的攻击的两大条件。用户能控制输入的数据,程序拼凑了数据。
与html一样,将“语言本身的保留字符”进行转义处理。- 代码注入
- CRLF 注入
cr = carriage return
lf = lind feed文件上传文件
上传漏洞概述漏洞
文件上传常见漏洞- 上传的文件是web脚本语言,服务器的web容器解释并执行用户上传的脚本,导致代码执行。
- 上传文件时flash的策略文件domain.xml,类似浏览器下的跨域。
- 上传文件是病毒和木马、黑客用以诱骗用户或者管理员下载执行。
- 删除的是钓鱼图片或者包含了脚本的图片,在某些版本的浏览器中会被作为脚本执行,被用于钓鱼和欺诈。
绕过文件上传检查功能。
功能还是漏洞
apache 文件解析问题
apache 1.x 2.x 对于不认识的文件按照php文件处理。IIS文件解析问题
PHP的cgi问题
利用上传文件钓鱼钓鱼网站在传播的时候,会通过利用xss,服务端的302跳转等功能,从正常网站跳转到钓鱼网站。
设置安全的文件上传功能
1.文件上传的目录设置为不可执行
2.判断文件类型
3.使用随机数改写文件名称和路径
4.单独设置文件服务器域名由于浏览器同源策略,一系列的客户端攻击将失效,比如上传crossdomain、上传包含javascript的xss利用等问题将解决。
认证和会话管理
认证目的是认出用户是谁。就是认证用户凭证的过程。
而授权的目的是为了决定用户能够做什么。
密码那些事儿
-
密码必须是不可逆加密算法或者单向散列算法,加密后存储在数据库中的,sha-1 、md5 存储。
-
多因素认证,以支付宝为例,支付密码,安全问题,实名认证,短信验证,证书 等等。
session 与认证
session一旦在声明周期内被窃取,就等于账户失窃,Session是用户登陆的凭证,黑客将不在登陆,因此黑客不再需要登录过程。
session泄漏的途径很多,xss攻击、网络sniff以及本地木马窃取。
xss攻击通过设置httponly解决,对于网络嗅探,本地木马只能通过客户端 解决。sessionId 生成必须要要有随机性。
手机很多浏览器都不支持session,都是在url中传输sessionId。session fixation 攻击
登录后需要重写sessionId。
session保持攻击
session保持攻击,可以通过不断的访问后台,保持服务器session有效。
甚至攻击者可以 把session cookie 增加一个expire date变成了third party session。永远的持久化在客户本地。
如何防御
强制将session过期,或者客户存在多个session。以最后一个session生效。其他的session都是失效。sso 单点登录 single sign on
访问控制
what can i do ?
某个主体 subject能对某个个体 object 需要实施某种操作
垂直权限管理
访问控制实际上是建立用户与权限的关系。
现在由一种通用的方法,基于角色的访问控制,role base access contorl 简称RBAC.
不同角色的权限有高低,往往高权限能防访问低权限的资源。
用户->角色->权限
以spring security为例水平越权管理
可称之为基于数据的访问控制
加密算法与随机数
Web框架安全
mvc 框架安全
view 负责用户视图、页面展示工作
control 负责用户逻辑的实现,接受view传送的数据,并转发给model处理
model model负责数据处理。web框架与csrf 策略
模板引擎与xss防御
- post请求添加token
- session 绑定token
- form 表单自动添加token
- ajax请求中自动添加token
- 在服务器端对比post参数的token与session的token是否一致
http header 的管理
在web框架中,可以对http头进行全局化的处理,因此一些基于http头的安全方案很好实施。
- 对http返回头的crlf攻击,所有的head都是key value 键值对。
location : http://www.a.com
host:127.0.0.1
对抗CRLF的方案只需要在value中编码所有的\r``\n
- 类似针对
30X
返回号的http response ,浏览器将会跳转到location制定的url,攻击者往往利用此类功能实施钓鱼和咋骗。
HTTP/1.1 302 Moved Temporarily
Location: http://www.fakesite.com管理好跳转地址很重要
1.如果web框架提供统一的跳转函数,则可以在跳转函数内部实现一个白名单,指定跳转地址只能在白名单 2.另一种解决是控制location的地址,本质还是白名单形式。
- 1
- 2
X-frame-options
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
httponly
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies
数据库与sql注入
还能想到什么
凡是在web框架可能实现的方案,只要对性能没有太大的损耗,都应该考虑实施。
spring security为spring mvc的用户提供了很多安全的功能,比如针对url的控制访问。
加密方法、证书支持、openId支持。但是还是缺乏的xss、csrf等问题的解决方案。
在设计整体框架安全解决方案时,比较科学的方法是建立威胁模型
在设计web框架安全解决方案时,还需要保存好安全检查日志,比如发生XSS 攻击时,可以记录下攻击者的ip、时间、useragent、目标url、用户名等信息。web框架的自身安全
关注业界前沿。框架漏洞。
##应用层拒绝服务攻击
PHP安全
Web Server 配置安全
安全开发流程
安全运营
安全运营
修补漏洞流程
安全监控
入侵检测
紧急响应流程
邮件 im 短信