「网络安全」面试常见的 web 网络安全知识整理
时间：2022-11-17 18:30:00
文章目录
- 一、XSRF 攻击
-
-
-
- 1、输入 cookie samesite 选项
- 2、httpOnly
- 3、使用Token(主流)
-
-
- 二、XSS 攻击
-
- XSS攻击的危害
- 原因解析
- XSS 攻击分类
-
-
- (1). 反射性XSS攻击 (非持久性XSS攻击)
- (2). 持久性XSS攻击 (留言板场景)
- (3). 基于 Flash 的跨站 XSS
- (4). 未经验证的跳转 XSS
- **修复漏洞政策**
-
- 三、SQL 注入
-
-
-
- (1). SQL注入攻击的总体思路
- (2). SQL注入攻击实例
- (3). 应对方法
-
-
- 四、DDos 攻击
-
-
-
- DDos 预防 **( 除非不使用，否则没有完全治愈的方法。TCP )**
-
-
- 五、流量劫持
-
-
- DNS 劫持
- HTTP 劫持
-
- 点击劫持攻击
-
- 原理
- 点击劫持防御
-
-
- **1、framebusting**
- **2. X-Frame-Options**
- 3、Sandbox 特性
-
一、XSRF 攻击
想象一下，你登录了 bank.com 网站。此时：您有网站的身份验证 cookie。每次请求时，您的浏览器都会到 bank.com，为了识别你，并执行所有敏感的财务操作。
现在，当你在另一个窗口浏览网页时，你不小心访问了另一个网站 evil.com。该网站有向 bank.com 该网站提交了具有开始与黑客账户交易字段的表格 的 JavaScript 代码。
你每次访问 bank.com 时，浏览器都会发送 cookie，即使表单是从 evil.com 提交。因此，银行会识别你的身份并实施真实付款。
这是跨网站要求伪造伪造（Cross-Site Request Forgery，简称 XSRF）”攻击。
当然，实际银行会防止这种情况。一切都是由 bank.com 生成的表单有一个特殊的字段，即所谓的 “XSRF 保护 token恶意页面既不能生成，也不能从远程页面提取（它可以在那里提交表格，但不能获取数据）。而且，网站 bank.com 收到的每个表单都会这样做 token 的检查。
然而，实现这种保护需要时间：我们需要确保每个表单都有 token 还必须检查所有请求。
1、输入 cookie samesite 选项
Cookie 的 samesite 选项提供了另一种防止此类攻击的方式，（理论上）不需要要求 “XSRF 保护 token”。
它有两个可能的值：
samesite=strict(和没有价值samesite一样)
如果用户来自同一个网站，则设置它 samesite=strict 的 cookie 永远不会被发送。
换句话说，无论用户是通过邮件链接还是从 evil.com 从其他域下提交表格或进行任何操作，cookie 不会发送。
若身份验证 cookie 具有 samesite 选项，那么 XSRF 攻击没有成功的机会，因为它来自 evil.com 的提交没有 cookie。因此，bank.com 将无法识别用户，也不会继续付款。
这种保护相当可靠。 bank.com 只发送操作 samesite cookie，例如来自 bank.com 提交另一页的表格。
虽然，这样有一些不方便。
当用户通过合法链接访问时 bank.com 例如，他们会对自己的笔记感到惊讶，bank.com 他们的身份无法识别。事实上，在这种情况下不会发送 samesite=strict cookie。
我们可以用两个 cookie 解决这个问题：一个 cookie 仅用于一般识别 “Hello, John另一个带 samesite=strict 的 cookie 用于数据更改。这样，来自网站外的用户就会看到欢迎信息，但支付操作必须从银行网站开始，这是第二个 cookie 只能发送。
samesite=lax
一种更容易防止的方法 XSRF 不会破坏用户体验的攻击。
宽松（lax）模式，和 strict 类似的模式，当从外部到网站时，禁止浏览器发送 cookie，但是增加了一个例外。
如果建立了以下两个条件，它们将被发送 samesite=lax 的 cookie：
-
HTTP 方法是安全(如 GET 而不是方法 POST）。
所有安全的 HTTP 方法详见 RFC7231 规范。基本上，这些都是用来读取而不是写入数据的方法。他们不能执行任何更改数据的操作。跟随链接总是 GET，这是一种安全的方法。
-
操作执行顶级导航(更改浏览器地址栏 URL）。
这通常是成立的，但如果导航是在一个