nginx常见漏洞解析_nginx漏洞，2024年最新蚂蚁金服网络安全架构面试题 ...

先自我先容一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，通常是自己摸索发展，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是盼望可以大概资助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小搭档深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！
由于文件比力多，这里只是将部分目录截图出来，全套包罗大厂面经、学习条记、源码讲义、实战项目、大纲门路、解说视频，并且后续会持续更新
如果你必要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

5.2.1 引发原因
5.2.2概念先容：
5.2.3漏洞利用：

---

什么是中央件？什么是中央件漏洞？

中央件漏洞可以说是最轻易被web管理员忽视的漏洞，原因很简单，由于这并不是应用程序代码上存在的漏洞，而是属于一种应用摆设情况的设置不妥大概使用不妥造成的。但是在开发使用过程中也不乏官方程序自身的一些安全标题。
我们在处理应急响应事件时经常遇到这么一种情况，客户网站代码是外包的，也就是第三方公司负责开发，而摆设可能是由客户内部运维人员负责。暂不说他们对于中央件安全的器重程度与了解程度，只谈发现漏洞后怎样处理，便是一团乱。开发商推卸说这并不是代码上的标题，他们完全是按照安全开发流程（SDL）走的，所以跟他无关；运维人员就一脸蒙蔽了，反驳道：你们当初没跟我说要设置什么啊，只是让我安装个程序就ok了，我怎么知道？
在谈中央件安全标题时，我觉得有必要先梳理下以上几种关系以及概念。当初我在打仗这些概念时，脑筋里就是一团浆糊，中央件、容器、服务器、webserver等等概念感觉彼此很相似，但又有所区别。
web中央件 容器 服务解析：
   web服务器:
web服务器用于提供http服务，即向客户端返回信息，其可以处理HTTP协议，响应针对静态页面或图片的请求，控制页面跳转，大概把动态请求委托其它程序（中央件程序）等。
  web中央件:
web中央件用于提供体系软件和应用软件之间的毗连，以便于软件各部件之间的沟通，其可以为一种或多种应用程序提供容器。
  web容器:
web容器用于给处于其中的应用程序组件（JSP，SERVLET）提供一个情况，是中央件的一个组成部分，它实现了对动态语言的解析。比如tomcat可以解析jsp，是由于其内部有一个jsp容器。
  常见的组件：
   web服务器：IIS、Apache、nginx、tomcat、weblogic、websphere等。
web中央件：apache tomcat、BEA WebLogic、IBM WebSphere等。
web容器：JSP容器、SERVLET容器、ASP容器等。
  注意：web中央件与web服务器是有重叠的，原因在于tomcat等web中央件也具备web服务器的功能。
说白了，web中央件就是运行在服务器上的一个程序，它的作用是为服务器提供一个解析http大概https请求的方案。由它充当中央人，确定前端传输的信息应该交给后端哪一个文件进行处理，并向前端返回效果。
对于其的操控我们大多数时间是在LINUX情况下采用设置文件对其进行控制。这就意味着某些错误的设置会引发一些安全漏洞。并且作为一款程序，也一定会存在着一些自身的安全漏洞。以上两个方向就是我们研究任何一个中央件漏洞应该具有的基本认知。
今天我们先来看一看nginx出现过的一些漏洞，情况均来自vulhub官网，其为基于docker的漏洞情况集成库，对我们的学习很有资助~
三个设置不妥导致的nginx漏洞

1. root㉿killer)-[~/vulhub/nginx/insecure-configuration/configuration]
2. docker-compose up -d

复制代码

作为设置不妥引起的漏洞，自然对全部版本的nginx都影响，这种小的标题反而很轻易引起忽视。
1.$uri导致的crlf注入漏洞

下面两种情景非常常见：

• 用户访问http://example.com/aabbcc，主动跳转到https://example.com/aabbcc
  
• 用户访问http://example.com/aabbcc，主动跳转到http://www.example.com/aabbcc
  

第二个场景重要是为了同一用户访问的域名，更加有益于SEO优化。
在跳转的过程中，我们必要保证用户访问的页面不变，所以必要从Nginx获取用户请求的文件路径。检察Nginx文档，可以发现有三个表示uri的变量：

• $uri
  
• $document_uri
  
