网络知识详解之：网络攻击与安全防护

共计 24498 个字符，预计需要花费 62 分钟才能阅读完成。

计算机网络相关知识体系详解

• 网络知识详解之：TCP 连接原理详解
• 网络知识详解之：HTTP 协议基础
• 网络知识详解之：HTTPS 通信原理剖析（对称、非对称加密、数字签名、数字证书）
• 网络知识详解之：CA 证书制作实战（Nginx 数字证书实战）
• 网络知识详解之：网络攻击与安全防护

  文章目录

  • 网络知识详解之：网络攻击与安全防护
    • Session 攻击
      • 认证和授权
      • Session 与认证
      • 会话（Session）劫持
      • 会话固定（Session fixation）
      • Session 保持攻击
    • 注入攻击
      • SQL 注入(SQL Injection)
        • SQL 盲注
        • ORM 注入
      • XML 注入（XML injection）
      • 代码注入（Code injection）
      • OS 命令注入
    • 文件操作防护
      • 文件上传漏洞
      • 文件下载和目录浏览漏洞
    • 访问控制
      • 垂直权限（功能权限）
      • 水平权限（数据权限）
    • IP 黑白名单
      • DDOS 攻击
        • Syn_Flood 攻击原理
        • Syn_Flood 防御
      • CC 攻击
      • CC 防护
      • IP 黑白名单方式
      • 动态黑名单实现

OWASP（开放 Web 软体安全项目 - Open Web Application Security Project）是一个开源的、非盈利的全球性安全组织，致力于应用软件的安全研究。使命是使应用软件更加安全，使企业和组织能够对应用安全风险做出更清晰的决策

http://www.owasp.org.cn/

OWASP 在业界影响力：

• OWASP 被视为 web 应用安全领域的权威参考，美国联邦贸易委员会 (FTC) 强烈建议所有企业需遵循 OWASP 十大 WEB 弱点（十大漏洞）防护守则
• 国际信用卡数据安全技术 PCI 标准更将其列为必要组件
• 为美国国防信息系统局应用安全和开发清单参考
• 为欧洲网络与信息安全局 云计算风险评估参考
• 为美国联邦首席信息官理事会，联邦部门和机构使用社会媒体的安全指南
• 为美国国家安全局 / 中央安全局，可管理的网络计划提供参考
• 为英国 GovCERTUK 提供 SQL 注入参考
• 为欧洲网络与信息安全局，云计算风险评估提供参考
• OWASP TOP 10 为 IBM APPSCAN、HP WEBINSPECT 等扫描器漏洞参考的主要标准

OWASP Top 10：

Session 攻击

认证和授权

很多时候，人们会把“认证”和“授权”两个概念搞混，实际上“认证”和“授权”是两件事情，认证的英文是 Authentication，授权则是 Authorization。分清楚这两个概念其实很简单，只需要记住：认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。

形象地说，假设系统是一间屋子，持有钥匙的人可以开门进入屋子，那么屋子就是通过“锁和钥匙的匹配”来进行认证的，认证的过程就是开锁的过程。钥匙在认证过程中，被称为“凭证”（Credential）, 开门的过程，在互联网里对应的是登录（Login）。可是开门之后，什么事情能做，什么事情不能做，就是“授权”的管辖范围了。

如果进来的是屋子的主人，那么他可以坐在沙发上看电视，也可以进到卧室睡觉，可以做任何他想做的事情，因为他具有屋子的“最高权限”。

可如果进来的是客人，那么可能就仅仅被允许坐在沙发上看电视，而不允许其进入卧室了。

“能否进入卧室”这个权限被授予的前提，是需要识别出来者到底是主人还是客人，所以如何授权是取决于认证的。现在问题来了，持有钥匙的人，真的就是主人吗？如果主人把钥匙弄丢了，或者有人造了把一模一样的钥匙，那也能把门打开，进入到屋子里。

这些异常情况，就是因为认证出现了问题，系统的安全直接受到了威胁。钥匙仅仅是一个很脆弱的凭证，其他诸如指纹、虹膜、人脸、声音等生物特征也能够作为识别一个人的凭证。认证实际上就是一个验证凭证的过程。

如果只有一个凭证被用于认证，则称为“单因素认证”；如果有两个或多个凭证被用于认证，则称为“双因素（Two Factors）认证”或“多因素认证”。一般来说，多因素认证的强度要高于单因素认证，但是在用户体验上，多因素认证或多或少都会带来一些不方便的地方。

Session 与认证

密码与证书等认证手段，一般仅仅用于登录（Login）的过程。当登录完成后，用户访问网站的页面，不可能每次浏览器请求页面时都再使用密码认证一次。因此，当认证成功后，就需要替换一个对用户透明的凭证。这个凭证，就是 SessionID。

当用户登录完成后，在服务器端就会创建一个新的会话（Session），会话中会保存用户的状态和相关信息。 服务器端维护所有在线用户的 Session，此时的认证，只需要知道是哪个用户在浏览当前的页面即可。为了告诉服务器应该使用哪一个 Session, 浏览器需要把当前用户持有的 SessionID 告知服务器。最常见的做法就是把 SessionID 加密后保存在 Cookie 中，因为 Cookie 会随着 HTTP 请求头发送，且受到浏览器同源策略的保护。

Cookie 中保存的 SessionlD，SessionID 一旦在生命周期内被窃取，就等同于账户失窃。同时由于 SessionID 是用户登录之后才持有的认证凭证，因此黑客不需要再攻击登录过程（比如密码），在设计安全方案时需要意识到这一点。

会话（Session）劫持

会话劫持（Session hijacking）就是一种通过窃取用户 SessionID 后，使用该 SessionID 登录进目标账户的攻击方法，此时攻击者实际上是使用了目标账户的有效 Session。如果 SessionID 是保存在 Cookie 中的，则这种攻击可以称为 Cookie 劫持。

攻击步骤：

1. 目标用户需要先登录站点；
2. 登录成功后，该用户会得到站点提供的一个会话标识 SessionID；
3. 攻击者通过某种攻击手段捕获 Session ID；
4. 攻击者通过捕获到的 Session ID 访问站点即可获得目标用户合法会话。

攻击者获取 SessionID 的方式有多种：

