文章目錄

• 簡介
• 為什么會有DOS
• 不合理的資源使用
• • 請求用于矢量圖的SVG文件和字體文件
  • 字符串或二進制表示的圖片轉換
  • zip炸彈
  • billion laughs attack
  • hashMap中插入太多相同hashcode的元素
  • 正則表達式悲觀回溯
  • 序列化和序列化
  • 大量的輸出日志
  • 無限循環
  • 使用第三方jar包
  • Xpath攻擊
  • 釋放所有資源

簡介

DOS不是那個windows的前身，而是Denial of Service，有做過系統安全方面的小伙伴可能對這個再熟悉不過了，簡單點講，DOS就是服務型響應不過來，從而拒絕了正常的服務請求。

今天本文不是要講怎么發起一個DOS攻擊，而是講一下怎么在java的代碼層面盡量減少DOS的可能性。

為什么會有DOS

為什么會有DOS呢？排除惡意攻擊的情況下，DOS的原因就是資源的使用不當。一般意義上我們所說的資源有CPU周期，內存，磁盤空間，和文件描述符等。

如果這些資源受到了惡意使用，那么很有可能會影響正常的系統服務響應，從而產生DOS。

怎么在編碼層面上，解決DOS問題呢？

不合理的資源使用

如果系統有不合理的資源使用的話，就會造成資源緊缺，從而會產生問題。我們這里舉一些不合理使用資源的例子。

請求用于矢量圖的SVG文件和字體文件

SVG (全稱是 Scalable Vector Graphics) 是一個跟分辨率無關的圖形格式。因為SVG是基于XML的，并且保存著大量的復雜路徑信息，所以它的體積一般比較大。我們在使用的時候要考慮。

同時如果使用大量的字體文件也會加重系統的資源負擔。

字符串或二進制表示的圖片轉換

圖片是一個文件，文件就可以使用二進制來表示，同樣的如果我們把二進制進行base64編碼就得到了圖片的字符串表示。

如果使用過webpack進行前端項目構建的同學應該知道，對于項目中的小圖像，一般是將其編碼成為字符串直接嵌套在html中的。但是對于大圖片，還是保存的原來的格式。

如果我們在后臺對字符串或者二進制表示的圖片進行轉換的時候，可能會需要幾倍于原image大小的內存。

看一個imageToBase64的例子：

public String imageToBase64() {File f = new File("/tmp/abc.jpg");try {BufferedImage bi = ImageIO.read(f);ByteArrayOutputStream baos = new ByteArrayOutputStream();ImageIO.write(bi, "jpg", baos);byte[] bytes = baos.toByteArray();return encoder.encodeBuffer(bytes).trim();} catch (IOException e) {e.printStackTrace();}return null;}

zip炸彈

為了提升數據傳輸的效率，很多時候我們都會使用壓縮算法，比如在HTTP中。但是一個壓縮過的很小的zip文件，解壓之后可能會變得非常非常大。

這里給大家介紹一個非常有名的zip炸彈。

42.zip 是很有名的zip炸彈。它的大小只有42KB，但是解壓之后居然有4.5PB之多。

怎么做的呢？

一個zip文件中又包含了16個zip文件，每一個zip文件又包含了16個zip文件，這樣循環5次，產生了16的5次方個文件，每個文件的大小是4.3GB，最后導致你的硬盤爆炸了。

感興趣的朋友可以從http://www.unforgettable.dk/42.zip 下載，自己嘗試一下。

怎么避免zip炸彈呢？

第一種做法在解壓過程中檢測解壓過后的文件大小，如果超出一定的限制就結束解壓。

另一種做法，就是判斷壓縮文件中是否還有壓縮文件，盡量減少這種壓縮套壓縮的做法。

billion laughs attack

billion laughs attack是解析XML文件產生的DOS攻擊。

先上代碼：

