一般**開發人員的學習大體路子應該是
開發動態**一般情況下都會涉及到使用者、許可權這些安全層面的東西，如何確保自己的**是乙個相對安全的**呢？
是否覺得自己做的**好像沒有什麼漏洞，因為demo啊，docs啊都沒有提及這方面，都是說應該怎麼做，但同時又總有些不放心，隱隱約約覺得怕出問題，
只好盲目的以為框架會帶來一定的安全性，自己可能不需要知道太多。但是在剛剛剛接觸了幾篇安全的文章我也才發現，如果做法出了問題，安全漏洞自然就會出現，
框架在安全性上幾乎沒有什麼太大的貢獻。
一切的模糊、不放心和盲目都是由於自己對網路安全，狹義點說，網路應用安全知識的匱乏導致的，所以從今天開始，我的學習圖譜裡也要開始增加這方面的知識了。
現在開始翻譯owasp 2013 top ten安全問題。
作為學習之用，翻譯有誤之處請指正，為了快速理解，翻譯順序可能不是按照owasp的順序來的
威脅載體：
考慮你的系統中的使用者型別，是否某些使用者只對某些特定型別的系統資料有訪問許可權？
攻擊媒介：
攻擊者是已經授權的系統使用者，通過簡單地改變乙個系統直接引用的物件到另乙個該使用者無許可權的物件上，是否就允許訪問了？
安全弱點：
當生成web頁面時應用經常使用乙個物件的準確名字或者鍵值。應用不經常檢查使用者是否對該目標物件有許可權。這是由於乙個不安全的直接物件引用漏洞導致的。
測試者可以很容易的操縱引數值去發現此類漏洞。**分析可以很快速的展現出許可權是否被正確的驗證了。
技術影響:
此種漏洞可以威脅到所有可以通過引數引用的資料。除非物件的引用是不可預知的。攻擊者很容易訪問到某個型別的所有資料。
業務影響:
考慮暴露資料的商業價值，同時漏洞公開後造成的商業影響
攻擊場景舉例：
應用程式在sql呼叫中使用未經過檢查的資料去訪問使用者資訊
string query = "select * from accts where account = ?";
preparedstatement pstmt = connection.preparestatement(query , … );
pstmt.setstring( 1,request.getparameter("acct"));
resultset results = pstmt.executequery( );
攻擊者在他們的瀏覽器中簡單的修改"acct"引數傳送任何他們想要的賬戶數字。如果不經檢驗，攻擊者可以訪問任何使用者的賬戶，而不是預期客戶的賬戶。
我是否在「不安全的直接物件引用」漏洞上容易被攻擊？
找出乙個應用程式在"不安全的直接物件引用"中是否存在漏洞的途徑就是確保所有物件的引用已經被適當防禦了。這做到這點，需要考慮：
1.對保密資源的直接引用中，應用是否沒有驗證使用者是否有權訪問他們所請求的資源？
2.如果引用是乙個非直接引用，是否其到直接引用的對映沒有為當前使用者限制那些授過權和沒授過權的值。
**評審可以快速檢查出這兩種做法是否是被安全地實現的。測試也對識別直接物件引用是否安全有效。自動檢測工具通常不檢查此種漏洞，
因為它們無法識別出什麼需要保護或者什麼是安全或者不安全的
我們應該怎麼做？
防止不安全直接物件引用要求選擇一種方法去保護每個使用者可訪問的物件(例如：物件數量，檔名稱)：
1.使用每個使用者或每個session非直接物件引用。這可以防止攻擊者直接命中未授權資源。例如，為當前使用者使用乙個包含6個已授權資源的下拉列表，可以使用1到6去指定使用者所選擇的那個資源，而不是直接使用資料庫鍵去指定。應用需要在伺服器上把
每個使用者的非直接引用
對映到具體的資料庫鍵。owasp的esapi包含順序和隨機2中引用對映，開發人員可以使用它去消除直接物件引用
2..檢查訪問。 對於每個使用者，每次使用來自不受信任**的直接物件引用必須包括乙個訪問控制檢查，以確保使用者對請求的物件有授權
通過工作中的乙個例子舉例加深理解：
場景：比如我有乙個已經登入的使用者，其userid記錄在session中，使用者通過userid去查詢他所有的文章
比如查詢鏈結形式
在後台如果我只檢查了此使用者是否登入，也就是檢查session中的userid是否為空，不為空，則直接使用userid去資料庫查詢，
這就是乙個不安全的直接引用。
如何讓這種直接引用變安全呢？
1.讓userid加密，在後台解密，之後再去資料庫中使用解密的userid去查詢，這樣使用者無法從頁面上直接傳入恰當的引數去找到想要的使用者的資料。
2.在查詢資料庫之前，我需要對比這個通過連線傳進來的userid是否和session中記錄的userid一致，不一致就拒絕請求，不允許其訪問不屬於此使用者的資料。
相比之下我還是覺得第二種做法是更好的。
IDOR 不安全的直接物件引用
測試前 先確認測試範圍 確定測試物件，需要dev協助 再手動驗證 確認，最後確定是否需要優化 驗證方法 通過修改用於直接指向物件的引數值直接訪問 影響 可以繞過許可權，直接訪問系統的資源 但這些資源可以是屬於其他使用者的資料庫條目 系統中的檔案等等 原因 這是因為應用程式接受使用者提供的輸入並使用它...
不安全的物件引用 垂直越權
該系統僅允許註冊社工賬號，此賬號許可權極低，無法檢視任何資訊，嘗試通過不安全的物件直接引用漏洞來獲取高許可權賬號。1.首先判斷出，社工與區管理員登入時使用者名稱識別的引數存在什麼不同 經抓包對比測試得知，社工賬戶和區管理員賬戶userinfobean.usertype的引數不同，社工賬戶 useri...
執行緒不安全
背景 執行緒不安全 sleep 模擬網路延遲 後多執行緒併發訪問同乙個資源 方法1 同步 塊 語法 synchronized 同步鎖 catch interruptedexception e 方法2 同步方法 使用synchronizd修飾的方法，就叫同步方法，保證a執行緒執行該方法的時候，其他執行...