• $request\_uri
  

1. location / {
2.     return 302 https://$host$uri;
3. }
4. #因为`$uri`是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。

复制代码

解释一下，1和2表示的是解码以后的请求路径，不带参数；3表示的是完整的URI（没有解码）。那么，如果运维设置了下列的代码：

1. location / {
2.     return 302 https://$host$uri;
3. }
4. #因为`$uri`是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。

复制代码

由于**$uri**和**$document_uri**是解码以后的请求路径，所以可能就会包罗换行符，也就造成了一个CRLF注入漏洞。
1.1利用方式：

我们在请求的过程中发送一个带有%0d%0a编码的请求：

1. #请求内容
2. curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
3. #测试结果
4. [root@blackstone insecure-configuration]# curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
5. HTTP/1.1 302 Moved Temporarily
6. Server: nginx/1.13.0
7. Date: Thu, 12 Jan 2023 12:18:16 GMT
8. Content-Type: text/html
9. Content-Length: 161
10. Connection: keep-alive
11. Location: http://192.168.2.169:8080/
12. Set-Cookie: a=1

复制代码

我们通过上述手段对请求进行了修改，利用此漏洞可以看到返回了一个set-cookie，也就是说错误的使用$uri设置会是用户的请求被黑客悄无声息的窜改掉。
我们使用burp抓包可以看到另一种可能性：在我们发送两个一连的换行\r\n后，可以直接修改返回报文的返回体。插入js代码引发xss。

1.2修改方案：

在获取用户的请求路径时，设置文件内出现的设置应当是**$request_uri**,比方：

1. location / {
2.     return 302 https://$host$request_uri;
3. }

复制代码

由于**$request_uri和上边1和2相反，表示的是完整的uri并不会解码。**
另外，由$uri导致的CRLF注入漏洞不但可能出现在上述两个场景中，理论上，只要是可以设置HTTP头的场景都会出现这个标题。
测试一下效果：

1. #1.编辑配置文件，投放进docker
2. [root@blackstone configuration]# cat fix1.conf
3. server {
4.         listen 8080;
6.         root /usr/share/nginx/html;
8.         index index.html;
10.         server_name _;
12.         location / {
13.                 return 302 http://$host:$server_port$request_uri;
14.         }
15. }
17. #2.将配置文件放到特定目录，重启nginx
18. [root@blackstone configuration]# docker exec -it fa2e43aabeec /bin/bash
19. root@fa2e43aabeec:/# cp fix1.conf /etc/nginx/conf.d/
20. root@fa2e43aabeec:/# rm -f /etc/nginx/conf.d/error1.conf
21. root@fa2e43aabeec:/etc/nginx/conf.d# nginx -s reload
24. #3.查看效果，确实可以有效消除CRLF的影响
25. [root@blackstone ~]# curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
26. HTTP/1.1 302 Moved Temporarily
27. Server: nginx/1.13.0
28. Date: Wed, 08 Feb 2023 18:44:14 GMT
29. Content-Type: text/html
30. Content-Length: 161
31. Connection: keep-alive
32. Location: http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1

复制代码

2. 目录穿越漏洞：

这个常见于Nginx做反向代理的情况，动态的部分被proxy_pass转达给后端端口，而静态文件必要Nginx来处理。
假设静态文件存储在/home/目录下，而该目录在url中名字为files，那么就必要用alias设置目录的别名：

1. location /files {
2.     alias /home/;
3. }

复制代码

2.1利用方式

此时，访问http://example.com/files/readme.txt，就可以获取/home/readme.txt文件。
但我们注意到，url上/files没有加后缀/，而alias设置的/home/是有后缀/的，这个/就导致我们可以从/home/目录穿越到他的上层目录：

此时我们就获得了一个目录穿越漏洞，他可以进行恣意文件的下载，比方php mysql等等。
固然有些mysql禁止远程登录，但是可以通过mysql的用户名和密码去进行一个社工，如果MySQL的密码较为牢靠那么可能其他体系的密码也是此密码，当然这只是一个没好的臆想大概说猜测，
2.2办理方案

在进行alies设置的过程中一定保证location后的匹配路径和别名路径一致。否则就会引发如许的路径穿越漏洞。

