常見Web漏洞

1.SQL注入

漏洞成因

• 直接使用SQL陳述句拼接，將用戶傳入的引數通過字串拼接的方式傳入查詢陳述句，
  示例：String sql = "select * from test where id = " + id;
• 預編譯使用有誤，沒有呼叫 set 方法將變數與占位符進行對應，
  示例：

String sql = "select * from test where id = ?";
PreparedStatement pstt = conn.prepareStatement(sql);
// pstt.setObject(1,id);

• 對 % 和 _ 沒有進行顯示處理， 導致用戶可以自行拼接進行模糊查詢，
• 不能引數化的位置，還是有可能存在拼接的情況，如order by后面，
  示例：String sql = "select * from test where id = ? order by '" + time + "' asc";
• Mybatis中，#{}是預編譯處理，${}是字串替換，使用${}就可能導致SQL注入，
  示例：Select * from news where title like '%#{title}%'

審計策略

• 重點關注創建查詢的函式如 createQuery()、createSQLQuery()、createNativeQuery()，
• 定位SQL陳述句背景關系，查看是否有引數直接拼接，是否有對模糊查詢關鍵字的過濾，
• 是否使用預編譯技術，預編譯是否完整，關鍵函式定位setObject()、setInt()、setString()、setSQLXML()關聯背景關系搜索set*開頭的函式，
• Mybatis中搜索${}，因為對于like模糊查詢、order by排序、范圍查詢in、動態表名/列名，沒法使用預編譯，只能拼接，所以還是需要手工防注入，此時可查看相關邏輯是否正確，
• JPA搜索JpaSort.unsafe()，查看是否用物體之外的欄位對查詢結果排序，進行了SQL的拼接，以及查看EntityManager的使用，也可能存在拼接SQL的情況，

修復

正確使用預編譯；無論是 SQL/HQL/JPQL，都不進行SQL陳述句字串拼接；正確理解占位符、預編譯、替換、引數注入等形式的使用

2.XXE

漏洞成因

• XML檔案結構包括XML宣告、DTD檔案型別定義（可選）、檔案元素，檔案型別定義(DTD)的作用是定義 XML 檔案的合法構建模塊，DTD 可以在 XML 檔案內宣告，也可以外部參考，當允許參考外部物體時，惡意攻擊者即可構造惡意內容訪問服務器資源，
  示例：

<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE root [
        <!ENTITY xxe SYSTEM "file:///tmp/aaa">
       ]>
    <root>&xxe;</root>

• 使用不可信資料來構造XML會導致XML注入漏洞，如果用戶被允許輸入結構化的XML片段，則他可以在XML的資料域中注入XML標簽來改寫目標XML檔案的結構與內容

Java中的XXE支持以下協議：http，https，file，ftp，mailto，jar，netdoc，可以利用file協議讀取檔案，利用http協議探測內網，沒有回顯時可組合利用file協議和ftp協議來讀取檔案，如果存在報錯的情況下還可以嘗試使用報錯XXE進行敏感資訊的獲取，甚至是嘗試遞回呼叫造成拒絕服務攻擊，

審計策略

XML決議涉及的業務功能點： WebServices介面、RESTful介面、Excel檔案決議、Soap協議等，

漏洞觸發點就在XML決議時，因此重點審計XML決議器是否設定了相關的安全屬性，禁用DTDs或者禁止使用外部物體，還有是否使用了不安全的漏洞組件，部分決議器如下：

javax.xml.parsers.DocumentBuilder
javax.xml.parsers.DocumentBuilderFactory
javax.xml.stream.XMLStreamReader
javax.xml.stream.XMLInputFactory
org.jdom.input.SAXBuilder
org.jdom2.input.SAXBuilder
org.jdom.output.XMLOutputter
oracle.xml.parser.v2.XMLParser
javax.xml.parsers.SAXParser
org.dom4j.io.SAXReader 
org.dom4j.DocumentHelper
org.xml.sax.XMLReader
javax.xml.transform.sax.SAXSource 
javax.xml.transform.TransformerFactory 
javax.xml.transform.sax.SAXTransformerFactory 
javax.xml.validation.SchemaFactory
javax.xml.validation.Validator
javax.xml.bind.Unmarshaller
javax.xml.xpath.XPathExpression
java.beans.XMLDecoder

