网安-入门总结
网络安全法
26条，27条，62条，63条，从事安全行业切记不能触碰灰色产业，不要被金钱迷失心智
安全观念
web安全简史
-
早期阶段（2002年前）： 黑客主要攻击系统软件，追求获取系统最高权限（root）。经典漏洞和exploit大量涌现。
-
防火墙技术的兴起： 防火墙和ACL技术的发展改变了互联网安全格局，保护了直接暴露在互联网上的系统。网络运营商和企业防火墙的共同作用减少了非Web服务的暴露。
-
2003年冲击波蠕虫事件： 对Windows RPC服务的蠕虫攻击引起全球关注，加强了对互联网安全的重视。网络运营商采取措施屏蔽某些端口连接请求。
-
Web攻击技术的兴起： 随着Web成为主流服务，黑客目光转移到Web上。不同阶段关注的焦点包括服务端动态脚本的安全、SQL注入、XSS攻击等。
-
Web2.0时代： 随着Web应用变得更复杂，涌现出大量企业级应用标准和框架。攻击形式变得更为多样化，涉及服务端、客户端、浏览器和用户。
-
移动互联网和云计算的发展： 移动安全和云安全等分支催生，与Web安全交叉。HTML5的迅速引爆、云计算的普及以及浏览器标准的推动都对Web安全技术提出了新的挑战。
安全本质
安全问题的本质是信任的问题
安全建立在信任的基础上，安全方案依赖于对一些基本假设的信任。安全领域划分出不同信任级别的域，通过信任边界进行安全检查。
安全是一个概率问题
安全的本质涉及概率，需要在成本和攻击概率之间取得平衡。良好的安全方案在有限的时空范围内对有限威胁给出一个遭受攻击的概率断言，需要灵活应对不同条件。
没有绝对的安全
安全是持续对抗的过程，攻击和防御技术不断发展。没有银弹，安全方案需要不断升级和演进，持续适应新的威胁。
安全的三要素 (CIA)
机密性、完整性和可用性是安全的基本组成元素。机密性要求数据内容不泄露，完整性要求数据没有被篡改，可用性要求资源是“随需而得”的。
态势感知
随着云计算、大数据和人工智能技术的进步，数据成为安全的核心。态势感知是全面、快速、准确地感知敌我双方态势，通过数字化技术对数据进行实时研判，实施有针对性的有效防御。
威胁情报和攻击矩阵：威胁情报是从各种源数据中提取的有关攻击者、攻击方式等信息，有助于实时感知态势。攻击矩阵框架将攻击过程结构化，帮助数字化分析攻击行为。
自适应智能化控制系统：安全系统逐渐向自适应的智能化控制系统演进，通过数字化安全系统实现自动化控制。自适应的系统表现出类似于人体免疫系统的能力，可以自动适应和应对新的威胁。
HTTP和Web应用
HTTP协议
HTTP的全称是Hypertext transfer protocol，他是构建web应用的基础，虽然开发web应用大部分时候都不用关心http协议细节，但是如果未能正确的使用该协议，可能会带来安全隐患。HTTP协议设计的内容非常多，西面将简单介绍HTTP协议中和安全有关的知识。
HTTP协议简介
HTTP协议是一种Client-Server协议，所以只能由客户端单向发起请求，服务端再响应请求。这里的客户端也叫用户代理（User Agent)，在大多数情景下是一个浏览器
HTTP请求
http通信由请求和响应组成，一个HTTP请求的数据包如下所示。（抓包演示）
http请求方法
http方法用于指定请求的操作系统，标准的方法如下所示
| 方法 | 用途 |
|---|---|
| OPTIONS | 用于客户端向服务端询问是否支持特定的选项 |
| GET | 向服务端获取URI指定的资源 |
| HEAD | 和GET方法类似，但是服务端不返回实际内容 |
| POST | 向服务端提交数据 |
| PUT | 向指定的URL存储文件 |
| DELETE | 删除URI指定的服务器上的文件 |
| TRACE | 让服务器回显请求中的内容 |
| CONNECT | 用户在HTTP协议中建立代理隧道 |
Web应用中的绝大部分请求使用的是GET和POST方法，通过XMLHttpRequest 可以发送HEAD、PUT、DELETE 方法的请求。在部分场景下，浏览器会发送OPTIONS 请求，用于预检。CONNECT 请求一般用于HTTP 隧道代理场景。
虽然 Web 应用中的一项功能，使用不同的HTTP方法都能实现，但出于安全考虑，我们要遵循如下基本原则:
(1)GET和HEAD方法应当只用于对服务端没有副作用的操作，即对服务端是“只读”的操作，它们被称为安全的方法。如果该操作对服务端会有副作用，比如增加、删除、更改数据,则应该使用别的 HTTP 方法。考虑到安全性，对于 GET 请求，浏览器在刷新页面时不会要求用户确认，而对于有副作用的 POST 请求，在刷新页面时浏览器会询问用户是否要重新发送，避免在服务端产生多余的操作，比如重复交易、重复下单等。
HEAD方法与GET方法的行为很类似， 但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下， 对资源的首部进行检查。使用HEAD, 可以： • 在不获取资源的情况下了解资源的情况（比如， 判断其类型） • 通过查看响应中的状态码， 看看某个对象是否存在， • 通过查看首部， 测试资源是否被修改了。 服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范， 就必须实现HEAD方法。
(2)PUT和 DELETE 方法一般用于直接上传和删除文件，大部分 Web 应用不会用到，如果这两种方法被攻击者利用，危害会非常大。因此如无业务需求，应当禁用这些方法。与GET从服务器读取文档相反，PUT方法会向服务器写入文档。有些发布系统允许用户创建Web页面， 并用PUT直接将其安装到Web服务器上去。
(3)在 Web 应用中，尽量通过 POST 方法提交敏感数据，而不是通过GET 方法提交。POST方法起初是用来向服务器输入数据的。实际上， 通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器， 然后由服务器将其发送到它要去的地方（比如， 送到一个服务器网关程序中， 然后由这个程序对其进行处理）。
(4)在服务端获取请求参数时，应当明确指明是从GET参数还是 POST参数中获取，否则攻击者可将原本设计为用POST方法提交的操作改用GET方法提交，以绕过某些只针对POST请求设计的安全策略(如全局 CSRF 防御方案，我们将在第7 章详细介绍)。例如，在 PHP中尽量不要从$REQUEST中获取请求参数，而是明确指定从$ GET 或者$_POST中获取。
(5)TRACE 方法通常用于诊断调试，服务端直接返回请求中的内容，在 XSS 攻击中可用它绕过 Cookie的HttpOnly 策略,通过 JavaScript代码读取带有 HttpOnly 属性的 Cookie内容生产环境的服务器应当禁用TRACE方法。
客户端发起一个请求时， 这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP 请求。TRACE方法允许客户端在最终将请求发送给服务器时， 看看它变成了什么样子。TRACE请求会在目的服务器端发起一个“环回” 诊断。行程最后一站的服务器会弹回一条TRACE响应， 并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求响应链上， 原始报文如何被毁坏或修改过。
TRACE方法主要用于诊断，也就是说， 用于验证请求是否如愿穿过了请求——响应链。它也是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生效果。
尽管TRACE可以很方便地用于诊断， 但它确实也有缺点， 它假定中间应用程序对各种不同类型请求（ 不同的方法–GET、HEAD、POST等） 的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情一比如， 代理可能会将POST请求直接发送给服务器， 而将GET请求发送给另一个HITP应用程序（比如Web缓存）。TRACE并不提供区分这些方法的机制。通常， 中间应用程序会自行决定对TRACE请求的处理方式。TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。
(6)HEAD方法和GET 方法所消耗的服务端计算资源是一样的，只是服务端对 HEAD请求的响应不会包含正文，所以网络出方向的带宽消耗不一样。在 DDoS 攻击中，攻击者可能使用HEAD方法发起攻击，让服务器的网络出方向带宽不超过告警阙值，对服务器实施应用层的DDoS攻击，耗尽服务器的计算资源。
(7)CONNECT方法用于在客户端和目标地址之间建立一个 TCP 隧道，这个时候 Web 服务器充当代理服务器，只有初始请求用的是 HTTP 协议，后续的所有双向流量都是在 TCP 连接上传输的。所以当 Web 服务器支持 CONNECT方法时，可用于建立从外网穿透到内网的传输隧道。
URI的全称是Uniform Resource Identifier,客户用其标识该HTTP请求要作用到服务器上的资源路径，URI再加上HOST头才是一个完整的互联网路径，即HOST+URI。但是当浏览器使用了正向代理时，这个URI就是完整的目标URL。
现代浏览器发出的HTTP 请求，其 HTTP 版本号主要是 1.1和2，更低的HTTP版本多见于API调用，因为部分应用的底层 HTTP 库还未升级。更高版本的 HTTP/3虽然已经正式发布但目前支持它的网站不多。
HTTP/1.1比HTTP/1.0 多了一些新特性。HTTP/1.1支持持久连接 (Keep-Alive)，即允许复用一个TCP 连接完成多个HTTP 请求。HTTP/1.1还支持管线化 (Pipelining)，即在一个TCP连接中客户端无须等待前一个请求的响应，就可以发送下一个请求，服务端只需要按照请求的顺序逐一响应即可。这个特性提升了 Web 应用的网络性能，但是在 HTTP Flood攻击中，攻击者利用这个特性能大幅提升攻击效率一一只需要建立少数的 TCP 连接，无须等待服务器响应就能在短时间内连续发送大量HTTP请求。
host头
HTTP/1.1 在请求中新增了 HOST 头用于虚拟主机的场景，即当一个IP 地址上运行了多个网站时，Web 服务器通过 HOST 头中的域名即可判断要访问的目标网站是哪一个。在一些虚拟主机配置错误的服务器上，如果一个 Web 应用使用任意 HOST 头都能正常访问，而且 Web 应用中又没有明确配置网站的域名，而是获取 HOST 头作为网站域名时，那么该应用就可能获取一个错误的域名。当攻击者通过恶意构造的 HOST 头访问时，如果应用内部需要获取网站域名用于关键业务逻辑，比如向该域名的网站发送敏感信息，就会将敏感信息发送给恶意域名。如果HOST 头的域名会出现在缓存页面中(比如 Web 应用中使用了编译型模板，并且其中的某些URL 是通过这个 HOST 头拼接生成的)，攻击者使用恶意构造的 HOST 头访问这个网站，可能导致其他用户访问受污染的页面。
user-agent头
HTTP 请求中的 User-Agent 头用来指示当前访问者的客户端类型，它的值是客户端指定的,黑客工具通常会伪装成一个正常浏览器的 User-Agent，所以在 Web 应用中不能基于User-Agent的值来做关键业务逻辑决策。甚至 User-Agent 头中也可能包含恶意内容，例如攻击者可能向其中插入XSS Payload，以便对后端的日志分析平台实现XSS 盲打。
referer头
Referer 头指示了当前请求是从哪个URL页面发起的,在旧版本的Flash 中这个值可以伪造但是在现代浏览器中不能通过 JavaScript 伪造这个头，所以有些安全防御方案会用这个头校验请求来源。在 JavaScript 中可以通过 window.history 对象的 pushState 和 replaceState 方法修改兰前窗口的历史记录,但是仅能够将其修改为与当前URL同源。所以依赖 Referer 中的域名做来源校验还是可靠的，但只能信任其域名，而不能信任 URL 级别的内容。
此外，当网页跳转到其他站点，或者加载其他站点资源时，会将当前 URL 作为 Referer传递给其他站点，所以URL 中一般不要包含敏感信息，以免信息泄露。
浏览器发送的 HTTP头的格式都是很标准的，而攻击者编写的自动化攻击程序通常是手丁构造的 HTTP 头，与标准的 HTTP 头在某些方面可能会有细微差异，如空格、标点符号、头的个数等。通过这些细微差异，我们可识别出异常的访问者并进行处置。另外，使用不同浏览器访问同一个页面时，HTTP 头的个数和顺序也会有差异，甚至同一个浏览器在访问不同类型的资源时，或者在不同的场景中发出的请求，也会有差异 (参见图 2-4)。这些细微的差异被安全产品用于鉴别访问者是不是真实用户。例如请求中的 User-Agent 宣称自己是 Firefox 浏览器而实际的HTTP头不符合 Firefox 浏览器的特征，那么访问者可能篡改了 User-Agent，或者它其实是个自动化程序
http请求方法最重要（get，post）
get：向服务端获取URI指定的资源
post：向服务端提交数据
两种方法都可以提交数据，但是也有区别：
1.使用get方法提交数据后，主题内容会在url中显示
2.使用post方法提交数据不会再url中显示
提交数据最好使用post方法
HTTP响应
HTTP 响应是与请求一一对应的，服务端将请求的操作结果通过 HTTP 响应返回给客户端。
响应中的版本号不一定要与请求中的版本号一样，但是其大版本号(Major Version)不能高于请求中的大版本号，例如请求是 HTTP/1.0 版本的，服务端响应不能为 HTTP/2 版本，但可以为HTTP/1.1版本。
状态码
状态码用于指示服务器对于该请求的操作结果。在标准定义中，状态码按照区段分为 5大类
| 状态码 | 说明 |
|---|---|
| 100-199 | 表示已收到请求，但未完成操作，用于通知客户端 |
| 200-299 | 请求中的操作已成功完成 |
| 300-399 | 告知客户端执行额外的操作，通常用于跳转 |
| 400-499 | 客户端请求有错误 |
| 500-599 | 服务端出错 |
状态码的不规范使用是非常普遍的现象。在有些网站中，不管是正常响应、页面未找到，还是服务端出错，全部都响应 200 状态码，还有很多API被设计为全部响应 200状态码，然后通过响应正文JSON 中的某个字段，来标识请求是成功还是出错。这些设计相当于把 HTTP协议当作传输层协议来使用，而把 HTTP 协议本身包含的很强的语义信息全部丢掉了。从非安全的角度看，不规范地使用状态码对 SEO 非常不利，搜索引擎并不能理解“页面未找到”等字眼而会将状态码为 200 的页面全部收录进来。
从安全的角度看，在利用访问日志做安全分析时，状态码非常有价值，例如一个访问者在短时间内产生大量的 404 响应，很可能是有攻击者在做网站扫描探测;某个页面有大量的 500 响应，可能意味着程序存在 Bug，甚至是代码存在 SQL注入漏洞，正在被黑客攻击。通过统计和分析 HTTP 响应的状态码，对这类情况就能实现简单的安全监测。
HTTP 的响应头是通过“\r\n”分割的，如果请求中的数据会出现在响应头中，当这些数据未经服务端严格过滤时，可能产生 HTTP 消息头注入(有些文章里也叫 CRLF 注入)，即攻击者可以使用“\r\n”注入任意的 HTTP 头。
如果在受害者的响应中注入了 Location 头，可将受害者重定向到指定网站；注入 Set-Cookie 头，可以让受害者使用攻击者指定的 Cookie 值，如实施定会话攻击；在跨域资源共享(CORS)和内容安全策略(CSP)中注入特定的响应头，可以改变浏览器接收到的安全策略，以便攻击者实施其他的攻击行为。所以，如果用户输入的数据会出现在响应头中，需要对其进行严格的校验，或在输出时对回车和换行符进行编码。
Web服务器
Web 服务器通过HTTP/HTTPS 协议向访问者提供服务，它可以是一台服务器或者一个服务器集群。
Web 服务器提供的内容按照其存在的形式可以分为两类:静态资源和动态资源。静态资源是指服务器上已经存在的文件，当客户端访问时，Web 服务器直接将它返回给客户端，比如图片和视频文件，通常这类资源可以缓存。动态资源是指服务端需要经过计算才能生成的内容，比如查询结果，不同的用户或不同的时间获得的结果都不一样，这类资源一般不缓存。
我们平常访问 Web应用并不都是直接访问 Web 服务器的，中间可能经过了HTTP代理，其中可能有客户端指定的正向 HTTP 代理，也有网站使用的CDN、WAF、负载均衡等反向 HTTP代理，在使用不当时可能会带来安全隐患。
正向代理：一位企业老总，他有一位助理小李，当老总想要订火车票时，就会委托小李帮忙订票，当老总想要订酒店时，小李就会负责查找合适的酒店并安排老总入住。助理小李帮老总办了很多事情，也就是代理了一些事情，而助理小李就充当了一个代理服务器的角色。
反向代理：雷池waf
操作系统
操作系统(Operating System，OS)是配置在计算机硬件上的第一层软件，是对硬件系统的首次扩充。其主要作用是管理好这些设备，提高它们的利用率和系统的吞吐量，并为用户和应用程序提供一个简单的接口，便于用户使用。OS 是现代计算机系统中最基本和最重要的系统软件，而其它的诸如编译程序、数据库管理系统等系统软件，以及大量的应用软件，都直接依赖于操作系统的支持，取得它所提供的服务。事实上 OS 已成为现代计算机系统、多处理机系统、计算机网络中都必须配置的系统软件。
Vmware workstation
虚拟机概述
虚拟机是一种在物理计算机上创建并运行多个虚拟计算机的技术。在 Windows 平台上，常用的虚拟机平台包括 VMware Workstations、VMware Player、VirtualBox 和 Hyper-V 等。
VMware Workstations（寄居架构）
VMware Workstations 是一款收费的虚拟机软件，支持多种操作系统，可以在 Windows 系统上创建多个虚拟计算机，每个虚拟计算机都可以运行不同的操作系统和应用程序。
vmware sphere(原生架构)
hyper-v（微软）
虚拟机运行架构
1.寄居架构
2.原生架构