3.HTTP header头被覆盖：

众所周知，Nginx的设置文件分为Server、Location、If等一些设置块，并且存在包罗关系，和编程语言比力雷同。如果在外层设置的一些选项，是可以被继承到内层的。
但这里的继承也有一些特性，比如add_header，子块中设置后将会覆盖父块中的add_header添加的全部HTTP头，造成一些安全隐患。
如下列代码，Server块添加了CSP头：

1. server {
2.     ...
3.     add_header Content-Security-Policy "default-src 'self'";
4.     add_header X-Frame-Options DENY;
6.     location = /test1 {
7.         rewrite ^(.*)$ /xss.html break;
8.     }
10.     location = /test2 {
11.         add_header X-Content-Type-Options nosniff;
12.         rewrite ^(.*)$ /xss.html break;
13.     }
14. }

复制代码

但/test2的location中又添加了X-Content-Type-Options头，nginx仅载入模块内部的头部修改信息，则会导致在父块中设置的 add_header Content-Security-Policy “default-src ‘self’”;无法在/test2中生效。从而使/test2这里无法获得防御功能
3.1利用方式：

此处的漏洞情况内部，摆设了xss漏洞点，通过 add_header Content-Security-Policy “default-src ‘self’”;头的设置理论上是可以防御XSS攻击的。但是由于此处/test2目录下的设置错误，导致这条设置不在此目录下生效。故仍然可以使用XSS进行攻击。

1. #这是转到的JS文件，获取锚点也就是#后面的内容添加到<p>标签内部
2. window.onload = function() {
3.     var m = document.getElementById('m');
4.     m.innerHTML = location.hash.substr(1);
5. }

复制代码

这个东西会对写入的xss进行转义。
所以可以利用写法可以写为：
http://127.0.0.:8082/test2#
但是新版浏览器针对xss攻击有一些限制，我们使用旧的浏览器可以发现：

可以看到，实际上/test2的防御机制并未打开。不外例子中的xss触发方案已经被浏览器防御了。
3.2修改方案：

设置头部信息修改时细分到最小块，如许才能最大限度的保证每一个小块的头部设置都是正确的。当然，也可以写到父块中，但是子块在进行头部个性化修改时，切记将父块中的头设置给子块复制一份。
说的更清楚一点，就是关于header的修改操作。不在nginx设置继承范围内。子块一旦修改，最终调用的设置就只在子块内部寻找。
修改设置文件为：

1. #1.直接在宿主机上修改对应文件也生效(配置文件是从宿柱机链进去的，具体可以看.yml文件)
2. [root@blackstone configuration]# pwd
3. /root/vulhub-master/nginx/insecure-configuration/configuration
4. #2.修改文件
5. [root@blackstone configuration]# cat error3.conf
6. server {
7.         listen 8082;
9.         root /usr/share/nginx/html;
11.         index index.html;
13.         server_name _;
15.     autoindex on;
17.     add_header Content-Security-Policy "default-src 'self'";
18.     add_header X-Frame-Options DENY;
20.         location = /test1 {
21.                 rewrite ^(.*)$ /xss.html break;
22.         }
24.     location = /test2 {
25.         add_header X-Content-Type-Options nosniff;
26.         add_header Content-Security-Policy "default-src 'self'";
27.         add_header X-Frame-Options DENY;
28.         rewrite ^(.*)$ /xss.html break;
29.     }
30. }
31. #3.进入docker重启nginx
32. [root@blackstone configuration]# docker exec -it fa2e43aabeec /bin/bash
33. root@fa2e43aabeec:/# nginx -s reload

复制代码

再次测试的话发现text2以及无法执行script。
4.nginx解析漏洞：

严格来说，这个漏洞的出现概率约即是0，甚至让人感觉非常的刻意而为之。请看：
这二者合在一起，在网页有文件上传功能时，百分百引发文件上传漏洞。属于高危设置手法。对于这个例子可能必要大家去看看nginx解析php原理。
总结来说，漏洞成因就是同时开启路径修复和图片后缀名解析(大概直接将解析设置为空)

1. [root@blackstone nginx_parsing_vulnerability]# cd /root/vulhub-master/nginx/nginx_parsing_vulnerability
2. [root@blackstone nginx_parsing_vulnerability]# docker-compose up -d