修復

為了防御XXE漏洞, 較為有效的處理方式是開發者在不影響系統業務的前提下做好安全配置，如果系統業務需要參考外部物體，應在后端做好引數校驗，此外，有許多第三方組件曾被爆出XXE漏洞（例如，Spring-data-XMLBean、JavaMelody組件XXE、Apache OFBiz.微信支付SDK-XXE ）,關注這類安全問題，避免因為使用第三方組件而引入XXE漏洞，

3.XSS

漏洞成因

對于用戶傳遞引數，沒有進行過濾，導致惡意攻擊者可以插入一些惡意的js陳述句、標簽、frame等來獲取應用或用戶的敏感資訊，

審計策略

審計程序要點還是定位用戶的輸入輸出，也就是梳理資料互動以及前端展示的程序，找到一條完整的利用鏈之后，就是結合現有的安全措施（輸出編碼、過濾器等）進行判斷，例如是否存在繞過的可能，或者是沒有任何安全防護可直接造成攻擊，

下面是一些可以快速定位的關鍵字：

<%=
${
<c:out
<c:if
<c:forEach
ModelAndView
ModelMap
Model
request.getParameter
request.setAttribute

一般會使用全域的Filter進行xss的過濾，但通常可能存在漏網之魚，所以也需要審計全域過濾規則是否完善，可以通過關鍵字 XssFilter 進行搜索，

如何修復

自定義全域過濾器，對用戶提交輸入進行檢查和過濾；對用戶輸入并用來展示的資料進行HTML轉義，可用的工具類包括org.springframework.web.util.HtmlUtils 、org.apache.commons.lang3.StringEscapeUtils、ESAPI.encoder().encodeForHTML 等，

4.命令執行

漏洞成因

由于業務需求，應用程式可能含有執行系統命令的功能，如果執行的命令任意用戶可控，則將產生極大的危害，

審計策略

重點關注能執行命令的一些功能及函式：

Runtime.getRuntime().exec()
Process
UNIXProcess
ProcessImpl
ProcessBuilder.start()
GroovyShell.evaluate()

如何修復

避免使用這樣的功能，如必須，待執行命令盡量不由用戶傳入，

5.SSRF

漏洞成因

SSRF形成的原因大都是由于代碼中提供了從其他服務器應用獲取資料的功能但沒有對目標地址做過濾與限制，比如從指定URL鏈接獲取圖片、下載等，

審計策略

出現SSRF漏洞的主要業務有：

• 通過URL地址分享網頁內容
• 在線服務
• 通過URL地址加載或下載圖片
• 加載遠端配置

重點關注一些HTTP請求操作函式：

om.alibaba.druid.util.HttpClientUtils
sun.net.www.http.HttpClient
javax.net.ssl.HttpsURLConnection
sun.net.www.protocol.http.HttpURLConnection
java.net.HttpURLConnection
javax.servlet.http.HttpServletRequest
java.net.URI
java.net.URL
java.net.URLConnection
com.bea.uddiexplorer.Search
com.squareup.okhttp.Request
com.squareup.okhttp3.Request
org.apache.commons.httpclient.HttpMethodBase
org.apache.http.client.methods.HttpRequestBase

除了建立HTTP協議連接，還可能直接通過 Socket建立連接，因此應該同樣關注Socket相關類：

AsynchronousServerSocketChannel.accept/bind
AsynchronousSocketChannel.write/read/bind/connect
ServerSocketChannel.bind
ServerSocket.accept/bind
Socket.bind/connect
Socket.getInputStream().read
Socket.getOutputStream().write
SocketChannel.bind/read/write/connect

如何修復

• 使用白名單校驗HTTP請求url地址，例如通過InetAddress物件的isSiteLocalAddress()方法進行判斷，禁止內網地址的網路請求，
• 避免將請求回應及錯誤資訊回傳給用戶
• 禁用不需要的協議及限制請求埠

6. 檔案上傳

漏洞成因

檔案上傳時，由于校驗不全、限制不當，可能導致被上傳webshell、拒絕服務、任意檔案寫入等安全問題，

審計策略

• 首先關注檔案后綴驗證，使用白名單或黑名單，建議使用白名單，使用lastIndexOf()方法獲取檔案后綴，使用IndexOf()可能被繞過，如果是白名單驗證時，使用toLowerCase()處理再進行對比，或使用equalsIgnoreCase()，避免被大小寫繞過，
• 是否校驗了檔案的大小，
• 是否校驗了檔案型別getContentType()，這種方式雖然能夠被繞過，但還是會增加攻擊成本，
• 對于使用Hutool的FileTypeUtil的getType()或ImageIO.read()通過讀取檔案流中前N個byte值來判斷檔案型別的，也可以使用類似圖片馬的方式進行繞過，
• "%00"截斷能否繞過，
• QP編碼特性能否繞過，javax.mail.internet.MimeUtility.encodeWord()方法，
• 有一些安全校驗的順序有問題，先將檔案保存，再進行安全檢測，如果不通過檢測則進行洗掉，此時可以在檔案保存后觸發報錯終止流程，導致不洗掉檔案，
• 對于檔案操作漏洞的挖掘還可以結合黑盒測驗來尋找入口點去審計，有時直接從介面入手能更快速地發現檔案操作中可能出現的問題，

重點是檔案上傳相關類或函式：

FileUpload
FileUploadBase
FileItemIteratorImpl
FileItemStreamImpl
FileUtils
UploadHandleServlet
FileLoadServlet
FileOutputStream
DiskFileItemFactory
MultipartRequestEntity
MultipartFile
com.oreilly.servlet.MultipartRequest

如何修復

對上傳檔案后綴進行白名單驗證，驗證檔案大小，強制重命名后綴，上傳檔案單獨服務器保存，

7. 任意檔案操作

漏洞成因

應用程式由于業務需求，提供了檔案操作的一系列功能，但檔案名、檔案路徑等由用戶控制，在校驗不當的情況下，用戶可以繞過限制對服務器上任意檔案進行操作，

審計策略

首先關注包含這些功能的類和函式：

sun.nio.ch.FileChannelImpl
java.io.File.list/listFiles
java.io.FileInputStream
java.io.FileOutputStream
java.io.FileSystem/Win32FileSystem/WinNTFileSystem/UnixFileSystem
sun.nio.fs.UnixFileSystemProvider/WindowsFileSystemProvider
java.io.RandomAccessFile
sun.nio.fs.CopyFile
sun.nio.fs.UnixChannelFactory
sun.nio.fs.WindowsChannelFactory
java.nio.channels.AsynchronousFileChannel
FileUtil/IOUtil
filePath/download/deleteFile/move/getFile

在使用這些函式時，對于用戶傳遞來的檔案物件/檔案名/檔案路徑，是否進行了正確的處理：

• 是否限制了可操作檔案的路徑、檔案型別、檔案所有者，
• 是否將敏感檔案進行排除，
• 查找getPath(), getAbsolutePath()，查看是否有錯誤的路徑判斷，

再排查程式的安全策略組態檔，全域搜索permission、Java.io.FilePermission、grant字樣，查看是否只為程式的某部分路徑賦予讀寫權限，

如何修復

• 對要操作的檔案名進行黑白名單限制，
• 對用戶輸入的資料進行過濾，過濾掉"./"、"…/"、"%"、"/"
• 針對不同的功能，將可操作檔案路徑限制在某個目錄內，禁止攻擊者通過 '../'的方式穿越路徑，建議使用getCanonicalPath()標準化路徑，之后再進行限制和判斷，
• 使用 FilePermission 限制權限，

8. URL重定向

漏洞成因

由于Web站點有時需要根據不同的邏輯將用戶引向到不同的頁面，如典型的登錄介面就經常需要在認證成功之后將用戶引導到登錄之前的頁面，整個程序中如果實作不好就可能導致URL重定向問題，攻擊者構造惡意跳轉的鏈接，可以向用戶發起釣魚攻擊，

審計策略

出現URL重定向主要的功能有：

• 用戶登錄、統一身份認證處，認證完了會通過url=的形式跳轉到類似操作的頁面，
• 用戶分享、收藏內容后跳轉，
• 跨域認證授權后進行跳轉，

一些相關函式及關鍵字：sendRedirect、setHeader、forward、redirect:、<c:redirect、self.location.href、location.href、windows.location.href等，
一些常見的引數名稱：redirect、redirect_do、redirect_url、url、jump、jump_to、target、to、link、domain等，

審計的思路為定位可能存在redirect業務的代碼段，審計跳轉的URL是否來自于前端引數，是否具有校驗和限制，

如何修復

對傳入的URL做認證處理，保證該URL來自于信任域，例如如下方式：

• 通過限制Referer保證將要跳轉URL的有效性，避免攻擊者生成自己的惡意跳轉鏈接，
• 加入有效性驗證Token，保證所有生成的鏈接都來自于可信域，通過在生成的鏈接里加入用戶不可控的Token對生成的鏈接進行校驗，

關鍵引數前端不可控，
對跳轉的URL進行白名單檢查

9.敏感資訊泄露

漏洞成因

在開發中，可能使用各種各樣的框架、組件，由于配置不當或使用有誤，將可能導致泄露服務器的敏感資訊，
例如：swagger 介面檔案、Hystrix 監控面板、DWR 框架、druid監控平臺等等，

審計策略

重點審計系統使用的框架、組件，根據經驗查看配置，配置是否有誤、是否將除錯功能正式上線到生產環境中等，

如何修復

在使用敏感功能，或框架、組件提供了管理頁面、除錯介面時，為此類功能設定訪問權限校驗，

10.代碼執行/運算式執行

漏洞成因

在Java中的代碼執行漏洞通常不常見，因為在jdk9之前的Java并不提供eval功能，想要執行任意代碼，就要動態編譯，或使用反序列化、自定義ClassLoader、結合JNDI服務、SPI機制等功能完成的任意代碼執行能力，這種方式一般是安全研究員研究用于區別于傳統的命令執行webshell用，平常在開發時很少會遇見此類功能，可參考這里，

相比之下，更常見的是各種運算式的執行，包括但不限于 SpEL、OGNL、MVEL2、EL等，在不同的環境下程式和框架可能使用了不同的運算式決議/模板引擎，在使用和配置有誤的情況下，將導致任意運算式執行，

審計策略

重點審計具有加載類、反序列化類、對類位元組碼進行操作的功能和代碼，關鍵字如下：

eval
classLoader
$$BCEL$$
ServiceLoader
ToolProvider.getSystemJavaCompiler()
getSystemClassLoader
JavaFileObject
JdbcRowSetImpl
TemplatesImpl
TransformerFactoryImpl
resolveClass
loadClass
javax.el.ELProcessor
SpelExpressionParser

同時關注程式中使用的運算式決議組件和框架，

如何修復

在非必要情況下，避免業務中出現此類功能，或對資料源進行嚴格校驗，

11.反序列化

漏洞成因

• Java程式使用ObjectInputStream物件的readObject()方法將反序列化資料轉換為java物件，如果被反序列化的物件重寫了readObject()方法，則會執行該物件的此方法，因此，當輸入的反序列化的資料可被用戶控制，那么攻擊者即可通過構造惡意輸入，讓反序列化產生非預期的物件，在此程序中執行構造的任意代碼，
• 反序列化一個類時，通常會伴隨呼叫 get/set 方法注入引數，并為這個類創建一個新的實體化物件，因此會執行構造方法及靜態代碼塊，在這種情況下，攻擊者也可以挖掘gadget來執行危險的動作，
• 根據權限最小化原則，一般情況下反序列化的類中的readObject()、writeObject()、readResolve()、writeReplace() 方法必須被宣告為 private void，否則如果 Serializable 的類開放 writeObject 函式為 public 的話，給非受信呼叫者過高權限，潛在有風險，
• 在 Java 環境中，允許處于不同受信域的組件進行資料通信，從而出現跨受信邊界的資料傳輸，如果反序列化類中存在未加密的敏感資料，將面臨泄露或被篡改的風險，
• 對非靜態內部類的序列化依賴編譯器，且隨著平臺的不同而不同，容易產生錯誤，對內部類的序列化會導致外部類的實體也被序列化，這樣有可能泄露敏感資料，

審計策略

反序列化操作的功能位置：匯入模版檔案、網路通信、資料傳輸、日志格式化存盤、物件資料落磁盤或DB存盤等業務場景，

可以通過對網路抓包尋找序列化資料：java序列化的資料一般會以標記（ac ed 00 05）開頭，base64編碼后的特征為rO0AB，

一些服務的傳輸可能存在反序列化：多平臺HTTP通信、RMI、JMX，

一些反序列化觸發點：

ObjectInputStream.readObject
ObjectInputStream.readUnshared
XMLDecoder.readObject
Yaml.load
XStream.fromXML
ObjectMapper.readValue
JSON.parseObject

主要查看這些觸發點的引數是否由用戶可控，

全域搜索是否具有public權限的一些方法：public * writeObject/readObject/readResolve/writeReplace，

查看反序列化類中是否包含敏感資料，

全域查找implements Serializable 的所有內部類，

如何修復

• 對要反序列化的物件設定黑白名單，像 fastJSON、Jackson這種官方會維護一個黑名單，持續更新，但還是建議使用白名單，可通過Hook函式resolveClass()來校驗反序列化的類從而實作白名單校驗；也可以使用Apache Commons IO Serialization包中的ValidatingObjectInputStream類的accept()方法來實作反序列化類白/黑名單控制，
• 對于一些敏感的屬性，將其宣告為 transient，或進行加密處理，
• 避免內部類的序列化，或把內部類宣告為靜態，但還是要注意敏感資訊的問題，

業務漏洞

1.越權漏洞

漏洞成因

• 在應用程式處理當前用戶請求時，沒有對用戶權限進行校驗，或校驗不足、失效，導致低權限用戶使用高權限功能，或同權限用戶操作對方資料，
• 對用戶的身份標識資訊從可偽造的引數或headers中獲取，而不是從session中獲取的話，可能存在越權，
• 一些跨域的服務導向架構，尤其是一些資料處理的介面，如果缺少類似token的認證機制的話，也會存在類似的越權訪問問題，
• 越權漏洞在許多Java框架中也存在很多，如Shiro，Spring等，可以多了解
• 業界常將典型的越權漏洞劃分為橫向越權與縱向越權這兩類

橫向越權

橫向越權指權限平級的兩個用戶之間的越權訪問，比如一個普通的用戶A通常 只能夠對自己的一些資訊進行增、刪、改、查，但是由于開發者的疏忽大意，Web應用在對資訊進行增、刪、改、查時未判斷所操作的資訊是否屬于對應的用戶，因 而導致用戶A可以操作其他平級用戶的資訊，

縱向越權

縱向越權指的是權限不等的兩個用戶之間的越權操作，通常是低權限的用戶可以直接訪問到高權限的用戶資訊，

審計策略

針對系統任意功能都可能存在越權，審計關注的是:

• 操作是否需要身份標識或其他標識，
• 此標識是否由用戶可控，
• 是否能夠可猜解，不同主體的標識是否具有規律性，
• 查詢資訊場景下，資訊是否與身份標識進行系結，
• 對應處理的函式方法中是否使用注解或其他方式對當前用戶進行權限校驗，
• 校驗能否被繞過或失效，

如何修復

• 處理請求之前先進行權限校驗，可通過Filter、AOP或攔截器進行實作，
• 用戶標識從快取中取出，盡量不從引數中取，

小結

越權也可以理解為失效的訪問控制，細化權限是安全體系中非常重要的一環，由于缺乏自動化檢測，以及應用程式開發人員缺乏有效的功能測驗，因而訪問控制缺陷很常見，上面的的“橫向越權”與“縱向越權”反映了越權漏洞挖掘的基本思路，而常見的訪問控制脆弱點不只是示例中介紹的用戶的增、刪、改、查介面，還包括CORS配置錯誤允許未授權的API訪問，通過修改URL、內部應用程式狀態或HTML頁面繞過訪問控制檢查，權限框架缺陷（如Apache Shiro身份驗證繞過漏洞CVE-2020-11989）等場景，在進行專項的代碼審計時，可重點關注“處理用戶操作請求時”是否對當前登錄用戶的權限進行校驗，進而確定是否存在越權漏洞

2.圖形驗證碼漏洞

漏洞成因

• 當驗證碼圖片的長寬由前端引數控制，并且后端沒有進行校驗時，攻擊者可以并發生成超大的圖片來進行DDOS攻擊，
• 當驗證碼認證了一次后，無論成功還是失敗，沒有及時清空，就可以被重復使用，導致爆破攻擊，
• 簡單的圖片驗證碼可被OCR識別，導致爆破攻擊，
• 在后端邏輯校驗程序中并未對前端傳遞驗證碼引數為null進行相關的邏輯判斷，直接洗掉驗證碼引數或置空值即可繞過，

審計策略

在登陸，重要資料的增刪改功能處一般會添加圖形驗證碼功能，可以通關關鍵字搜索：captcha、checkCode等等，
重點審計驗證碼生成邏輯，以及驗證碼的判斷校驗邏輯、順序，

如何修復

圖形驗證碼由后端控制大小；驗證一次后無論是否成功都立即清空快取；生成復雜的圖形驗證碼，降低遭到機器識別的風險；對驗證碼引數是否為空進行判斷，

3.短信服務漏洞

漏洞成因

• 如果應用程式對短信介面沒有發送頻率限制、或校驗邏輯有誤，則會導致短信炸彈漏洞，
• 如果對手機號進行校驗或格式化處理邏輯有誤，可導致攻擊者通過使用空格、分隔符、手機區號、字母等方式繞過對手機號的限制，在進行快取計數時進行繞過，
• 如果短信內容的提示有部分通過引數內容獲取，則可能導致攻擊者篡改訊息內容，對部分用戶進行定點釣魚攻擊、或垃圾短信等，

審計策略

重點審計發送短信驗證碼功能的業務邏輯，一般通過關鍵字sms進行搜索，審計業務邏輯、快取次數邏輯、非空判斷邏輯、短信內容邏輯等等，

如何修復

針對手機號的格式化以及號碼快取的業務邏輯設計一定要正確，對短信發送介面及驗證介面的業務順序要正確，

4.Zip檔案提取

漏洞成因

在業務中可能存在上傳壓縮檔案并提取的功能，利用此類功能可能存在如下安全問題：

• 如果提取出的檔案標準路徑落在解壓的目標目錄之外，攻擊者可以利用此功能進行任意檔案寫入，
• 提取出的檔案消耗過多的系統資源，zip演算法的本性就可能會導致zip炸彈（zip bomb）的出現，
  由于極高的壓縮率，即使在解壓小檔案時，比如ZIP、GIF，以及gzip編碼的HTTP內容，也
  可能會導致過度的資源消耗，

審計策略

審計重點主要關注應用是否存在ZIP解壓縮功能：

FileInputStream
ZipInputStream
getSize()
ZipEntry

如果出現getSize基本上就需要特別注意了，

如何修復

針對ZIP解壓縮功能，應該在解壓每個條目之前對其檔案名進行校驗，如果校驗不通過，就終止整個解壓程序，或對其進行忽略，
除了校驗檔案名，還應該對每個檔案大小進行限制，過大的單個檔案應該不予處理，或拋出例外，
最后對檔案總個數也應該有所限制，避免過多的檔案數目導致占用系統資源，

5.自動系結漏洞

漏洞成因

攻擊者可能將非預期的HTTP請求引數系結到一個物件上，使用這種方法來創建、修改、更新開發人員或者業務本身從未打算變更的引數，而這些新引數反過來又會影響程式代碼中不需要的新變數或物件，進而觸發一些業務邏輯漏洞，

審計策略

重點審計應用程式接參時是否使用自動系結注入完整物件，而物件是否又對應了資料層的物體類，在更新資料時是否能夠通過添加引數的方式更新非預期的屬性值；或這些引數能否影響后續業務邏輯，

如何修復

取原始資料由DAO層取；存放于session中的物件，如用戶等，在更新資訊時注意敏感欄位；使用自動系結以物體類來接參時，確保類屬性與實際引數能夠一一對應，

6.其他業務邏輯漏洞

漏洞成因

在代碼中可能存在各種業務邏輯類的漏洞，要具體看開發人員實作的代碼邏輯，在實作有誤的情況下，如校驗不完全、校驗順序錯誤、校驗邏輯設計錯誤等，將會產生各種業務邏輯漏洞，

審計策略

最常見的就是任意密碼重置、驗證碼繞過等等，下面簡單列舉了一些，

1. 用戶登陸、用戶注冊、找回密碼等功能中密碼資訊未采用加密演算法，
2. 用戶登陸、用戶注冊、找回密碼等功能中`未采用驗證碼`或`驗證碼未做安全重繪`(未重繪Session中驗證碼的值)導致的撞庫、密碼爆破漏洞，
3. 找回密碼邏輯問題(如:可直接跳過驗證邏輯直接發包修改)，
4. 手機、郵箱驗證、找回密碼等涉及到動態驗證碼`未限制驗證碼失敗次數`、`驗證碼有效期`、`驗證碼長度過短`導致的驗證碼爆破問題，
5. 充值、付款等功能呼叫了第三方支付系統未正確校驗介面(與第三方的互動、與客戶的互動，主要查看邏輯問題)，
6. 后端采用了`ORM框架`更新操作時因處理不當導致可以更新用戶表任意欄位(如:用戶注冊、用戶個人資料修改時可以`直接創建管理員賬號`或其他越權修改操作)，
7. 后端采用了`ORM框架`查詢資料時因處理不當導致可以接收任何引數導致的越權查詢、敏感資訊查詢等安全問題，
8. 用戶中心轉賬、修改個人資料、密碼、退出登陸等功能未采用驗證碼或`Token機制`導致存在`CSRF漏洞`，
9. 后端服務過于信任前端，重要的引數和業務邏輯只做了前端驗證(如:檔案上傳功能的檔案型別只在JS中驗證、后端不從Session中獲取用戶ID、用戶名而是直接接收客戶端請求的引數導致的`越權問題`)，
10. 用戶身份資訊認證邏輯問題(如:后臺系統自動登陸時直接讀取Cookie中的用戶名、用戶權限不做驗證)，
11. 重要介面采用`ID自增、ID可預測并且云端未驗證引數有效性`導致的越權訪問、資訊泄漏問題(如:任意用戶訂單越權訪問)，
12. `條件競爭問題`，某些關鍵業務(如:用戶轉賬)不支持并發、分布式部署時不支持鎖的操作等，
13. 重要介面`未限制請求頻率`，導致短信、郵件、電話、私信等資訊轟炸，
14. 敏感資訊未保護，如`Cookie中直接存盤用戶密碼等重要資訊`，跟蹤cookie中的變數最終到了哪，
15. 弱加密演算法、弱密鑰，如勿把Base64當成資料加密方式、重要演算法密鑰采用弱口令如`123456`，
16. 后端無例外處理機制、未自定義50X錯誤頁面,服務器例外導致敏感資訊泄漏(如:資料庫資訊、網站絕對路徑等)，
17. 使用`DWR框架`開發時前后端不分漏洞(如:DWR直接呼叫資料庫資訊把用戶登陸邏輯直接放到了前端來做)，

如何修復

在業務邏輯實作時詳細設計，代碼實作時注意一些常見的坑，避免出現以上提到的漏洞，

其他漏洞

1.硬編碼

漏洞成因

如果將敏感資訊（包括口令和加密密鑰）硬編碼在程式中，可能會將敏感資訊暴露給攻擊者，任何能夠訪問到class檔案的人都可以反編譯class檔案并發現這些敏感資訊，因此，不能將資訊硬編碼在程式中，

審計策略

審計源代碼中是否有硬編碼敏感資訊，

password
pass
jdbc
auth

如何修復

動態獲取敏感資訊，通過組態檔、讀取資料庫或其他手段，

2. 臨時檔案洗掉

漏洞成因

開發人員會在全域可寫的目錄中創建臨時檔案，這類目錄中的檔案可能會被定期清理，然而，如果檔案未被安全地創建或者用完后還是可訪問的，攻擊者便可以利用共享目錄中的檔案操作獲取本地檔案系統訪問權限，

審計策略

重點檔案應用程式創建新檔案時是否為臨時檔案，在使用后是否對臨時進行及時的洗掉，
可以搜索關鍵字File、FileOutputStream、tempFile、FileUtils進行查找，

如何修復

可以使用NIO中的createTempFile() 方法創建臨時檔案，這種方法無論是否有例外，都會自動關閉檔案，使用DELETE_ON_CLOSE選項，在檔案關閉時自動洗掉，
或在業務邏輯處理完成后顯式地進行洗掉，但要注意條件競爭問題，

3.不安全的反射

漏洞成因

開發人員如果提供了介面，可以由訪問人員為應用程式提供確定實體化哪個類或呼叫哪個方法的引數值，那么就有可能創建一個貫穿于整個應用程式的控制流路徑，而該路徑并非是應用程式開發者最初設計的，

而攻擊者可以利用這樣的介面呼叫非預期的任意方法執行檔案寫入、命令執行或者其他的惡意操作，

審計策略

查看開發人員是否對反射呼叫方法、反射創建類實體進行了封裝，并是否在對外的介面中進行了相關的呼叫，

Class.forName
Method.invoke
newInstance
Worker/Invoker

如何修復

避免對外開放具有相關功能的介面，或在呼叫前進行嚴格的審查，

4. 使用了不安全的組件

漏洞成因

開發人員在開發應用程式時可能會參考第三方的組件，這些組件可能被報出過安全漏洞，但是使用者由于種種原因沒有及時升級，因此可能導致存在歷史遺留的問題，

組件例如 fastjson、jackson、xstream，框架例如 struts2、spring 等等，都要注意使用的版本問題，

審計策略

關注 maven 和 gradle 等包管理軟體處理的應用程式依賴，關注開發人員所使用的應用程式版本，查看是否具有存在漏洞的版本，并查看其具體呼叫位置，看是否能夠組合成相關漏洞，

必要時可借助 SCA 審查工具來實作，

如何修復

確保應用程式使用較新的、或安裝了安全補丁的組件，

本文來自博客園，作者：gk0d，轉載請注明原文鏈接：https://www.cnblogs.com/gk0d/p/16816174.html

標籤：其他

上一篇：[征途外掛制作記五]

下一篇：RIP路由欺騙攻擊與防御策略