《HTTP图解》读书笔记及总结
针对Web的攻击技术
HTTP不具备必要的安全功能
从整体上看,HTTP就是一个通用的单纯协议机制,具备较多优势,但在安全性方面则呈劣势。比如现在Web网站都会使用的会话管理(session),加密处理等安全性的功能,HTTP协议内并不具备,需要开发者自行设计并实现。
在客户端即可篡改请求
通过URL查询字段或表单,HTTP首部,Cookie等途径把攻击代码传入。
针对Web应用的攻击模式
以服务器为目标的主动攻击
攻击者通过直接访问Web应用,把攻击代码传入,主要来攻击服务器上的资源。常见的攻击是SQL注入和OS命令注入攻击。
以服务器为目标的被动攻击
被动攻击是利用圈套策略执行攻击代码的攻击模式,攻击者不直接对目标Web应用发起攻击(借刀杀人),主要攻击用户的资源和权限。
通常的攻击模式如下:
在Web页面或邮件内设置陷阱
陷阱诱导
用户的浏览器触发事先已设好陷阱的HTTP请求
用户的浏览器运行攻击代码
执行攻击代码的后果是用户所持的Cookie等被窃取、用户权限遭到恶意滥用
被动攻击模式中具有代表性的攻击是跨站脚本攻击(XSS)和夸站点请求伪造(CSRF)
因输出值转义不完全引发的安全漏洞
安全对策大致可分为:
客户端的验证
javascript验证只是为了尽早地识别输入错误,起到提高UI体验的作用。但请求仍然可以篡改,不能完全依赖客户端的验证。服务器端的验证:输入值验证、输出值转义
从数据库或文件系统、HTML、邮件等输出Web应用处理的数据之际,针对输出值做转义是很重要的安全策略。转义不完全时,会因触发攻击者传入的攻击代码,而带来一些危害。
跨站脚本攻击
跨站脚本攻击(Cross-Site Scripting, XSS)是在浏览器内运行非法的HTML标签或JS脚本进行的一种攻击。动态创建的HTML部分有可能隐藏着安全漏洞。
攻击案例:
动态生成HTML处发生,表单中填写HTML甚至JS脚本
浏览器地址栏,Chrome和FireFox现在可以对这种URL进行转义,避免被攻击
http://example.com/login?ID="><script>var ..</script>"
对用户Cookie进行窃取
恶意构造的脚本同样能以跨站脚本攻击的方式,窃取到用户的Cookie信息。
如果响应信息中Cookie设置成HttpOnly,脚本就无法取到
CSRF跨站点请求伪造
SQL注入
现在后端程序员很少用字符串拼接吧,做个了解
//SQL语句
SELECT * FROM party WHERE userName =
//传过来是这样的字符串 'xx' OR 1 = 1
//拼接后,就可以把所有的用户查找出来
SELECT * FROM party WHERE userName = 'xx' OR 1 = 1
HTTP首部注入攻击
有时服务端会把外部就收到的数据赋给首部字段Location和Set-Cookie或者其他字段,攻击者便可以在响应首部字段内插入换行,添加任意响应或主体的一种攻击。
因设置或设计上的缺陷引发的安全漏洞
强制浏览
对那些不愿公开的文件,为了保证安全会隐藏其URL,可一旦知道了URL,也就意味着可以浏览URL对应的文件。直接显示容易推测的文件名或文件目录索引是,通过某些方法可能会使URL产生泄露。
不正确的错误消息处理
Web应用不必在用户浏览画面上展现详细的错误消息,对攻击者来说,详细的错误消息有可能给他们下一次攻击以提示。
开放重定向
开放重定向(Open Redirect)是一种对置顶的任意URL作重定向跳转的功能。如果重定向的URL到某个具有恶意的Web网站,那么用户就回被诱导到那个Web网站。
因回话管理疏忽引发的安全漏洞
会话劫持
攻击者通过某种手段拿到了用户的会话ID,并非法使用此会话ID伪装成用户,达到攻击的目的。
获取会话ID的途径:
通过非正规的生成方法推测会话ID
通过窃听或XSS攻击盗取会话ID
通过会话固定攻击强行获取会话ID
会话固定攻击
访问登录页面
服务器发布一个会话ID,如http://example.com?SID=12k2snsjn
将第2步中的URL作为陷阱,诱导用户A前去认证
用户A认证后,会话ID变味(用户A已认证)状态
之后攻击者再用第2步中的URL访问,伪装成功欢迎用户A
跨站点请求伪造
攻击者通过设置好的陷阱,强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新,属于被动攻击。
攻击案例:
攻击者在留言板上发表恶意代码的评论
<img src="http://example.com/msg?q=你好">
用户A登录,查看留言板
触发陷阱,用户A中浏览器的Cookie持有已认证的会话ID,利用用户A的权限执行发表动作
HTTPS
HTTP在安全方面有以下缺点:
通信使用明文(不加密),内容可能会被窃听
不验证通信方的身份,因此有可能遭遇伪装
无法证明报文的完整性,有可能已遭篡改
HTTPS就是在HTTP上再加入加密处理和认证等机制。
为什么不一直使用HTTPS?
加密通信会消耗更多的CPU及内存资源。如果每次通信都加密,会消耗更多的资源,平摊到一台计算机上,能够处理的请求数量也会随之减少
节约购买证书的开销
因此,如果是非敏感信息则使用HTTP通信,只有在包含个人信息等敏感数据时才使用HTTPS加密通信。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。