亚洲精品动漫在线观看,亚洲精品成人久久久,精品不卡一区二区

web安全之XSS實例解析

2020-5-20 seo達人

XSS

跨站腳本攻擊（Cross Site Script）,本來縮寫是 CSS, 但是為了和層疊樣式表（Cascading Style Sheet, CSS）有所區分，所以安全領域叫做 “XSS”；

XSS攻擊，通常是指攻擊者通過 “HTML注入”篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，對用戶的瀏覽器進行控制或者獲取用戶的敏感信息（Cookie, SessionID等）的一種攻擊方式。

頁面被注入了惡意JavaScript腳本，瀏覽器無法判斷區分這些腳本是被惡意注入的，還是正常的頁面內容，所以惡意注入Javascript腳本也擁有了所有的腳本權限。如果頁面被注入了惡意 JavaScript腳本，它可以做哪些事情呢？

可以竊取 cookie信息。惡意 JavaScript可以通過 ”doccument.cookie“獲取cookie信息，然后通過 XMLHttpRequest或者Fetch加上CORS功能將數據發送給惡意服務器；惡意服務器拿到用戶的cookie信息之后，就可以在其他電腦上模擬用戶的登陸，然后進行轉賬操作。

可以監聽用戶行為。惡意JavaScript可以使用 "addEventListener"接口來監聽鍵盤事件，比如可以獲取用戶輸入的銀行卡等信息，又可以做很多違法的事情。

可以修改DOM 偽造假的登陸窗口，用來欺騙用戶輸入用戶名和密碼等信息。

還可以在頁面內生成浮窗廣告，這些廣告會嚴重影響用戶體驗。

XSS攻擊可以分為三類：反射型，存儲型，基于DOM型(DOM based XSS)

反射型

惡意腳本作為網絡請求的一部分。

const Koa = require("koa");

const app = new Koa();

app.use(async ctx => {

// ctx.body 即服務端響應的數據

ctx.body = '<script>alert("反射型 XSS 攻擊")</script>';

})

app.listen(3000, () => {

console.log('啟動成功');

});

訪問 http://127.0.0.1:3000/ 可以看到 alert執行

反射型XSS1

舉一個常見的場景，我們通過頁面的url的一個參數來控制頁面的展示內容，比如我們把上面的一部分代碼改成下面這樣

app.use(async ctx => {

// ctx.body 即服務端響應的數據

ctx.body = ctx.query.userName;

})

此時訪問 http://127.0.0.1:3000?userName=xiaoming 可以看到頁面上展示了xiaoming，此時我們訪問 http://127.0.0.1:3000?userName=<script>alert("反射型 XSS 攻擊")</script>, 可以看到頁面彈出 alert。

反射型XSS2

通過這個操作，我們會發現用戶將一段含有惡意代碼的請求提交給服務器，服務器在接收到請求時，又將惡意代碼反射給瀏覽器端，這就是反射型XSS攻擊。另外一點需要注意的是，Web 服務器不會存儲反射型 XSS 攻擊的惡意腳本，這是和存儲型 XSS 攻擊不同的地方。

在實際的開發過程中，我們會碰到這樣的場景，在頁面A中點擊某個操作，這個按鈕操作是需要登錄權限的，所以需要跳轉到登錄頁面，登錄完成之后再跳轉會A頁面，我們是這么處理的，跳轉登錄頁面的時候，會加一個參數 returnUrl，表示登錄完成之后需要跳轉到哪個頁面，即這個地址是這樣的 http://xxx.com/login?returnUrl=http://xxx.com/A，假如這個時候把returnUrl改成一個script腳本，而你在登錄完成之后，如果沒有對returnUrl進行合法性判斷，而直接通過window.location.href=returnUrl，這個時候這個惡意腳本就會執行。

存儲型

存儲型會把用戶輸入的數據“存儲”在服務器。

比較常見的一個場景就是，攻擊者在社區或論壇寫下一篇包含惡意 JavaScript代碼的博客文章或評論，文章或評論發表后，所有訪問該博客文章或評論的用戶，都會在他們的瀏覽器中執行這段惡意的JavaScript代碼。

存儲型攻擊大致需要經歷以下幾個步驟

