http-安全

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

web 安全
http 本身不具备安全性能

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、web 安全威胁分类

WASC（Web Application Security Consortium）
是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体。

OWASP(Open Web Application Security Project)
该组织致力于发现和解决不安全Web 应用的根本原因
这个组织最重要的项目之一是“Web 应用的十大安全隐患”
总结了目前Web 应用最常收到的始终攻击手段，并且按照攻击发生的概率进行了排序

WASC 将web 应用安全威胁分为六大类

1、Authentication(验证):用来确认某用户、服务或是应用身份的攻击手段
2、Authorization(授权):用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段
3、Client-Side Attacks(客户侧攻击):用来扰乱或是探测Web站点用户的攻击手段
4、Command Execution(命令执行):在 Web 站点上执行远程命令的攻击手段
5、|nformation Disclosure(信息暴露)用来获取 Web 站点具体系统信息的攻击手段
6、:用来扰乱或是探测 Web 应6、Logical Attacks(逻辑性攻击)用逻辑流程的攻击手段

OWASP 漏洞分类

A4:2017-XML外部实体(XXE)
许多较早的或配置错误的XML处理器评估的XML 文件中的外部实体引用。攻击者可利用外部实体窃取内部文件、执行远程代码
A5:2017-失效的访问控制
未对通过身伤验证的用户实施恰当的访问控制,
A6:2017-安全配置错误
于不安全的默认安全配置错误是最常见的安全问题，这通常是由配置、不完整的临时配置、开源云错误等造成。
A7:2017-跨站脚本:(xSS)
XSS会让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。
A8:2017-不完全的反序列化
不安全的反序列化会导致远程代码执行
A9:2017-使用含有已知漏洞的组件
组件如库框架和其他软件模块拥有和应用程序相同的权限
A10:2017-不足的日志记录和监控
不足的日或无效的集成，使攻志记录和监控，以及事件响应缺失击者能够:#一步攻击系统、保持持续性、篡攻、提取或销毁数据

二、验证机制

1. 验证机制是web 应用程序中最简单的一种安全机制
   一般来说，应用程序必须合适用户提交的用户名和密码是否正确。正确则允许登录，否则禁止登录
2. 验证机制是应用程序防御恶意攻击的核心机制
   它处在安全防御的最前沿，如果被用户轻易突破，通常应用程序的全部功能、数据都会被其控制。
   缺乏安全有效的验证机制，其他核心安全机制都无法实施（会话管理和访问控制）

典型的身份验证模式讨论

验证技术

1. 基于HTML 表单的验证
2. 多元机制，如组合型密码
3. 客户端SSL 证书（通常在银行，使用网银）

基于HTML表单的验证

1. 弱密码-用户密码强度

• 非常短或空白密码
• 以非常常用的字典词汇为密码，比如123456，password等等
• 密码和用户名完全相同
• 长时间使用默认密码
• 忘记密码

暴力破解

登录功能的公开性会诱使攻击者试图猜测用户名和密码，从而获得访问应用程序的权力。
如果应用程序允许攻击者用不同的密码暴力尝试，直到他找到正确的密码，这个程序就非常容易遭受攻击。

执行暴力攻击示意图

很多工具（如Burpsuite）自身提供了一些常用的密码破解表，也能自行添加一些常用字典，网上也有更多全面的密码字典。
按照如今的带宽和CPU处理能力，根据破解者的能力，每分钟可以发出几千甚至上万个登录尝试，如果没有一些安全措施的话，最强大的密码也最终会被攻破。

应对暴力破解的安全措施

1. 验证码技术
2. Cookie 和会话检测
3. 双因子认证

验证码

验证码技术是最常见且最有效的应对方式，但是还需要注意几个问题：

1. 验证码是否真实有效
2. 验证码复杂度
3. 应对当前的“打码”事业盛行

Cookie 和会话检测