<?xml version="1.0"?> <!DOCTYPE lolz [<!ENTITY lol "lol"><!ELEMENT lolz (#PCDATA)><!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"><!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"><!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"><!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"><!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"><!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"><!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"><!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"><!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

上面的代碼定義了10個entities，每個entity又包含了10個前面定義的entity，從而實現了指數級的字符串增長。最后生成了包含10億個字符串的xml文件。

一般情況下，我們會將xml放在內存中保存，這么多的字符串最后會耗盡我們的內存，最終導致DOS。

我們可以通過設置 XMLConstants.FEATURE_SECURE_PROCESSING 來防止這種攻擊。

hashMap中插入太多相同hashcode的元素

我們知道java中hashMap是用分離鏈表來處理hash沖突的，如果插入了太多相同hashcode的元素，就會導致這個hashcode對應的鏈表變得很長，從而查詢效率降低，影響程序性能。

正則表達式悲觀回溯

什么是悲觀回溯呢？

我們舉個例子，假如大家對正則表達式已經很熟悉了。

假如我們使用/^(x*)y$/ 來和字符串xxxxxxy來進行匹配。

匹配之后第一個分組（也就是括號里面的匹配值）是xxxxxx。

如果我們把正則表達式改寫為 /^(x*)xy$/ 再來和字符串xxxxxxy來進行匹配。 匹配的結果就是xxxxx。

這個過程是怎么樣的呢？

首先(x*)會盡可能的匹配更多的x，知道遇到字符y。 這時候(x*)已經匹配了6個x。

接著正則表達式繼續執行(x*)之后的xy，發現不能匹配，這時候(x*)需要從已經匹配的6個x中，吐出一個x，然后重新執行正則表達式中的xy，發現能夠匹配，正則表達式結束。

這個過程就是一個回溯的過程。

如果正則表達式寫的不好，那么就有可能會出現悲觀回溯。

還是上面的例子，但是這次我們用/^(x*)y$/ 來和字符串xxxxxx來進行匹配。

按照上面的流程，我們知道正則表達式需要進行6次回溯，最后匹配失敗。

考慮一些極端的情況，可能會導致回溯一個非常大的次數，從而導致CPU占用率飆升。

序列化和序列化

我們將java對象存進文件或者進行網絡傳輸的時候，都需要使用到序列化和反序列化。

如果我們在對一個java對象進行反序列化的時候，很可能就會加載惡意代碼。

因此我們需要在反序列化的時候進行住夠的安全控制。

大量的輸出日志

通常我們為了調試程序或者尋找問題都會輸出大量的日志，如果日志文件太大會影響到磁盤空間的使用。

同時，日志寫入操作也會對同一個硬盤上的其他寫入操作產生影響。所以日志輸出要抓住重點。

無限循環

在使用循環的時候一定要注意，不要產生無限循環的情況。

使用第三方jar包

現代的java程序都會使用第三方jar包，但是第三方jar包的安全性還是需要我們注意的。如果某些第三方jar包中包含有惡意代碼，那么會對我們的系統造成非常嚴重的影響。

Xpath攻擊

XPath 解析器是用來解析XML結構的工具，但是在使用XPath 解析器的時候，我們需要注意防止注入攻擊。

舉個例子：

<users><user><name>張三</name><username>zhangsan</username><password>123</password></user><user><name>李四</name><username>lisi</username><password>456</password></user>

如果使用xpath，我們需要這樣來驗證一個用戶是否存在：

//users/user[username/text()='lisi'and password/text()='456']

如果用戶傳入username = ‘lisi’ 和 password = ‘456’, 那么可以匹配成功，證明用戶存在。

但是如果用戶輸入類似 ’ or 1=1 or ‘’=’ 的值，我們看下xpath的解析結果：

//users/user[username/text()=''or 1=1 or ''='' and password/text()='' or 1=1 or ''='']

結果產生和SQL注入一樣的結果。

釋放所有資源

通常來說，我們在進行文件操作，鎖獲取操作的的時候會申請相應的資源，在使用完這些資源過后，千萬要記得釋放他們。

在JDK7 之后，引入了try with表達式，我們可以將要釋放的資源放入try語句內，在程序執行完畢，資源會自動釋放。

舉個例子：

public R readFileBuffered(InputStreamHandler handler) throws IOException {try (final InputStream in = Files.newInputStream(path)) {handler.handle(new BufferedInputStream(in));}}

上面的InputStream會自動釋放。

本文已收錄于 http://www.flydean.com/java-security-code-line-dos/

最通俗的解讀，最深刻的干貨，最簡潔的教程，眾多你不知道的小技巧等你來發現！

歡迎關注我的公眾號:「程序那些事」,懂技術，更懂你！

總結

以上是生活随笔為你收集整理的java安全编码指南之:拒绝Denial of Service的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。