1. 暴力破解：尝试各种 Session ID，直到破解为止；
2. 预测：如果 Session ID 使用非随机的方式产生，那么就有可能计算出来；
3. 窃取：使用网络嗅探、本地木马窃取、XSS 攻击等方法获得。

防御方法：

1、Cookie HttpOnly。通过设置 Cookie 的 HttpOnly 为 true，可以防止客户端脚本访问这个 Cookie，从而有效的防止 XSS 攻击。

response.setHeader("SETHEADER","user="+request.getParameter("cookie")+";HttpOnly");

• 1

SessionCookieConfig 接口，用于操作会话 Cookie，在 ServletContextListener 监听器初始化方法中进行设定即可

@WebListener
public class SessionCookieInitialization implements ServletContextListener {
	private static final Log log = LogFactory.getLog(SessionCookieInitialization.class);
		public void contextInitialized(ServletContextEvent sce) {
			ServletContext servletContext = sce.getServletContext();
			SessionCookieConfig sessionCookie = servletContext.getSessionCookieConfig();
		
			// 设置 HttpOnly
			sessionCookie.setHttpOnly(true);
		} 
		
		public void contextDestroyed(ServletContextEvent sce) {
		}
	}
}

 

Cookie Secure，是设置 COOKIE 时，可以设置的一个属性，设置了这个属性后，只有在 https 访问时，浏览器才会发送该 COOKIE。浏览器默认只要使用 http 请求一个站点，就会发送明文 cookie，如果网络中有监控，可能被截获。如果 web 应用网站全站是 https 的，可以设置 cookie 加上 Secure 属性，这样浏览器就只会在 https 访问时，发送 cookie。攻击者即使窃听网络，也无法获取用户明文 cookie。

response.setHeader("SETHEADER","user="+request.getParameter("cookie")+";HttpOnly;Secure");

• 1

或者

@WebListener
public class SessionCookieInitialization implements ServletContextListener {
	private static final Log log = LogFactory.getLog(SessionCookieInitialization.class);
	public void contextInitialized(ServletContextEvent sce) {
		ServletContext servletContext = sce.getServletContext();
		SessionCookieConfig sessionCookie = servletContext.getSessionCookieConfig();
		
		// 设置 HttpOnly
		sessionCookie.setHttpOnly(true);
		sessionCookie.setSecure(true);
	} 
	
	public void contextDestroyed(ServletContextEvent sce) {
	}
}

 

会话固定（Session fixation）

会话固定（Session fixation）是一种诱骗受害者使用攻击者指定的会话标识（SessionID）的攻击手段。 这是攻击者获取合法会话标识的最简单的方法。让合法用户使用黑客预先设置的 sessionID 进行登录，从而是 Web 不再进行生成新的 sessionID，从而导致黑客设置的 sessionId 变成了合法桥梁。

会话固定也可以看成是会话劫持的一种类型，原因是会话固定的攻击的主要目的同样是获得目标用户的合法会话，不过会话固定还可以是强迫受害者使用攻击者设定的一个有效会话，以此来获得用户的敏感信息。

什么是 Session Fixation 呢？举一个形象的例子，假设 A 有一辆汽车，A 把汽车卖给了 B，但是 A 并没有把所有的车钥匙交给 B, 还自己藏下了一把。这时候如果 B 没有给车换锁的话，A 仍然是可以用藏下的钥匙使用汽车的。这个没有换“锁”而导致的安全问题，就是 Session Fixation 问題。

攻击步骤

1. 攻击者通过某种手段重置目标用户的 SessionID，然后监听用户会话状态；
2. 目标用户携带攻击者设定的 Session ID 登录站点；
3. 攻击者通过 Session ID 获得合法会话
   

攻击者如何才能让目标用户使用这个 SessionID 呢？如果 SessionID 保存在 Cookie 中，比较难做到这一点。但若是 SessionID 保存在 URL 中，则攻击者只需要诱使目标用户打开这个 URL 即可。

防御方法：【多个方法结合使用】

1、每当用户登陆的时候就进行重置 sessionID

// 会话失效
session.invalidate();
// 会话重建
session=request.getSession(true);

 

2、sessionID 闲置过久时，进行重置 sessionID

3、禁用客户端访问 Cookie，设置 HttpOnly

Session 保持攻击

一般来说，Session 是有生命周期的，当用户长时间未活动后，或者用户点击退出后，服务器将销毁 Session。Session 如果一直未能失效，会导致什么问题呢？前面的章节提到 session 劫持攻击，是攻击者窃取了用户的 SessionID，从而能够登录进用户的账户。

但如果攻击者能一直持有一个有效的 Session（比如间隔性地刷新页面’以告诉服务器这个用户仍然在活动），而服务器对于活动的 Session 也一直不销毁的话，攻击者就能通过此有效 Session—直使用用户的账户，成为一个永久的‘后门。

但是 Cookie 有失效时间，Session 也可能会过期，攻击者能永久地持有这个 Session 吗？

一般的应用都会给 session 设置一个失效时间，当到达失效时间后，Session 将被销毁。但有一些系统，出于用户体验的考虑，只要这个用户还“活着”，就不会让这个用户的 Session 失效。从而攻击者可以通过不停地发起访问请求，让 Session 一直“活”下去

保持 session 长时间存活

<script>
	// 要保持 session 的 url
	var url = "http://bbs.yuanjing.com/wap/index.php?/sid=LOXSAJH4M";
	
	// 定时任务
	window.setInterval("keeyId()",6000);
	function keepsid(){
		document.getElementById("iframe1").src=url+"&time"+Math.random();
	}
	
</script>
<iframe id="iframe1" src=""/></iframe>

 

Cookie 永不过期

anehta.dom.persistCookie = function (cookieName){
    if(anehta.dom.checkCookie(cookieName)==false){
		return false;
	} 
	try{
		document.cookie = cookieName + "=" +
		anehta.dom.getCookie(cookieName)+";" + "expires=Thu, 01-Jan-2038 00:00:01 GMT;";
	} catch( e){
		return false;
	} 
	
	return true;
}

 

攻击者甚至可以为 Session Cookie 增加一个 Expire 时间，使得原本浏览器关闭就会失效的 Cookie 持久化地保存在本地，变成一个第三方 Cookie（third-party cookie）。

防护方案

常见的做法是在一定时间后，强制销毁 Session。这个时间可以是从用户登录的时间算起，设定一个阈值，比如 3 天后就强制 Session 过期。