首先攻擊者利用站點漏洞將一段惡意JavaScript代碼提交到網站數據庫中

然后用戶向網站請求包含了惡意 JavaScript腳本的頁面

當用戶瀏覽該頁面的時候，惡意腳本就會將用戶的cookie信息等數據上傳到服務器

存儲型XSS

舉一個簡單的例子，一個登陸頁面，點擊登陸的時候，把數據存儲在后端，登陸完成之后跳轉到首頁，首頁請求一個接口將當前的用戶名顯示到頁面

客戶端代碼

<!DOCTYPE html>

<head>

<style>

.login-wrap {

height: 180px;

width: 300px;

border: 1px solid #ccc;

padding: 20px;

margin-bottom: 20px;

}

input {

width: 300px;

}

</style>

</head>

<body>

<br>

<br>

</div>

</body>

var btn = document.querySelector('.btn');

btn.onclick = function () {

var userName = document.querySelector('.userName').value;

var password = document.querySelector('.password').value;

fetch('http://localhost:3200/login', {

method: 'POST',

body: JSON.stringify({

userName,

password

}),

headers:{

'Content-Type': 'application/json'

mode: 'cors'

})

.then(function (response) {

return response.json();

})

.then(function (res) {

alert(res.msg);

window.location.href= "http://localhost:3200/home";

})

.catch(err => {

message.error(`本地測試錯誤 ${err.message}`);

console.error('本地測試錯誤', err);

});

}

</script>

</html>

服務端代碼

const Koa = require("koa");

const app = new Koa();

const route = require('koa-route');

var bodyParser = require('koa-bodyparser');

const cors = require('@koa/cors');

// 臨時用一個變量來存儲，實際應該存在數據庫中

let currentUserName = '';

app.use(bodyParser()); // 處理post請求的參數

const login = ctx => {

const req = ctx.request.body;

const userName = req.userName;

currentUserName = userName;

ctx.response.body = {

msg: '登陸成功'

};

}

const home = ctx => {

ctx.body = currentUserName;

}

app.use(cors());

app.use(route.post('/login', login));

app.use(route.get('/home', home));

app.listen(3200, () => {

console.log('啟動成功');

});

點擊登陸將輸入信息提交大服務端，服務端使用變量 currentUserName來存儲當前的輸入內容，登陸成功后，跳轉到首頁，服務端會返回當前的用戶名。如果用戶輸入了惡意腳本內容，則惡意腳本就會在瀏覽器端執行。

在用戶名的輸入框輸入 <script>alert('存儲型 XSS 攻擊')</script>，執行結果如下

存儲型XSS

基于DOM(DOM based XSS)

通過惡意腳本修改頁面的DOM節點，是發生在前端的攻擊

基于DOM攻擊大致需要經歷以下幾個步驟

攻擊者構造出特殊的URL，其中包含惡意代碼

用戶打開帶有惡意代碼的URL

用戶瀏覽器接受到響應后執行解析，前端JavaScript取出URL中的惡意代碼并執行

惡意代碼竊取用戶數據并發送到攻擊者的網站，冒充用戶行為，調用目標網站接口執行攻擊者指定的操作。

舉個例子：

<body>

<br>

</div>

</body>

var btn = document.querySelector('.btn');

var content = document.querySelector('.content');

btn.onclick = function () {

var url = document.querySelector('.url').value;

content.innerHTML = `<a href=${url}>跳轉到輸入的url</a>`

}

</script>

點擊提交按鈕，會在當前頁面插入一個超鏈接，其地址為文本框的內容。

在輸入框輸入如下內容

'' onclick=alert('哈哈，你被攻擊了')

執行結果如下

基于DOM型XSS

首先用兩個單引號閉合調 href屬性，然后插入一個onclick事件。點擊這個新生成的鏈接，腳本將被執行。

上面的代碼是通過執行執行 alert來演示的攻擊類型，同樣你可以把上面的腳本代碼修改為任何你想執行的代碼，比如獲取用戶的 cookie等信息，<script>alert(document.cookie)</script>，同樣也是可以的.

防御XSS

HttpOnly

由于很多XSS攻擊都是來盜用Cookie的，因此可以通過使用HttpOnly屬性來防止直接通過 document.cookie 來獲取 cookie。

一個Cookie的使用過程如下

瀏覽器向服務器發起請求，這時候沒有 Cookie

服務器返回時設置 Set-Cookie 頭，向客戶端瀏覽器寫入Cookie

在該 Cookie 到期前，瀏覽器訪問該域下的所有頁面，都將發送該Cookie

HttpOnly是在 Set-Cookie時標記的：

通常服務器可以將某些 Cookie 設置為 HttpOnly 標志，HttpOnly 是服務器通過 HTTP 響應頭來設置的。

const login = ctx => {

// 簡單設置一個cookie

ctx.cookies.set(

'cid',

'hello world',

{

domain: 'localhost', // 寫cookie所在的域名

path: '/home', // 寫cookie所在的路徑

maxAge: 10 * 60 * 1000, // cookie有效時長

expires: new Date('2021-02-15'), // cookie失效時間

httpOnly: true, // 是否只用于http請求中獲取

overwrite: false // 是否允許重寫

}

)

}

HttpOnly

需要注意的一點是：HttpOnly 并非阻止 XSS 攻擊，而是能阻止 XSS 攻擊后的 Cookie 劫持攻擊。

輸入和輸出的檢查

永遠不要相信用戶的輸入。

輸入檢查一般是檢查用戶輸入的數據是都包含一些特殊字符，如 <、>, '及"等。如果發現特殊字符，則將這些字符過濾或編碼。這種可以稱為 “XSS Filter”。

安全的編碼函數

針對HTML代碼的編碼方式是 HtmlEncode（是一種函數實現，將字符串轉成 HTMLEntrities）

& --> &

< --> <

> --> >

" --> "

相應的， JavaScript的編碼方式可以使用 JavascriptEncode。

假如說用戶輸入了 <script>alert("你被攻擊了")</script>，我們要對用戶輸入的內容進行過濾（如果包含了 <script> 等敏感字符，就過濾掉）或者對其編碼，如果是惡意的腳本，則會變成下面這樣

經過轉碼之后的內容，如 <script>標簽被轉換為 <script>，即使這段腳本返回給頁面，頁面也不會指向這段代碼。

防御 DOM Based XSS

我們可以回看一下上面的例子

btn.onclick = function () {

var url = document.querySelector('.url').value;

content.innerHTML = `<a href=${url}>跳轉到輸入的url</a>`

}

事實上，DOM Based XSS 是從 JavaScript中輸出數據到HTML頁面里。

用戶輸入 '' onclick=alert('哈哈，你被攻擊了')，然后通過 innerHTML 修改DOM的內容，就變成了 <a href='' onclick=alert('哈哈，你被攻擊了')>跳轉到輸入的url</a>, XSS因此產生。

那么正確的防御方法是什么呢？

從JavaScript輸出到HTML頁面，相當于一次 XSS輸出的過程，需要根據不同場景進行不同的編碼處理

變量輸出到 <script>，執行一次 JavascriptEncode

通過JS輸出到HTML頁面

輸出事件或者腳本，做 JavascriptEncode 處理

輸出 HTML內容或者屬性，做 HtmlEncode 處理

會觸發 DOM Based XSS的地方有很多，比如

xxx.interHTML

xxx.outerHTML

document.write

頁面中所有的inputs框

XMLHttpRequest返回的數據

...

項目中如果用到，一定要避免在字符串中拼接不可信的數據。

利用CSP

CSP (Content Security Policy) 即內容安全策略，是一種可信白名單機制，可以在服務端配置瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則，如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。

通常可以通過兩種方式來開啟 CSP：

設置 HTTP Header 的 Content-Security-Policy

Content-Security-Policy: default-src 'self'; // 只允許加載本站資源

Content-Security-Policy: img-src https://* // 只允許加載 HTTPS 協議圖片

Content-Security-Policy: child-src 'none' // 允許加載任何來源框架

設置 meta 標簽的方式

« 2020的UI設計趨勢，我先收藏了（上）如何選擇設計需求分析結果？ »

web安全之XSS實例解析

分類

日歷

鏈接

個人資料

存檔