有些应用程序会设置一个cookie，如果faillogin =0;登录尝试失败，那么faillogin++,达到上限，比如3次；检测到这个值大于等于3，那么就会拒绝登录操作了。
但是这种方式没有什么用，因为cookie 可以在客户端更改。

双因子认证

双因子认证的核心是综合what you know(个人密码)和what you have(手机)l来达到双重认证效果。

忘记密码

忘记密码的核心问题：忘记密码的流程调过了身份验证

忘记密码的三种方式来认证用户

1. 用户设定的安全问题；比如你的大学学校名字是什么？
2. 用户注册时留下的安全邮箱
3. 给预留手机号发送验证码短信
   但是，这三种方式都容易被敌手截获并篡改信息。

多阶登录机制

人们总认为知道的信息越多，那么越真实，其实这种想法是错误的。
执行多次验证检查可能会提高登录机制的安全性，但是相应的，这个过程也可能存在更多的执行缺陷。不能保证每个阶段都是正确的。有可能跳过某一个或者某几个阶段，直接验证最后一步，然后验证成功。

三、会话管理概述

会话令牌：cookie

会话令牌生成漏洞

1. 通过用户的用户名或者电子邮箱地址转换而来，或者使用其他相关的信息创建
2. 把用户的一些信息通过某种方式进行编码或者模糊处理，也可以与其他数据结合在一起
3. 令牌具有可预测性； 一些会话令牌包含某种顺序或模式，允许攻击者通过几个令牌样本，就可能推断出应用程序最近发布的其他有效令牌。
4. 生成随机数强度不够；计算机中的数据极少完全随机，因此如果由于某种原因需要随机数据，一般通过软件使用各种技巧生成伪随机数字

会话终止攻击

1. 尽可能缩短一个会话的寿命，可降低攻击者截获，猜测或者滥用有效会话令牌的可能性
2. 如果用户不再需要现有会话，终止会话为用户提供一种使其失效的途径，在进一步境地上述可能性的同时，在某种程度上，确保共享计算环境中会话的安全。
3. 一些应用程序并不实施有效的会话终止功能；会话一旦建立，它在收到最后请求的许多天内仍然有效，直到服务器最终将其清除。有些时候，退出功能实际上并不能帮助服务器终止会话。即使服务器从用户的浏览器中删除令牌，如果用户继续提交令牌，服务器仍然能够接收。最糟糕的情况：当用户单击“退出”按钮式，应用程序并不与服务器通信，因此服务器不采取任何行动。访问这个客户端的攻击者，仍然可以使用cookie ，好像用户从未退出一样。

会话劫持攻击

攻击者通过网络嗅探，xss 攻击等方式获取被攻击者会话令牌的攻击方式。这种方式最简单也最有效，也是目前最多的攻击方式。

四、会话管理漏洞的防御

令牌传出安全