但强制销毁 Session 可能会影响到一些正常的用户，还可以选择的方法是当用户客户端发生变化时，要求用户重新登录。比如用户的 IP、UserAgent 等信息发生了变化，就可以强制销毁当前的 Session，并要求用户重新登录。

最后，还需要考虑的是同一用户可以同时拥有几个有效 Session。若每个用户只允许拥有一个 Session，则攻击者想要一直保持一个 Session 也是不太可能的。当用户再次登录时，攻击者所保持的 Session 将被“踢出”。

注入攻击

注入攻击是 Web 安全领域中一种最为常见的攻击方式。XSS 本质上也是一种针对 HTML 的注入攻击。注入攻击的本质，是把用户输入的数据当做代码执行。这里有两个关键条件，第一个是用户能够控制输入；第二个是原本程序要执行的代码，拼接了用户输入的数据。解决注入攻击的核心思想：“数据与代码分离”原则。

SQL 注入(SQL Injection)

原因

在应用程序中若有下列状况，则可能应用程序正暴露在 SQL Injection 的高风险情况下

• 在应用程序中使用字符串联结方式或联合查询方式组合 SQL 指令。
• 在应用程序链接数据库时使用权限过大的账户（例如很多开发人员都喜欢用最高权限的系统管理员账户连接数据库）。
• 太过于信任用户所输入的资料，未限制输入的特殊字符，以及未对用户输入的资料做潜在指令的检查。

SQL 盲注

** 所谓“盲注”，就是在服务器没有错误回显时完成的注入攻击。** 服务器没有错误回显，对于攻击者来说缺少了非常重要的“调试信息”，所以攻击者必须找到一个方法来验证注入的 SQL 语句是否得到执行。

最常见的盲注验证方法是，构造简单的条件语句，根据返回页面是否发生变化，来判断 SQL 语句是否得到执行。比如在 DVWA 靶机平台，输入 1’and 1=1# 显示存在，输入 1’and 1=2# 显示不存在，由此可立即判断漏洞存在。

ORM 注入

Mybatis

1. Java 生态中很常用的持久层框架 Mybatis 就能很好的完成对 SQL 注入的预防，如下两个 mapper 文件，前者就可以预防，而后者不行。${ }：单纯替代，纯粹的将参数传进去，没有做任何的转义操作和预编译。

   <select id="selectByNameAndPassword"
   parameterType="java.util.Map" resultMap="BaseResultMap">
   select id, username, password, role
   from user
   where username = #{username,jdbcType=VARCHAR}
   and password = #{password,jdbcType=VARCHAR}
   </select>
   
   <select id="selectByNameAndPassword"
   parameterType="java.util.Map" resultMap="BaseResultMap">
   select id, username, password, role
   from user
   where username = ${username,jdbcType=VARCHAR}
   and password = ${password,jdbcType=VARCHAR}
   </select>
   

   使用 #{}语法，Mybatis 会通过预编译机制生成 PreparedStatement 参数，然后在安全的给参数进行赋值操作

   <select id="getPerson" parameterType="string"
   resultType="org.application.vo.Person">
   SELECT * FROM PERSON WHERE NAME = #{name} AND PHONE LIKE
   '${phone}';
   </select>
   

   首先，这是一种不全的用法，注意上面的参数修符号 $phone，使用${} 参数占位修饰符，MyBatis 不会对字符串做任何修改，而是直接插入到 SQL 语句中。

   建议使用参数绑定

   named parameter

   usernameString// 前台输入的用户名
   passwordString// 前台输入的密码
   
   //hql 语句
   String queryString = "from User t where t.username：usernameString and t.password: passwordString";
   
   // 执行查询
   List result = session.createQuery(queryString)
   					 .setString("usernameString", usernameString )
   					 .setString("passwordString", passwordString)
   					 .list();
   
   positional parameter

   usernameString// 前台输入的用户名
   passwordString// 前台输入的密码
   
   //hql 语句
   String queryString = "from User t where t.username=? and t.password=?";
   
   // 执行查询
   List result = session.createQuery(queryString)
   					 .setString(0, usernameString )
   					 .setString(1, passwordString)
   				     .list();
   

JDBC

Connection conn = DriverManager.getConnection(url,user,password);
String sql = "select * from product where name like'%" +
request.getParameter("pname")+"%''" ;
Statement statement = conn.createStatement();
ResultSet rs = stat.executeQuery(sql);

解决方案

使用预处理执行 SQL 语句，对所有传入 SQL 语句中的变量做绑定，这样用户拼接进来的变量无论内容是什么，都会被当做替代符号“？”所替代的值，数据库也不会把恶意用户拼接进来的数据，当做部分 SQL 语句去解析。

无论使用了哪个 ORM 框架，都会支持用户自定义拼接语句，经常有人误解 Hibernate，其实 Hibernate 也支持用户执行 JDBC 查询，并且支持用户把变量拼接到 SQL 语句中。

XML 注入（XML injection）

XML 注入是将用户录入的信息作为 XML 节点。

除了 SQL 注入外，在 Web 安全领域还有其他的注入攻击，这些注入攻击都有相同的特点，就是应用违背了“数据与代码分离”原则。

和 SQL 注入原理一样，XML 是存储数据的地方，如果在查询或修改时，如果没有做转义，直接输入或输出数据，都将导致 XML 注入漏洞。攻击者可以修改 XML 数据格式，增加新的 XML 节点，对数据处理流程产生影响。如果用户构造了恶意输入数据，就有可能形成注入攻击。

//userData 是准备保存的 XML 数据，接受了 name 和 email 两个用户提交的数据

String userData = "<USER >"+
				  "<name>"+
				  request.getParameter("name")+
				  "</name>"+
				  "<email>"+
				  request.getParameter("email")+
				  "</email>"
				  "</USER>"

// 保存 XML 数据
userDao.save(userData);

 

比如用户输入的数据如下

user1
[email protected]</email></USER><USER><name>user2</name>
<email>[email protected]

 

最终生成的 XML 文件里被插入一条数据

<USER>
<name>user1</name>
<email>[email protected]</email>
</USER>

<USER>
<name>user2</name>
<email>[email protected]</email>
</USER>

 

XML 注入，也需要满足注入攻击的两大条件

