web安全的常见问题分析之XSS攻击

Love The Way You Lie 2024-04-20 00:45 96阅读 0赞

### 一、XSS攻击 ###

##### 1. XSS #####

XSS(`Cross-Site Scripting`，跨站脚本攻击)是一种代码注入攻击，攻击者在目标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本可以读取 cookie，session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等

##### 2. XSS 的本质 #####

恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，利用这些信息冒充用户向网站发起攻击者定义的请求

###### 3. 根据攻击的来源，XSS攻击可以分为存储型(持久性)、反射型(非持久型)和DOM型三种 ######

##### 4. 反射型XSS #####

1）当用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。Web服务器将注入脚本，比如一个错误信息，搜索结果等，未进行过滤直接返回到用户的浏览器上  
2）**反射型 XSS 的攻击步骤**

*  攻击者构造出特殊的 URL，其中包含恶意代码
 *  用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器
 *  用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行
 *  恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作

3）反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击  
4）POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见  
5）注意Chrome 和 Safari 能够检测到 url 上的xss攻击，将网页拦截掉，但是其它浏览器不行，如Firefox  
6）如果不希望被前端拿到cookie，后端可以设置 httpOnly (不过这不是 XSS攻击 的解决方案，只能降低受损范围)  
7）防范反射型XSS攻击，对url的查询参数进行转义后再输出到页面  
举例：

app.get('/welcome', function(req, res) { 
       //对查询参数进行编码，避免反射型 XSS攻击
       res.send(`${ encodeURIComponent(req.query.type)}`); 
    });

##### 5. DOM 型 XSS #####

1）**DOM 型 XSS 攻击**  
实际上就是前端 JavaScript 代码不够严谨，把不可信的内容插入到了页面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API时要特别小心，不要把不可信的数据作为 HTML 插到页面上，尽量使用 .innerText、.textContent、.setAttribute() 等  
2）**DOM 型 XSS 的攻击步骤**  
攻击者构造出特殊数据，其中包含恶意代码  
用户浏览器执行了恶意代码  
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作  
3）**防范 DOM 型 XSS 攻击**  
防范 DOM 型 XSS 攻击的核心就是对输入内容进行转义，DOM 中的内联事件监听器和链接跳转都能把字符串作为代码运行，需要对其内容进行检查  
对于url链接(例如图片的src属性)，那么直接使用 `encodeURIComponent` 来转义  
非url，我们可以这样进行编码  
实例代码：

function encodeHtml(str) { 
        return str.replace(/"/g, '"')
                .replace(/'/g, ''')
                .replace(/</g, '<')
                .replace(/>/g, '>');
    }

4）DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞

##### 6. 存储型XSS #####

1）恶意脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器传回并执行，影响范围比反射型和DOM型XSS更大。存储型XSS攻击的原因仍然是没有做好数据过滤：前端提交数据至服务端时，没有做好过滤；服务端在接受到数据时，在存储之前，没有做过滤；前端从服务端请求到数据，没有过滤输出  
2）**存储型 XSS 的攻击步骤**

*  攻击者将恶意代码提交到目标网站的数据库中
 *  用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器
 *  用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行
 *  恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作  
    3）这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信  
    4）**防范存储型XSS攻击**  
    前端数据传递给服务器之前，先转义/过滤(防范不了抓包修改数据的情况)  
    服务器接收到数据，在存储到数据库之前，进行转义/过滤  
    前端接收到服务器传递过来的数据，在展示到页面前，先进行转义/过滤  
    5）其它手段防范XSS攻击  
    i) **Content Security Policy**  
    在服务端使用 HTTP的 `Content-Security-Policy` 头部来指定策略，或者在前端设置 meta 标签  
    前端和服务端设置 CSP 的效果相同，但是meta无法使用report  
    严格的 CSP 在 XSS 的防范中可以起到以下的作用：
 *  禁止加载外域代码，防止复杂的攻击逻辑
 *  禁止外域提交，网站被攻击后，用户的数据不会泄露到外域
 *  禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）
 *  禁止未授权的脚本执行（新特性，Google Map 移动版在使用）
 *  合理使用上报可以及时发现 XSS，利于尽快修复问题  
    ii) **输入内容长度控制**  
    对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度  
    iii) **输入内容限制**  
    对于部分输入，可以限定不能包含特殊字符或者仅能输入数字等  
    iiii) **其他安全措施**  
    HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie  
    验证码：防止脚本冒充用户提交危险操作

1.  XSS 检测  
    1）**使用通用 XSS 攻击字串手动检测 XSS 漏洞**  
    举例：``jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e``  
    说明：能够检测到存在于 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文中的 XSS 漏洞，也能检测 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能绕过一些 XSS 过滤器  
    2）**使用第三方工具进行扫描**