复制代码

Nginx解析漏洞：
影响版本：全版本
影响说明：命令执行，获取服务器web权限
情况说明：Nginx 1.13.0
情况搭建： 此次情况使用docker情况搭建，情况采用地址Vulhub
4.1漏洞原因：

Nginx的解析漏洞的出现和Nginx的版本没有关系，漏洞的产生是由于php设置标题导致的。出现了如下

1. # php.ini 目录修复，如果没找到则向上一级文件查找修复，为路径修复！
2. cgi.fix_pathinfo=1
3. # php-fpm.conf 开启.php后缀和.jpg后缀解析功能，或者有一个可能，他压根为off或者空，压根没写也可以解析。
4. security.limit_extensions = .php .jpg

复制代码

路径修复****以及PHP-fpm开启了图片jpg大概gif大概压根没开什么文件都能解析的，愚蠢
当访问http://127.0.0.1/test.jpg时显示图片解析错误，当访问http://127.0.0.1/test.jpg/test.php时效果显示Access denied，这个回显很奇怪，正常访问这个链接是不存在的，正常思维应该是404，这里就必要研究下Nginx的解析流程了：Nginx在收到/test.jpg/test.php路径时，起首判断文件类型，发现后缀是.php，便交给php处理，但php想要解析该文件时，发现并不存在，便删除掉/test.php，去找test.jpg，此时test.jpg是存在的，便要尝试解析它，但无奈后缀是.jpg，不是php，便报错Access denied。 上面的流程中提到了一个点，就是删除/test.php，这是Nginx的“修理”机制，由参数cgi.fix_pathinfo决定，当值为1时，便进行“修理”。比方，文件名为/aa.jpg/bb.png/cc.php，如果cc.php不存在就找/aa.jpg/bb.png，如果还不存在就找aa.jpg，如果存在将它视为php文件。 到目前为止我们并没有成功利用解析漏洞，由于php代码并没有执行。为什么呢？ 由于在PHP的设置中没有界说降.jpg文件中的php代码也解析为php，这是在security.limit_extensions中界说的。由于security.limit_extensions的引入，漏洞难以利用。
演示如下：

加一个/.php试试？

ok，就是这么简单。不外这玩意出现不太可能。
可以大概实现这个效果得益于愚蠢的设置。
   我们可以构造一个<?php phpinfo(); system($\_GET['var']); ?>图片马，则可以完成var=whomai
  

5.nginx自己的漏洞

对于程序自己的漏洞我们能做的就是版本升级，时刻保持程序为最新版，才有可能把风险降到最低。对于以下漏洞的修复方案就不在赘述。
5.1文件名逻辑漏洞（CVE-2013-4547）

影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
情况位置：/nginx/CVE-2013-4547

• Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
  
• php-fpm.conf中的security.limit_extensions为空，也就是说恣意后缀名都可以解析为PHP
  

5.1.1漏洞原因

Nginx版本范围较大，比力好匹配，但php-fpm.conf的security.limit_extensions设置默认为php，一般鲜有管理员答应全部类型都可以解析为PHP，所以该漏洞比力鸡肋，但这是在Linux的服务器中，而在Windows中便影响极大，这点我们后面再讲，先说下在Linux下的复现步调。
5.1.1.1漏洞前置知识

要理解这个漏洞我们先必要了解nginx解析php的原理，放一张图：

图中的几个界说：
   CGI：CGI是一种协议，它界说了Nginx大概其他Web Server转达过来的数据格式，全称是（Common Gateway Interface，CGI），CGI是一个独立的程序，独立与WebServer之外，任何语言都可以写CGI程序，比方C、Perl、Python等。
FastCGI：FastCGI是一种协议，它的前身是CGI，可以简单的理解为是优化版的CGI，拥有更够的稳定性和性能。
PHP-CGI：只是一个PHP的解释器，自己只能解析请求，返回效果，不会做进程管理。
PHP-FPM：全称FastCGI Process Manager，看名称就可以知道，PHP-FPM是FastCGI进程的管理器，但前面讲到FastCGI是协议并不是程序，所以它管理的是PHP-CGI，形成了一个雷同PHP-CGI进程池的概念。
Wrapper：字母意思是包装的意思，包装的是谁呢？包装的是FastCGI，通过FastCGI接口，Wrapper吸收到请求后，会天生一个新的线程调用PHP解释器来处理数据。
  Nginx调用PHP的过程是比力复杂的，必要花大量的时间来学习和梳理。通过原理图和刚才的界说，我们对Nginx处理PHP请求有了大致的了解。那么，Nginx是怎样知道将什么样的文件当作PHP文件处理？是在nginx.conf设置文件中的：