用户能控制数据的输入；

程序直接拼凑了数据。

在修补方案上，与 HTML 注入的修补方案也是类似的，在 XML 保存和展示前，对数据部分，单独做 XML escape，如下所示

String userData = "<USER>"+
				  "<name>"+StringUtil.xmlEncode(request.getParameter("name"))+"</name>"+
				  "<email>"+StringUtil.xmlEncode(request.getParameter("email"))+
				   "</email>"+
				   "</USER>";

 

转义规则

lt - <
gt - >
amp - &
apos - \'quot -"

代码注入（Code injection）

Code injection，代码注入攻击。web 应用代码中，允许接收用户输入一段代码，之后在 web 应用服务器上执行这段代码，并返回给用户。由于用户可以自定义输入一段代码，在服务器上执行，所以恶意用户可以写一个远程控制木马，直接获取服务器控制权限，所有服务器上的资源都会被恶意用户获取和修改，甚至可以直接控制数据库。代码注入比较特别一点。

代码注入往往是由一些不安全的函数或者方法引起的，其中的典型代表就是 eval（）

public static void main(String[] args) {
	// 在 Java 中也可以实施代码注入，比如利用 Java 的脚本引擎。
	ScriptEngineManager manager = new ScriptEngineManager();
	
	// 获得 JS 引擎对象
	ScriptEngine engine = manager.getEngineByName("JavaScript");
	try {
		// 用户录入
		String param = "hello";
		String command = "print('"+param+"')";
		
		// 调用 JS 中的 eval 方法
		engine.eval(command);
	} catch (ScriptException e) {
		e.printStackTrace();
	}
}

参数 param 的值由用户指定并传入，攻击者可以提交如下数据

hello'); var fImport = new JavaImporter(java.io.File);
with(fImport) {var f = new File('new'); f.createNewFile();}

 

解决方案

对抗代码注入，需要禁止使用 eval（）等可以执行命令的函数，如果一定要使用这些函数，则需要对用户的输入数据进行处理。比如：执行代码的参数，或文件名，禁止和用户输入相关，只能由开发人员定义代码内容，用户只能提交“1、2、3”参数，代表相应代码。

代码注入往往是由于不安全的编程习惯所造成的，危险函数应该尽量避免在开发中使用，可以在开发规范中明确指出哪些函数是禁止使用的。

OS 命令注入

OS 命令注入（Operating System Command injection 操作系统命令注入或简称命令注入）是一种注入漏洞。攻击者注入的有效负载将作为操作系统命令执行。仅当 Web 应用程序代码包括操作系统调用并且调用中使用了用户输入时，才可能进行 OS 命令注入攻击。

当您确定了 OS 命令注入漏洞后，通常可以执行一些初始命令来获取有关受到破坏的系统的信息。以下是在 Linux 和 Windows 平台上有用的一些命令的摘要

比如应用程序的开发人员希望用户能够在 Web 应用程序中查看 Windows ping 命令的输出。用户需要输入 IP 地址，然后应用程序将 ICMP ping 发送到该地址。不幸的是，开发人员过分信任用户，并且不执行输入验证。使用该 GET 方法传递 IP 地址，然后在命令行中使用。

DVWA – Command Execution

1. 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.013 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.011 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time
2000ms
rtt min/avg/max/mdev = 0.011/0.012/0.013/0.000 ms

2.127.0.0.1 && whoami

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.011 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time
1998ms
rtt min/avg/max/mdev = 0.011/0.018/0.029/0.008 ms
www-data

3.127.0.0.1 && ps -ef

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.012 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.019 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.013 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time
1998ms
rtt min/avg/max/mdev = 0.012/0.014/0.019/0.005 ms
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Nov15 ? 00:00:00 /sbin/init
root 2 0 0 Nov15 ? 00:00:00 [kthreadd]
root 3 2 0 Nov15 ? 00:00:00 [migration/0]
root 4 2 0 Nov15 ? 00:00:00 [ksoftirqd/0]
root 5 2 0 Nov15 ? 00:00:00 [watchdog/0]
root 6 2 0 Nov15 ? 00:00:32 [events/0]
root 7 2 0 Nov15 ? 00:00:00 [cpuset]
root 8 2 0 Nov15 ? 00:00:00 [khelper]
root 9 2 0 Nov15 ? 00:00:00 [netns]

防护方案

到目前为止，防止 OS 命令注入漏洞的最有效方法是永远不要从应用程序层代码中调用 OS 命令。几乎在每种情况下，都有使用更安全的平台 API 来实现所需功能的替代方法。如果认为无法通过用户提供的输入调出 OS 命令，则必须执行强大的输入验证。有效验证的一些示例包括

• 根据允许值的白名单进行验证。
• 验证输入是否为数字。
• 验证输入仅包含字母数字字符，不包含其他语法或空格。

文件操作防护

文件上传漏洞

在互联网中，我们经常用到文件上传功能，比如上传一张自定义的图片；分享一段视频或者照片；论坛发帖时附带一个附件；在发送邮件时附带附件，等等。

文件上传功能本身是一个正常业务需求，对于网站来说，很多时候也确实需要用户将文件上传到服务器。所以“文件上传”本身没有问题，但有问题的是文件上传后，服务器怎么处理、解释文件。如果服务器的处理逻辑做的不够安全，则会导致严重的后果。

文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。这种攻击方式是最为直接和有效的，有时候几乎没有什么技术门槛。

文件上传后导致的常见安全问题一般有：

• 上传文件是 Web 脚本语言，服务器的 Web 容器解释并执行了用户上传的脚本，导致代码执行；
• 上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行；
• 上传文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。

在大多数情况下，文件上传漏洞一般都是指“上传 Web 脚本能够被服务器解析”的问题，也就是通常所说的 web shell 的问题。要完成这个攻击，要满足如下几个条件

• 首先，上传的文件能够被 Web 容器解释执行。所以文件上传后所在的目录要是 Web 容器所覆盖到的路径。
• 其次，用户能够从 Web 上访问这个文件。如果文件上传了，但用户无法通过 Web 访问，或者无法使得 Web 容器解释这个脚本，那么不能称之为漏洞。
• 最后，用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容，则也可能导致攻击不成功。

解决方案

处理用户上传文件，要做以下检查：

