作web開發的時候，很少對深層次的安全性進行考慮，國內現在的氛圍也不是太好，讀書的時候總是會逛烏雲，後面工作一直也沒怎麼考慮，都是依靠框架去解決問題。但是由於安全部門對我們的**檢測比較多，雖然都是指令碼檢測的，但是依舊鬧出了很多事情，需要處理
處理的辦法，指令碼掃瞄一般都是掃瞄框架漏洞，或者字串，還有xml包處理的一些問題。處理起來並不複雜，通常是公升級，加過濾，加判斷。這些指令碼都能通過。
但是假如我自己現在突然成為程式的壞人，我是否能攻破我們的系統了？我思考了一下，我覺得完全沒問題，給我乙個基礎賬號，基本上可以更改任何資料了，因為我們的介面判斷並沒有做許可權控制，只要是乙個有敵意的公司，如果真想給我們麻煩，我們肯定是沒辦法的。這也是現在常見的web開發人員的乙個素質的缺失。或者說產品已經迭代了很久了，很難去動**去改。
有一種方法叫做ip限制，這種方法簡直是無腦至極，但是又非常有效，能乾掉大部分的惡意指令碼，對後台的攻擊。但是這樣子侷限性非常大，這是國企的erp常見的使用方式，不考慮使用人的友好性。
我們現在會從三個角度出發
前端的介面無法改變，以前也沒有做check，我們用node或者其他封裝乙個中間層出來，作為介面的**，在這層check和防止攻擊
後端的加日誌，ip，做異常監控，為什麼不ip限制？不能做，做了異常有什麼好處了？其實很少人會去攻擊，然後做了日誌，後面就可以去查，恢復。一種亡羊補牢的手段
重構**，先把本來不用暴漏的介面暴漏出去的先給改回來，比如說a->b是非暴漏，但是b->c是暴漏的，導致a是暴漏的。b這裡就是乙個豬隊友。之前加日誌了，因為做的是aop，那麼我這裡同樣也可以改改，加功能成功為安全攔截，但是這裡我還沒有完全改好的原因是，工作量太大，並且最主要是怕出問題，一出問題，就**了，所以改的小心翼翼
WEB開發時的一些思考
這星期在整理工程的文件。發現一些問題。1 dao層應該進行具體的操作還是抽象程度高的操作？抽象程度越高，復用的可能性就越大。但是效率上確實眼睜睜看著它提高不了。2 dao層的操作應該事先準備完整的 增刪改查 還是等用到的時候再針對性的增加？由於當初在開始建立工程時，時間緊迫而且需求不清晰，所以dao...
對於api安全性的思考
目前的情況下api被很多地方應用，隨之而來的是api的安全性問題。我所認識到的安全性問題有以下幾個方面 1 ddos 拒絕服務攻擊 介面被惡意呼叫，使真實的使用者無法享受到正常暢通的服務。這個比較單純，也比較容易處理，通過ip限制來做，並且輔以一些硬體裝置應該就沒問題了，同時伺服器 商也可以提供相應...
Web獲取的一些思考
幫朋友做乙個天氣預報的web獲取的方式。之前是使用分析xml的方法去分析html，有點類似閱讀網頁原始碼的味道去獲取資料。這樣的好處是比較有邏輯性。而且直接獲取標籤的值，不像直接處理字串的方式那麼原始。壞處，如果網頁標籤有所變得，程式需要可能要重寫。另一種辦法，是我在嘗試的，使用正規表示式。這樣有乙...