1. location ~ \.php$ {
2.     root           html;
3.     include        fastcgi_params;
5.     fastcgi_pass   IP:9000;
6.     fastcgi_index  index.php;
7.     fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
8.     fastcgi_param  DOCUMENT_ROOT /var/www/html;
9. }

复制代码

locating后边的 .php是一个正则，代表了以.php末端的文件都必须按照括号内的命令来执行，fastcgi是一个协议，具象化理解为nginx和php之间的一个媒介一个沟通交换方式，有点想路由协议但又不全是。nginx将请求通过fastcgi发送给PHP-fpm。其中nginx和fastcgi_pass可以不在同一台服务器上，用fastcgi_pass以ip和port端口的方式进行通信功能。
5.1.1.2漏洞引发条件：

作为相应版本的程序，其在解析URL时存在一定的缺陷，我们请求wbe-php.jpg[0x20][0x00].php，这个URI可以匹配上正则.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.jpg[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。也就是说后端的php代码在处理的过程中所担当到的文件名就是web-php.jpg。
同时检察php-fpm的设置文件可以看到：

我们来看一下官方设置文件给出的建议：

1. [root@blackstone php-fpm]# vim /etc/php-fpm.d/www.conf
3. ; Limits the extensions of the main script FPM will allow to parse. This can
4. ; prevent configuration mistakes on the web server side. You should only limit
5. ; FPM to .php extensions to prevent malicious users to use other extensions to
6. ; exectute php code.
9. ### 如何自学黑客&网络安全
12. #### 黑客零基础入门学习路线&规划
15. **初级黑客**  
16. **1、网络安全理论知识（2天）**  
17. ①了解行业相关背景，前景，确定发展方向。  
18. ②学习网络安全相关法律法规。  
19. ③网络安全运营的概念。  
20. ④等保简介、等保规定、流程和规范。（非常重要）
23. **2、渗透测试基础（一周）**  
24. ①渗透测试的流程、分类、标准  
25. ②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking  
26. ③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察  
27. ④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等
30. **3、操作系统基础（一周）**  
31. ①Windows系统常见功能和命令  
32. ②Kali Linux系统常见功能和命令  
33. ③操作系统安全（系统入侵排查/系统加固基础）
36. **4、计算机网络基础（一周）**  
37. ①计算机网络基础、协议和架构  
38. ②网络通信原理、OSI模型、数据转发流程  
39. ③常见协议解析（HTTP、TCP/IP、ARP等）  
40. ④网络攻击技术与网络安全防御技术  
41. ⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现
44. **5、数据库基础操作（2天）**  
45. ①数据库基础  
46. ②SQL语言基础  
47. ③数据库安全加固
50. **6、Web渗透（1周）**  
51. ①HTML、CSS和JavaScript简介  
52. ②OWASP Top10  
53. ③Web漏洞扫描工具  
54. ④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）  
55. 恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k
58. 到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？
61. 如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！
64. **7、脚本编程（初级/中级/高级）**  
65. 在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.
68. 如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。
70. **8、超级黑客**  
71. 这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。  
72. 
75. #### 网络安全工程师企业级学习路线
78.   
79. 如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的
82. 视频配套资料&国内外网安书籍、文档&工具
85. 当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。
87.   
88. 一些笔者自己买的、其他平台白嫖不到的视频教程。  
89. 
95. **网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
97. **需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）**
98. 
100. **一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
102. ebp?x-oss-process=image/format,png)  
103. 如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的
106. 视频配套资料&国内外网安书籍、文档&工具
109. 当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。
111.   
112. 一些笔者自己买的、其他平台白嫖不到的视频教程。  
113. 
119. **网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
121. **需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）**
122. [外链图片转存中...(img-4yhHGgHO-1713165679221)]
124. **一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。