1、检查上传文件扩展名白名单，不属于白名单内，不允许上传。

2、上传文件的目录必须是 http 请求无法直接访问到的。如果需要访问的，必须上传到其他（和 web 服务器不同的）域名下，并设置该目录为不可执行目录。

3、上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。

4、图片上传，要通过处理（缩略图、水印等），无异常后才能保存到服务器。

5、上传文件需要做日志记录。

文件下载和目录浏览漏洞

是属于程序设计和编码上的不严谨导致的，良好的设计应该是：不允许用户提交任意文件路径进行下载，而是用户单击下载按钮默认传递 ID 到后台程序。

文件下载和目录浏览漏洞：File download and Directory traversal，任意文件下载攻击和目录遍历攻击。

处理用户请求下载文件时，允许用户提交任意文件路径，并把服务器上对应的文件直接发送给用户，这将造成任意文件下载威胁。如果让用户提交文件目录地址，就把目录下的文件列表发给用户，会造成目录遍历安全威胁。

恶意用户会变换目录或文件地址，下载服务器上的敏感文件、数据库链接配置文件、网站源代码等。

处理用户请求的代码：

String path = request.getParameter("path");
OutputStream os = response.getOutputStream();
FileInputStream fis = new FileInputStream(path);

byte[] buff = new byte[1024];
int i=0;
while((i=fis.read(buff))>0){
	os.write(buff,0,i);
} 

fis.close();
os.flush();
os.close();
防护方案

1、要下载的文件地址保存至数据库中。

2、文件路径保存至数据库，让用户提交文件对应 ID 下载文件。

3、下载文件之前做权限判断。

4、文件放在 web 无法直接访问的目录下。

5、记录文件下载日志。

6、不允许提供目录遍历服务。

Nginx 中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑 nginx.conf 文件，删除如下两行：

autoindex on;

autoindex_exact_size on;

然后重启 Nginx。

访问控制

“权限”一词在安全领域出现的频率很高。“权限”实际上是一种“能力”。对于权限的合理分配，一直是安全设计中的核心问题。但“权限”一词的中文含义过于广泛，因此本节中将使用“访问控制”代替。在互联网安全领域，尤其是 Web 安全领域中，“权限控制”的问题都可以归结为“访问控制”的问题，这种描述也更精确一些。

在 Linux 的文件系统中，将权限分成了“读”、“写”、“执行”三种能力。用户可能对某个文件拥有“读”的权限，但却没有“写”的权限。

在 Web 应用中，根据访问客体的不同，常见的访问控制可以分为“基于 URL 的访问控制”和“基于数据的访问控制”。

一般来说，“基于 URL 的访问控制”是最常见的。要实现一个简单的“基于 URL 的访问控制”，在基于 Java 的 Web 应用中，可以通过增加一个 filter 实现。

// 获取访问功能
String url = request.getRequestPath();
// 进行权限校验
User user = request.getSession.get("user");
// 校验该用户是否有权限访问目标 url
boolean permit = PrivilegeManager.permit(user,url);
if(permit){
	chain.doFilter(request,response);
}else{
	// 未授权提示
}

垂直权限（功能权限）

基于 URL 的访问控制的漏洞和防护。

访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是“基于角色的访问控制（Role-Based Access Control）”，简称 RBAC，最终的表现形式就是某一个用户可以访问哪些 URL。

RBAC 事先会在系统中定义出不同的角色，不同的角色拥有不同的权限，一个角色实际上就是一个权限的集合。而系统的所有用户都会被分配到不同的角色中，一个用户可能拥有多个角色，角色之间有高低之分（权限高低）。在系统验证权限时，只需要验证用户所属的角色，然后就可以根据该角色所拥有的权限进行授权了

例如: 在一个论坛中，有 admin、普通用户、匿名用户三种角色，admin 有删除、编辑、置顶帖子的权限，普通用户有评论和浏览帖子的权限，匿名用户只有浏览帖子的权限。目前已有 Shiro，Spring Security 等基于 RBAC 模型的成熟框架来处理功能权限管理和鉴权的问题。

垂直权限又称为功能权限

垂直权限的漏洞举例：

Web 应用程序在服务端没有做权限控制，只是在前端菜单显示上将部分页面隐藏了。此时，恶意用户可以猜测其他管理页面的 URL，就可以访问或控制其他角色拥有的数据或页面，达到越权操作的目的，可能会使得普通用户拥有了管理员的权限。

垂直权限漏洞是指 Web 应用没有做权限控制，或仅仅在菜单上做了权限控制，导致恶意用户只要猜到了其他页面的 URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

解决方案：

针对任何 URL，每次用户访问时，都要判定该用户是否有访问此 URL 的权限。推荐使用成熟的权限解决方案框架，比如 Spring Security。

水平权限（数据权限）

基于数据的访问控制

同一部门下的用户张三和李四都有访问 线索管理 的权限，但是张三只能操作张三线索，李四只能操作李四的线索。

用户 A 和用户 B 可能同属于一个角色 RoleX，但用户 A 和用户 B 都各自有一些私有数据，正常情况下，用户自己只能访问自己的私有数据，例如：你有删除邮件的功能（操作权限），但只能删除自己的邮件，不能误删其他人的邮件（数据权限）。但在 RBAC 模型下，系统只会验证用户 A 是否属于角色 RoleX，而不会判断用户 A 是否能访问只属于用户 B 的数据 DataB，此时就可能发生越权访问。

这种问题，称之为『水平权限管理问题』，又可以称之为『基于数据的访问控制』：相比垂直权限管理来说，水平权限问题出现在同一个角色上，系统只验证了能访问数据的角色，没有对数据的子集做细分，因此缺乏了一个用户到数据级之间的对应关系。对于数据的访问控制，与业务结合的比较紧密，目前还没有统一的数据级权限管理框架，一般是具体问题具体解决。

数据权限就是控制访问数据的可见范围，表现形式是：当某用户有操作权限时候，不代表对所有数据都有查看或管理的权限。一般表现为行权限和列权限:

1. 行权限：限制用户对某些行的访问，例如：只能对某人、某部门的数据进行访问；也可以是根据数据的范围进行限制，例如：按合同额大小限制用户对数据的访问
2. 列权限：限制用户对某些列的访问，例如：某些内容的摘要可以被查阅，但详细内容只有 VIP 用户能查阅