1. 令牌传输只能通过https
2. 如果使用http cookie 传送令牌（大多数情况下），应该将这些cookie 标记为secure，以防止用户浏览器通过http 传送它们。

    // 设置cookie
    app.get('/cookie',(req,res)=>{
        // 使用了中间件后就可以访问req和res上的cookies对象
        console.log(req.cookies);
        // 不加密写入cookie
        // res.cookie('num', 10, {
        // 	// domain: 'xxx.com',
        // 	// path: '/',
        // 	maxAge: 24 * 3600 * 1000
        // })

        // 加密后读取cookie
        console.log(req.signedCookies['num'])
        res.cookie('num', 10, {
            // httpOnly: true,
            // secure: true,
            signed: true,// 签名一定要写上这个，表示对cookie 进行签名
            maxAge: 24 * 3600 * 1000
        })
        res.send({
            code:200,
            data:'ok'
        });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

增加软硬会话过期

软会话过期，它指的是用户在一定的时间内，与应用系统没有交互，则会话过期，也就是我们常说的session 失效
硬会话过期，它指的是用户登录到系统中经过一定的时间，不管用户做什么，该会话都会过期。

提供完善的注销功能

用户可以手动地使当前会话过期，这就是我们在几乎所有网站上都能看到的logout 按钮。要保证注销不存在会话终止漏洞

五、SQL 注入原理

1. 几乎每一个web应用都需要使用数据库来保存操作所需的各种信息。
2. 所以web程序经常会建立用户提交数据的SQL语句，
3. 如果，建立这种语句的方法不安全，那么应用程序就很容易受到SQL注入的攻击。

最严重的情况下，攻击者可利用SQL注入读取甚至修改数据库中保存的所有数据。

用户可以提交一段数据库查询代码，根据程序返回的结果获得某些他想得知的数据。

SQL 注入危害

1. 探知数据库的具体结构，为进一步攻击做准备
2. 泄露数据，尤其是机密信息、账户信息等
3. 取得更高权限，来修改表数据甚至是内部结构

SQL 注入防御

参数化查询

参数化查询是对SQL 注入根本性的防御策略，也叫做预处理语句，在建立一个包含用户输入的SQL 语句是分为两步：
1.指定查询结构，用户输入预留占位符
2.指定占位符的内容

六、XSS 攻击原理

跨站脚本攻击(Cross Site Scripting)，XSS是一种经常出现在web应用中的计算机安全漏洞。
它允许恶意web用户将代码植入到提供给其它用户使用的页面中，其他用户在观看网页时，恶意脚本就会执行。

这类攻击通常通过注入HTML或is等脚本发动攻击。
攻击成功后，攻击者可以得到私密网页内容和cookie等。
最近几年XSS 攻击已经成为最流行的攻击方式

XSS 攻击的举例

1. 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2. 控制数据，包括读取、篡改、添加、删除企业敏感数据的能力
3. 盗窃企业重要的具有商业价值的资料
4. 非法转账
5. 强制发送网站挂马
6. 控制受害者机器向其它网站发起攻击

XSS 分类

1. 反射式XSS
2. 存储式XSS
3. 基于DOM 的XSS

反射式XSS

也称为非永久性XSS，是目前最流行的XSS攻击:
它出现在服务器直接使用客户端提交的数据，如url的数据html表单中提交数据等，并且没有对数据进行无害化处理。
如果提交的数据中含有HTML控制字符而没有被正确处理那么一个简单的XSS攻击就会发生。

反射式XSS举例

典型的反射式攻击可通过一个邮件或中间网站，诱饵是一个看起来可信任的站点的链接，其中包含XSS攻击脚本。

如果信任的网站没有正确处理这个脚本，用户点击后就会导致浏览器执行含有恶意攻击的脚本。

这个例子说明：

1. input 的值可以用任何返回给浏览器的数据替代
2. 无论老服务器应用程序如何处理这些数据，都无法阻止提交JavaScript 代码，一旦该页面显示，这些代码就会执行

存储式XSS

也成为永久性XSS，危害更大。
攻击将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员，

存储式XSS 举例

存储式XSS多发生在最终显示给其他用户的位置包含

1. 个人信息字段，如姓名、地址、电子邮件、电话等
2. 文档、上传文件及其他数据的名称
3. 提交给应用程序管理员的反馈或问题
4. 向其他应用程序用户传送的消息、注释、问题等
5. 在用户之间共享的上传文件内容
6. 于是你发布一个热点信息，利用该漏洞获取用户信息，吸引其它用户纷纷阅读。
7. 任何其他人浏览该信息，其会话cookies或者其它信息将被你盗走

基于DOM的XSS 攻击

反射式XSS攻击和存储式XSS攻击都是通过服务器端提取用户提交的数据。
并且以不安全的方式将其返回给用户。
基于DOM的攻击仅仅通过JavaScript的方式执行。

也就是说这种攻击常发生在应用程序每次返回相同的静态html，而通过客户端JavaScript动态生成信息，并不会跟服务端交互获取的时候。

XSS 攻击载荷（就是xss 最容易攻击的地方）

会话令牌

1. XSS 攻击最普遍的方式
2. 截取以为受害者的会话令牌，劫持他的会话，从而作为受害者的身份来使用应用程序，执行任意操作并占有该用户的账户。

虚拟置换

这种攻击需要在一个Web应用程序页面注入恶意数据从而向应用程序的用户传送误导性信息。

包括简单的向站点注入html，或者使用脚本注入精心设计的内容

攻击者实际上没有修改保存在服务器上的内容，而是利用程序处理并显示用户提交的输入方面的缺陷实现置换。

注入木马

这种攻击造成的后果远比虚拟置换严重，它在易受攻击的应用程序中注入实际运行的功能，旨在欺骗终端用户执行某种有害操作(如输入敏感数据)
随后将它们传送给攻击者。
在一个明显的攻击中，攻击者注入的功能向用户显示一个木马登录表单，要求他们向攻击者控制的服务器提交他们自己的证书。
如果由技巧熟练的攻击者实施，这种攻击还允许用户无缝登录到真正的应用程序中，以便他们不会发觉访问过程中的任何反常情况。

XSS 防御措施

输入验证

如果应用程序在某个位置收到的用户提交的数据将来有可能被复制到它的响应中，应用程序应根据这种情形对这些数据执行尽可能严格的确认。

1. 数据不是太长
2. 数据仅包含某组合法字符
3. 数据与一个特殊的正规表达式相匹配
4. 根据应用程序希望在每个字段中收到的数据类型，应尽可能限制性地对姓名、电子邮件地址、账号等应用不同的确认规则

输出编码

如果应用程序将某位用户或第三方提交的数据复制到它的响应中，那么应用程序应对这些数据进行HTML编码，以净化可能的恶意字符。

HTML编码指用对应的HTML实体替代字面量字符。这样做可确保浏览器安全处理可能为恶意的字符，把它们当作HTML文档的内容而非结构处理。
应用程序之所以结合使用输入确认与输出净化，原因在于这种方法能够提供两层防御:如果其中一层被攻破，另一层还能提供一些保护。

结合这两种技巧，应用程序就能够获得额外的保护，即使攻击者发现其中一种过滤存在缺陷，另一种过滤仍然能够阻止他实施攻击。
在这两种防御中，输出确认最为重要，必不可少。实施严格的输入确认应被视为一种次要故障恢复。

七、CSRF 攻击原理

CSRF(Cross-site Request Forgery，跨站请求伪造，也被称为“one click attack”或者session riding，通常缩写为CSRF 或者XSRF，是一种对网站的恶意利用

CSRF(Cross-site Request Forgery，跨站请求伪造，也被称为“one click attack”或者session riding，通常缩写为CSRF 或者XSRF，是一种对网站的恶意利用，
尽管听起来像跨站脚本(XSS)，但它与XSS 非常不同，并且攻击方式几乎相左。

XSS 利用站点内的信任用户(受害者)而CSRF 通过伪装来自受信任用户的请求来利用受信任的网站。

通过社会工程学的手段(如通过电子邮件发送一个链接)来蛊惑受害者进行一些敏感性的操作，如修改密码、修改E-mail、转账等，而受害者还不知道他已经中招，

CSRF 攻击危害

1. CSRF 的破坏力依赖于受害者的权限
2. 如果受害者只是个普通的用户，则一个成功的CSRF攻击会危害用户的数据以及一些功能。
3. 如果受害者具有管理员权限，则一个成功的CSRF 攻击甚至会威胁到整个网站的安全。
4. 与XSS 攻击相比，CSRF 攻击往往不太流行(因此对其进行防范的资源也相当稀少)和难以防范。
5. 故被认为比XSS 更具危险性，所以CSRF 在业内有个响当当的名字–沉睡的巨人。

总结

提示：写的有些乱，研究不深入，有时间再改