常見網站資安問題與防禦方法(後端角度)
SQL injection, xss, csrf, json hijacking
SQL injection(SQL注入)
簡介：
網站可以接受資料的輸入，若輸入後接著會將輸入的資料用來訪問資料庫時，直接組合查詢句可能會導致原本的語意不同，進而偷竊或破壞資料庫裡面的資料。
例子：
在登入時，如果SQL的內容是需要同時滿足以下條件才能夠登入
// <username> 以及 <password>是變數
account = <username> and password = <password>但惡意攻擊者刻意在輸入帳號密碼時輸入
帳號： '1 or "1" = "1"'
// 密碼以此類推於是對於資料庫來說變成需要同時滿足
- account = 1 OR 1=1
- password = 1 OR 1=1
重點變成不在乎帳號密碼各是什麼，而是後面的「OR 1=1」讓帳號密碼在OR的條件下可以直接被通過，就可以直接登入了。
後端防禦：
- (優先使用!!)不要使用組字串方式查詢SQL，改為使用參數化查詢，參數化查詢簡單來說就是讓SQL預先把除了參數的部分都先執行了，留下參數的地方，這樣在輸入資料時，就會把輸入的資料都當成是要查詢的內容，而不會誤以為是SQL的正文。
// 這是一般的 SQL 注入
SELECT * FROM users where id = <id>// 這是參數化查詢，在MySQL中以?字符搭配參數名稱
SELECT * FROM users where id = ?id
- 使用ORM，就會在底層幫你實作類似的防禦機制。
- 系統上線後不要有super user，意思是說使用者僅能使用讀、寫功能。
參考資料：
XSS (cross-site scripting) 跨網站指令攻擊
簡介：
網站被惡意植入其他程式碼，最容易發生在論壇、部落格等。
例子：
比如今天有一個部落格可以留言，而惡意攻擊者在留言的地方輸入了撰寫了<img src="惡意攻擊">，你有可能覺得很可愛，想要點擊並放大時，就受到攻擊了。
另外一個例子來自這裡：
比前面那個還防不勝防，他插入這個到有需要輸入密碼的頁面，當你按下enter時，自動觸發onfocusout，進而將你的密碼傳給了http://localhost，這是你根本沒有亂點圖片之類並正常使用網頁也會遇到的狀況。
詳細有分為儲存型、反射型、DOM-based型，以後再來細細了解(埋坑…)
後端防禦：
- 儲存型、反射性：
對於輸入內容做檢查，對於輸入的內容要一概刪除所有script或其他所有可能執行code的字串。
(參考xss-npm套件) - 補充(前端)：DOM-based
盡量使用innerText取代innerHTML這樣輸入的內容就會被當成純粹的字串了。
參考資料：
csrf(cross-site request forgery) 跨站請求偽造
簡介：
維基百科定義下的好：XSS利用的是使用者對指定網站的信任，CSRF利用的是網站對使用者瀏覽器的信任。
跨站請求偽造指的是利用cookie對於同個domain的網站一定會夾帶的特性，欺騙使用者的瀏覽器去對曾經認證過的網站進行操作。
再次引用維基：簡單的身分驗證只能保證請求發自某個使用者的瀏覽器，卻不能保證請求本身是使用者自願發出的。
例子：
攻擊者架設惡意網站(A方)，但裡面夾帶對受害網站(B方)的請求(可能是隱藏的form表單)，受害使用者(C方)進入惡意網站後，點擊該某一按鈕送出了對於受害網站的請求，而後因為cookie的特性，受害網站認為這個請求來自於使用者瀏覽器(但無法辨認是不是使用者自願發送)，於是便通過認證對資料進行執行，可能造成的後果包括取得使用者需要登入後才能取得的隱私資料、權限操作(投票)，或一些對資料的破壞性操作。
另外一個有趣的例子是XSS搭配CSRF進行攻擊，透過XSS植入CSRF攻擊程式碼，甚至就可以不用架站，例如使用者對於該網站的信任就可以讓CSRF攻擊變得更容易許多。
後端防禦：
- (推薦)CSRF token：針對這類的攻擊，將form表單發送給使用者時，加上由伺服器產生的token(比如使用input hidden並夾帶 value = token)，所有的表單請求進到伺服器時，對表單內的token進行驗證，因為這個token內容只有伺服器知道，攻擊者無法夾帶合法token，攻擊就無法成功。
- 檢查refererx欄位：HTTP header中有一個欄位稱作referer，用以標明請求來源來自哪個位址，處理敏感請求時，referer的位址應該和request的目標位址相通，比如www.hacker.com夾帶的www.example請求，referer欄位(www.hacker.com)就會和請求位址(www.example)不同。
此方法簡單，但風險就是無法保證其他人沒有竄改referer的可能性。
參考資料：
json hijacking
簡介：
簡單來說就是覆寫Array()這個函式，因為Array有個神祕的特性是收到後可以直接執行，具體可以透過eval()函式實驗，eval函式會將傳入的字串當作JS code 執行。(範例參考此連結)
eval('{"x":"y"}'); //Uncaught SyntaxError: Unexpected token ':'
eval('[1,2,3]'); //不會有 Error不過這已經是過去的事情，原本各大瀏覽器都已經防堵這個漏洞，讓駭客無法透過__defineSetter__來覆寫簡單型別(Primitive Type)的JS物件，藉以讓Array這個可以被直接執行的東西不能被覆寫。
但因為ES6後出現新的語法 Proxy物件，又多了一個叫做setPrototypeOf的東西可以修改Array，簡單說proxy有點像是在程式之前新增一層程式碼，所有對於Proxy指定的物件的訪問都要先經過這層過濾，有沒有想到什麼?沒錯，透過Proxy，Array又再一次慘遭毒手。
例子(連結)：
// 舊版
<script type="text/javascript">
var o = [];
Object.prototype.__defineSetter__('Id', function (obj) {
console.log(obj);
});
Object.prototype.__defineSetter__('Balance', function (obj) {
console.log(obj);
});
</script>
<script id="myJson" type="application/json" src="http://mywebsite.com/getjson"></script>
// 新版Proxy
<!doctype HTML>
<script>
Object.setPrototypeOf(__proto__,new Proxy(__proto__,{
has:function(target,name){
alert(name.replace(/./g,function(c){ c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff); }));
}
}));
</script>
<script charset="UTF-16BE" src="external-script-with-array-literal"></script>
舊版的意思是，只要某一屬性被賦值就會啟動後面的函式，於是此意思就是說當Id或Balance被賦值時就會把該物件資料印在console.log上。
新版的…恕我暫時無法理解Orz
後端防禦：
- (推薦!!)API不要直接使用JSON陣列，改用JSON物件
- 有看到其實他為了要取得資料還是需要使用src，所以也是參考了CSRF的攻擊方式，但改用script去處理抓到的陣列資料，於是可以在重要、敏感資料上面加上csrf token去避免這件事情、或使用POST方法。
- Facebook有用一個有趣的方法是在返回的資料最前面加上無限迴圈。
參考資料：
基本型：
- 重要資訊以Https加密或雜湊提高破解的難度及時間成本。
- 檔案上傳漏洞：
如果沒有限制使用者上傳的副檔名，在後台就有打開到惡意的程式碼；另外SVG這個特殊的圖片檔名，因為他可以寫入HTML甚至可以寫入onload事件，權限開這麼大，能做的事情就多了。
資安學習路徑
簡單且概略的介紹幾種資安的風險以及防禦的方式，根據可靠消息，想要Level up，靠的就是你也當hacker，來自於IT邦幫忙的初學者入門CTF，我自己還沒來的及試玩，試玩過後說不定又是一篇blog：
比賽：
https://ctflearn.com/
https://bamboofox.cs.nctu.edu.tw/
https://hackme.inndy.tw
http://pwnable.kr/play.php
社群：
tdohacker : https://www.facebook.com/tdohacker
閱讀：
重要聲明：
寫完之後覺得太像是整理各地的資訊，並備份起來的感覺，特別是最後一段資安學習路徑XD，幾乎完整照搬…有太多是參考其他網站大大們的內容了，所有有參考到的內容我都有附註參考資料或直接在該文字後面加上連結，如果有大大希望撤掉某部分內容請聯繫我，我會立刻處理。