水平权限的漏洞案例：

Web 应用程序接受用户的请求，修改某条数据时，而没有判断当前用户是否可以访问该条记录（判断数据的所属人），导致恶意用户可以修改本不属于自己的数据。例如：/api/v1/blog?blogId=xxx [DELETE] 这是删除博客内容的 url，当用户改变 blogId 时，后端如果未校验博客的所属人是否是当前用户，则可以删除其他人的博客内容。

解决方案：

根据用户的 ID 做好数据级权限控制，比如针对 CRUD 操作进行会话身份验证，并且对用户访问的对象记录校验数据权限进行校验，防止通过修改 ID 的方式越权查看别人的隐私信息（按业务场景）。

访问控制与业务需求需求息息相关，并非是一个单纯的安全问题。因此在解决此类问题或者设计权限控制方案时，要重视业务的意见。最后，无论选择哪种访问控制方式，在设计方案时都应该满足“最小权限原则”，这是权限管理的黄金法则。

IP 黑白名单

DDOS 攻击

DDOS 又称为分布式拒绝服务，全称是 Distributed Denial of Service。DDOS 本是利用合理的请求造成资源过载，导致服务不可用。

比如一个停车场总共有 100 个车位，当 100 个车位都停满车后，再有车想要停进来，就必须等已有的车先出去才行。如果已有的车一直不出去，那么停车场的入口就会排起长队，停车场的负荷过载，不能正常工作了，这种情况就是“拒绝服务”。我们的系统就好比是停车场，系统中的资源就是车位。资源是有限的，而服务必须一直提供下去。如果资源都已经被占用了，那么服务也将过载，导致系统停止新的响应。

分布式拒绝服务攻击，将正常请求放大了若干倍，通过若干个网络节点同时发起攻击，以达成规模效应。这些网络节点往往是黑客们所控制的“肉鸡”，数量达到一定规模后，就形成了一个“僵尸网络”。大型的僵尸网络，甚至达到了数万、数十万台的规模。如此规模的僵尸网络发起的 DDOS 攻击，几乎是不可阻挡的。

常见的 DDOS 攻击有 SYN flood、UDP flood、ICMP flood 等。其中 SYN flood 是一种最为经典的 DDOS 攻击，其发现于 1996 年，但至今仍然保持着非常强大的生命力。SYN flood 如此猖獗是因为它利用了 TCP 协议设计中的缺陷，而 TCP/IP 协议是整个互联网的基础，牵一发而动全身，如今想要修复这样的缺陷几乎成为不可能的事情。

Syn_Flood 攻击原理

攻击者首先伪造地址对服务器发起 SYN 请求（我可以建立连接吗？），服务器就会回应一个 ACK+SYN（可以 + 请确认）。而真实的 IP 会认为，我没有发送请求，不作回应。服务器没有收到回应，会重试 3 - 5 次并且等待一个 SYNTime（一般 30 秒 - 2 分钟）后，丢弃这个连接。

如果攻击者大量发送这种伪造源地址的 SYN 请求，服务器端将会消耗非常多的资源来处理这种半连接，保存遍历会消耗非常多的 CPU 时间和内存，何况还要不断对这个列表中的 IP 进行 SYN+ACK 的重试。TCP 是可靠协议，这时就会重传报文，默认重试次数为 5 次，重试的间隔时间从 1s 开始每次都番倍，分别为 1s+2s + 4s + 8s +16s = 31s, 第 5 次发出后还要等 32s 才知道第 5 次也超时了，所以一共是 31 + 32 = 63s。

也就是说一个假的 syn 报文，会占用 TCP 准备队列 63s 之久，也就是说在没有任何防护的情况下，频繁发送伪造的伪造 syn 包，就会耗尽连接资源，从而使真正的连接无法建立，无法响应正常请求。最后的结果是服务器无暇理睬正常的连接请求—拒绝服务。

Syn_Flood 防御

cookie 源认证

原理是 syn 报文首先由 DDOS 防护系统来响应 syn_ack。带上特定的 sequence number（记为 cookie）。真实的客户端会返回一个 ack 并且 Ack number 为 cookie+1。而伪造的客户端，将不会作出响应。这样我们就可以知道那些 IP 对应的客户端是真实的，将真实客户端 IP 加入白名单。下次访问直接通过，而其他伪造的 syn 报文就被拦截。

reset 认证

Reset 认证利用的是 TCP 协议的可靠性，也是首先由 DDOS 防护系统来响应 syn。防护设备收到 syn 后响应 syn_ack, 将 Ack number (确认号)设为特定值（记为 cookie）。当真实客户端收到这个报文时，发现确认号不正确，将发送 reset 报文，并且 sequence number 为 cookie + 1。而伪造的源，将不会有任何回应。这样我们就可以将真实的客户端 IP 加入白名单。

在很多对抗 DDOS 的产品中，一般会综合使用各种算法，结合一些 DDOS 攻击的特征，对流量进行清洗。对抗 DDOS 的网络设备可以串联或者并联在网络出口处。但 DDOS 仍然是业界的一个难题，当攻击流量超过了网络设备，甚至带宽的最大负荷时，网络仍将瘫痪。一般来说，大型网站之所以看起来比较能“抗”DDOS 攻击，是因为大型网站的带宽比较充足，集群内服务器的数量也比较多。但一个集群的资源毕竟是有限的，在实际的攻击中，DDOS 的流量甚至可以达到数 G 到几十 G, 遇到这种情况，只能与网络运营商合作，共同完成 DDOS 攻击的响应。

DDOS 的攻击与防御是一个复杂的课题，因此对网络层的 DDOS 攻防在此不做深入讨论。

CC 攻击

CC 攻击是 DDOS 攻击的一种方式，可以理解为是应用层的 DDOS 攻击。

攻击者借助代理服务器生成指向受害主机的合法请求，实现 DDOS 和伪装就叫：CC(Challenge Collapsar)。

CC 攻击的原理非常简单，就是对一些消耗资源较大的应用页面不断发起正常的请求，以达到消耗服务端资源的目的。在 Web 应用中，查询数据库、读 / 写硬盘文件等操作，相对都会消耗比较多的资源。一个很典型的例子：

String sql = " select * from post where targid=${targid}
order by postid desc limit ${start},30";

当 post 表数据庞大，翻页频繁，$start数字急剧增加时，查询结果集=${start}+30；该查询效率呈明显下降趋势，而多并发频发调用，因查询无法立即完成，资源无法立即释放，会导致数据库请求连接过多，数据库阻塞，网站无法正常打开。

CC 就是充分利用了这个特点，模拟多个用户不停的进行访问那些高计算、高 IO 的数据。为什么要使用代理呢？因为代理可以有效地隐藏自己的身份，也可以绕开所有的防火墙，因为基本上所有的防火墙都会检测并发的 TCP/IP 连接数目，超过一定数目一定频率就会被认为是 Connection-Flood。

在互联网中充斥着各种搜索引擎、信息收集等系统的爬虫（spider）, 爬虫把小网站直接爬死的情况时有发生，这与应用层 DDOS 攻击的结果很像。

应用层 DDOS 攻击还可以通过以下方式完成：在黑客入侵了一个流量很大的网站后，通过篡改页面，将巨大的用户流量分流到目标网站。

<!-- 那么访问该页面的用户，都将对 target 发起一个 get 请求，这可能直接导致 target 拒绝服务 -->
<iframe src="http://target" height="0" width="0">
</iframe>

应用层 DDOS 攻击是针对服务器性能的一种攻击，那么许多优化服务器性能的方法，都或多或少地能缓解此种攻击。比如将使用频率高的数据放在 memcache 中，相对于查询数据库所消耗的资源来说，查询 memcache 所消耗的资源可以忽略不计。

但很多性能优化的方案并非是为了对抗应用层 DDOS 攻击而设计的，因此攻击者想要找到一个资源消耗大的页面并不困难。比如当 memcache 查询没有命中时，服务器必然会查询数据库，从而增大服务器资源的消耗，攻击者只需要找到这样的页面即可。

同时攻击者除了触发“读”数据操作外，还可以触发“写”数据操作，“写”数据的行为一般都会导致服务器操作数据库。

CC 防护

应用层 DDOS 攻击并非一个无法解决的难题，一般来说，我们可以从以下几个方面着手。

首先，应用代码要做好性能优化。 合理地使 cache 就是一个很好的优化方案，将数据库的压力尽可能转移到内存中。此外还需要及时地释放资源，比如及时关闭数据库连接，减少空连接等消耗。

其次，在网络架构上做好优化。 善于利用负载均衡分流，避免用户流量集中在单台服务器上。同时可以充分利用好 CDN 和镜像站点的分流作用，缓解主站的压力。

再有，使用页面静态化技术，利用客户端浏览器的缓存功能或者服务端的缓存服务，以及 CDN 节点的缓冲服务，均可以降低服务器端的数据检索和计算压力，快速响应结果并释放连接进程。

最后，也是最重要的一点，实现一些对抗手段，比如限制每个 IP 地址的请求频率，超出限制策略后动态加入黑名单（也就是实现一些反爬手段）

1. 验证码

嵌入验证码能够有效防止资源滥用，因为通常脚本无法自动识别出验证码。但验证码也分三六九等，有的验证码容易识别，有的则较难识别。验证码发明的初衷，是为了识别人与机器。但验证码如果设计得过于复杂，那么人也很难辨识出来，所以验证码是一把双刃剑。

2. Detecting system abuse

Yahoo 为我们提供了一个解决思路。如果发起应用层 DDOS 攻击的 IP 地址都是真实的，所以在实际情况中，攻击者的 IP 地址其实也不可能无限制增长。假设攻击者有 1000 个 IP 地址发起攻击，如果请求了 10000 次，则平均每个 IP 地址请求同一页面达到 10 次，攻击如果持续下去，单个 IP 地址的请求也将变多，但无论如何变，都是在这 1000 个 IP 地址的范围内做轮询。

为此 Yahoo 实现了一套算法，根据 IP 地址和 Cookie 等信息，可以计算客户端的请求频率并进行拦截。Yahoo 设计的这套系统也是为 Web Server 开发的一个模块，但在整体架构上会有一台 master 服务器集中计算所有 IP 地址的请求频率，并同步策略到每台 Webserver 上。

Yahoo 为此申请了一个专利（Detecting system abuse），因此我们可以查阅此专利的公开信息，以了解更多的详细信息。

Yahoo 设计的这套防御体系，经过实践检验，可以有效对抗应用层 DDOS 攻击和一些类似的资源滥用攻击。但 Yahoo 并未将其开源，因此对于一些研发能力较强的互联网公司来说，可以根据专利中的描述，实现一套类似的系统

专利页面：https://xueshu.baidu.com/usercenter/paper/show?paperid=3945f7b5a9fbc6f3ebbe4c246899eece&site=xueshu_se

IP 黑白名单方式

阿里云安全产品：

• Web 应用防火墙 – IP 黑白名单配置
• CDN – 配置 IP 黑白名单
• DDoS 防护 – 配置黑白名单
• 开发 IP 黑白名单功能

1. OpenResty

OpenResty 是一个基于 Nginx 的可伸缩的 Web 平台，由中国人章亦春发起，提供了很多高质量的第三方模块。OpenResty 是一个强大的 Web 应用服务器，Web 开发人员可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块, 更主要的是在性能方面，OpenResty 可以快速构造出足以胜任 10K 以上并发连接响应的超高性能 Web 应用系统。360，UPYUN，阿里云，新浪，腾讯网，去哪儿网，酷狗音乐等都是 OpenResty 的深度用户。

2. Lua

Lua 是一种轻量小巧的脚本语言，用标准 C 语言编写并以源代码形式开放，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。Lua 是巴西里约热内卢天主教大学里的一个研究小组于 1993 年开发的。

通过 Lua 编写限流、权限认证、黑白名单等功能

设计目的：

其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能

Lua 特性：

轻量级: 它用标准 C 语言编写并以源代码形式开放，编译后仅仅一百余 K，可以很方便的嵌入别的程序里。

可扩展: Lua 提供了非常易于使用的扩展接口和机制：由宿主语言（通常是 C 或 C ++）提供这些功能，Lua 可以使用它们，就像是本来就内置的功能一样。

动态黑名单实现

1. 安装 OpenResty

# 下载
wget https://openresty.org/download/ngx_openresty-
1.9.7.1.tar.gz
# 解压
tar xzvf ngx_openresty-1.9.7.1.tar.gz
cd ngx_openresty-1.9.7.1/
# 配置
./configure
# 编译
make
# 安装
make install
# 配置 nginx profile PATH
PATH=/usr/local/openresty/nginx/sbin:$PATH
export PATH
# 指定配置
nginx -c /usr/local/openresty/nginx/conf/nginx.conf

2. 配置

用 OpenResty 以及下面的 redis 组件，配置 redis 数据库信息及黑名单策略

set $redis_service "127.0.0.1";
set $redis_port 6380;
set $redis_db 0;

# 1 second 50 query
set $black_count 50;
set $black_rule_unit_time 1;
set $black_ttl 3600;
set $auto_blacklist_key blackkey;

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

• redis_service：redis 服务器 ip 地址
• redis_port：redis 服务器端口
• redis_db：所使用的 redis db
• black_count：拉黑限制的最大访问次数
• black_rule_unit_time：拉黑限制次数的保存时间，即保存访问次数的 kv 的 ttl
• black_ttl：黑名单的存活时间
• auto_blacklist_key：kv 的部分 key
• 重点控制好 black_count 和 black_rule_unit_time

3. lua 脚本

ip_blacklist.lua，从 ip 及 token（访问凭证）入手来控制

local redis_service = ngx.var.redis_service
local redis_port = tonumber(ngx.var.redis_port)
local redis_db = tonumber(ngx.var.redis_db)
local black_count = tonumber(ngx.var.black_count)
local black_rule_unit_time =
tonumber(ngx.var.black_rule_unit_time)
local cache_ttl = tonumber(ngx.var.black_ttl)
local remote_ip = ngx.var.remote_addr

-- 计数
function my_count(redis, status_key, count_key)
	local key = status_key
	local key_connect_count = count_key
	
	local Status = redis:get(key)
	local count = redis:get(key_connect_count)
	
	if Status ~= ngx.null then
		-- 状态为 connect 且 count 不为空 且 count <= 拉黑次数
		if (Status == "Connect" and count ~= ngx.null and tonumber(count) <= black_count) then
			-- 再读一次
			count = redis:incr(key_connect_count)
			ngx.log(ngx.ERR, "count:", count)
			if count ~= ngx.null then
				if tonumber(count) > black_count then
                    redis:del(key_connect_count)
					redis:set(key,"Black")
					-- 永久封禁
					-- Redis:expire(key,cache_ttl)
				else
					redis:expire(key_connect_count,black_rule_unit_time)
				end
			end
		else
			ngx.log(ngx.ERR,"The visit is blocked by the blacklist because it is too frequent. Please visit later.")
			return ngx.exit(ngx.HTTP_FORBIDDEN)
		end
	else
		local count = redis:get(key)
		if count == ngx.null then
			redis:del(key_connect_count)
		end
		redis:set(key,"Connect")
		redis:set(key_connect_count,1)
		redis:expire(key,black_rule_unit_time)
		redis:expire(key_connect_count,black_rule_unit_time)
	end
end

-- 读取 token
local token
local header = ngx.req.get_headers()["Authorization"]
if header ~= nil then
	token = string.match(header, 'token (%x+)')
end
local redis_connect_timeout = 60
local redis = require "resty.redis"
local Redis = redis:new()
local auto_blacklist_key = ngx.var.auto_blacklist_key

Redis:set_timeout(redis_connect_timeout)

local RedisConnectOk,ReidsConnectErr =
Redis:connect(redis_service,redis_port)
local res = Redis:auth("password");

if not RedisConnectOk then
	ngx.log(ngx.ERR,"ip_blacklist connect Redis Error :" ..ReidsConnectErr)
else
	-- 连接成功
	Redis:select(redis_db)
	local key = auto_blacklist_key..":"..remote_ip
	local key_connect_count = auto_blacklist_key..":key_connect_count:"..remote_ip
	my_count(Redis, key, key_connect_count)
	if token ~= nil then
		local token_key, token_key_connect_count
		token_key = auto_blacklist_key..":"..token
		token_key_connect_count =
		auto_blacklist_key..":key_connect_count:"..token
		my_count(Redis, token_key, token_key_connect_count)
	end
end

至于对于添加到黑名单的 ip 及 token，需要怎么做下一步的处理，这边就给服务器下的具体应用来处理，在这里不阐述。

4. 配置到 nginx 的 conf 中

server {
	listen 80;
	server_name edu.lagou.com;
	root /~/public;
	# 加载配置文件
	include /etc/nginx/conf.d/blacklist_params;
	# 指定请求中需要执行的 lua 脚本
	access_by_lua_file /etc/nginx/conf.d/ip_blacklist.lua;
	location / {	} 

	error_log /etc/nginx/conf.d/log/error.log;
	access_log /etc/nginx/conf.d/log/access.log;
}

配置就完成了，在 console 中重启下 nginx nginx -s reload，就可以实现动态添加黑名单的需要了。至于对于添加到黑名单的 ip 及 token，需要怎么做下一步的处理，这边就给服务器下的具体应用来处理，在这里不阐述。

至于对于添加到黑名单的 ip 及 token，需要怎么做下一步的处理，这边就给服务器下的具体应用来处理，在这里不阐述。

4. 配置到 nginx 的 conf 中

server {
	listen 80;
	server_name edu.lagou.com;
	root /~/public;
	# 加载配置文件
	include /etc/nginx/conf.d/blacklist_params;
	# 指定请求中需要执行的 lua 脚本
	access_by_lua_file /etc/nginx/conf.d/ip_blacklist.lua;
	location / {	} 

	error_log /etc/nginx/conf.d/log/error.log;
	access_log /etc/nginx/conf.d/log/access.log;
}

 

配置就完成了，在 console 中重启下 nginx nginx -s reload，就可以实现动态添加黑名单的需要了。至于对于添加到黑名单的 ip 及 token，需要怎么做下一步的处理，这边就给服务器下的具体应用来处理，在这里不阐述。

API 网关 Kong，基于 OpenResty，开源与 2015 年，核心价值在于其高性能和跨站性。从全球 500 强的组织统计数据来看，Kong 现在是维护的、在生产环境使用最广泛的网关。Plugin IP Restriction 通过设置 IP 白名单和黑名单，根据客户端 IP 来对一些请求进行拦截和防护。