作者:maoge@云影實驗室
JAVA安全編碼會是一個系列的文章。此文章為該系列的第一篇。
1.框架介紹
目前hibernate和mybatis為java項目廣泛采用的兩個框架。由于hibernate使用方便,以前的項目采用hibernate非常的廣泛,但是后面由于hibernate的侵入式特性,后面慢慢被mybatis所取代 。下面我們會以springboot為基礎,分別搭建hibernate和mybatis的漏洞環(huán)境。
2.配置說明
Springboot采用2.3.1.RELEASE,MySQL版本為5.7.20。數(shù)據(jù)庫有一張表user_tbl。數(shù)據(jù)如下:
3.Hibernate
Hibernate 是一個開放源代碼的對象關系映射框架,它對 JDBC 進行了非常輕量級的對象封裝,是一個全自動的 ORM 框架。Hibernate 自動生成 SQL 語句,自動執(zhí)行。
3.1環(huán)境搭建
結(jié)構如下,ctl為控制層,service為服務層,dao為持久層。為了方便沒有按照標準的接口實現(xiàn),我們只關注漏洞的部分。
Beans下User.java對用為user_tbl表結(jié)構。
我們使用/inject 接口,p為接受外部的參數(shù),來查詢User的列表,使用fastjson來格化式輸出。
我們回到dao層。
3.1.1 SQL注入
SQL注入我們使用字符串拼接方式:
訪問http://localhost:8080/inject?p=m 直接用sqlmap跑一下:
很容易就注入出數(shù)據(jù)來了。
3.1.2 Hql注入
HQL(Hibernate Query Language)是hibernate專門用于查詢數(shù)據(jù)的語句,有別于SQL,HQL 更接近于面向?qū)ο蟮乃季S方式。表名就是對應我們上面的entity配置的。Hql注入利用難度比sql注入利用大,比如一般程序員不會對系統(tǒng)表進行映射,那么通過系統(tǒng)表獲取屬性的幾乎不可能的,同時由于hql對于復雜的語句支持比較差,對攻擊者來說需要花費更多時間去構造可用的payload,更多詳細的語法可以參考https://docs.huihoo.com/hibernate/reference-v3_zh-cn/queryhql.html
3.1.3 預編譯
我們使用setParameter的方式,也就是我們熟知的預編譯的方式。Query query = (Query) this.entityManager.createQuery(“from User u where u.userName like :userName “,User.class);query.setParameter(“userName”,”%”+username+”%”);訪問http://localhost:8080/inject?p=m 后得到正常結(jié)果
執(zhí)行注入語句http://localhost:8080/inject?p=m’ or ‘1’ like ‘1 返回為空。
我們來看看setParameter的方式到底對我們的sql語句做了什么。我們將斷點打至Loader.class的bindPreparedStatement,這樣我們可以完整的sql語句。發(fā)現(xiàn)通過預編譯后,sql變?yōu)榱藄elect user0.id as id1_0, user0.password as password2_0, user0.username as username3_0 from usertbl user0 where user0_.username like ‘%’’ or ‘’1’’ like ‘’1%’,然后交給hikari處理。發(fā)現(xiàn)變成了將我們的單引號變成了兩個單引號,也就是說把里面的變?yōu)樽址?/p>
將斷點斷至mysql-connector-java(也就是我們熟知的JDBC驅(qū)動包)的ClientPreparedQueryBindings.setString.這里就是參數(shù)設置的地方。
看一下算法:
public void setString(int parameterIndex, String x) {
if (x == null) {
setNull(parameterIndex);
} else {
int stringLength = x.length();
if (this.session.getServerSession().isNoBackslashEscapesSet()) {
// Scan for any nasty chars
boolean needsHexEscape = isEscapeNeededForString(x, stringLength);
if (!needsHexEscape) {
StringBuilder quotedString = new StringBuilder(x.length() + 2);
quotedString.Append(''');
quotedString.append(x);
quotedString.append(''');
byte[] parameterAsBytes = this.isLoadDataQuery ? StringUtils.getBytes(quotedString.toString())
: StringUtils.getBytes(quotedString.toString(), this.charEncoding);
setValue(parameterIndex, parameterAsBytes);
} else {
byte[] parameterAsBytes = this.isLoadDataQuery ? StringUtils.getBytes(x) : StringUtils.getBytes(x, this.charEncoding);
setBytes(parameterIndex, parameterAsBytes);
}
return;
}
String parameterAsString = x;
boolean needsQuoted = true;
if (this.isLoadDataQuery || isEscapeNeededForString(x, stringLength)) {
needsQuoted = false; // saves an allocation later
StringBuilder buf = new StringBuilder((int) (x.length() * 1.1));
buf.append(''');
//
// Note: buf.append(char) is _faster_ than appending in blocks, because the block append requires a System.arraycopy().... go figure...
//
for (int i = 0; i < stringLength; ++i) {
char c = x.charAt(i);
switch (c) {
case 0: /* Must be escaped for 'mysql' */
buf.append('\');
buf.append('0');
break;
case 'n': /* Must be escaped for logs */
buf.append('\');
buf.append('n');
break;
case 'r':
buf.append('\');
buf.append('r');
break;
case '\':
buf.append('\');
buf.append('\');
break;
case ''':
buf.append('\');
buf.append(''');
break;
case '"': /* Better safe than sorry */
if (this.session.getServerSession().useAnsiQuotedIdentifiers()) {
buf.append('\');
}
buf.append('"');
break;
case '32': /* This gives problems on Win32 */
buf.append('\');
buf.append('Z');
break;
case '\u00a5':
case '\u20a9':
// escape characters interpreted as backslash by mysql
if (this.charsetEncoder != null) {
CharBuffer cbuf = CharBuffer.allocate(1);
ByteBuffer bbuf = ByteBuffer.allocate(1);
cbuf.put(c);
cbuf.position(0);
this.charsetEncoder.encode(cbuf, bbuf, true);
if (bbuf.get(0) == '\') {
buf.append('\');
}
}
buf.append(c);
break;
default:
buf.append(c);
}
}
buf.append(''');
parameterAsString = buf.toString();
}
byte[] parameterAsBytes = this.isLoadDataQuery ? StringUtils.getBytes(parameterAsString)
: (needsQuoted ? StringUtils.getBytesWrapped(parameterAsString, ''', ''', this.charEncoding)
: StringUtils.getBytes(parameterAsString, this.charEncoding));
setValue(parameterIndex, parameterAsBytes, MysqlType.VARCHAR);
}
}
可以看到mysql-connector-java主要是將將我們’轉(zhuǎn)為了’’,對于轉(zhuǎn)義的會變?yōu)?比如對于這種sql:SELECT user0.id AS id1_0,user0. PASSWORD AS password2_0,user0.username AS username3_0FROM usertbl user0WHERE user0.username LIKE ‘%’ or username = 0x6d #%’
也會變?yōu)椋?br />SELECT user0.id AS id10,user0. PASSWORD AS password2_0,user0.username AS username3_0 FROM usertbl user0WHERE user0_.username LIKE ‘%‘’ or username = 0x6d #%’
有人會說那我們使用select from user_tbl where id = 1 and user() = 0x726f6f74406c6f63616c686f7374 這種類似的語句,全程沒有jdbc里面的危險字符是不是就可以繞過了?mysql-connector-java里面有個非常巧妙的點是,他會根據(jù)你傳入的類型判斷。比如傳入的為int類型。就會走setInt。傳入的為string就會走setString。所以這段語句還是會被select from user_tbl where id = 1 ‘and user() = 0x726f6f74406c6f63616c686f7374’我們看到sql預編譯的算法也是非常簡單。
4.Mybatis
MyBatis是一流的持久性框架,支持自定義SQL,存儲過程和高級映射。MyBatis可以使用簡單的XML或注釋進行配置。現(xiàn)在目前國內(nèi)大部分公司都是采用的MyBatis框架。
4.1環(huán)境搭建:
下面為我們項目目錄結(jié)構:
4.2使用#{}的方式
#{}也就是我們熟知的預編譯方式。
訪問http://localhost:8080/getList?p=m 后正常的返回:
使用http://localhost:8080/getList?p=m‘ or ‘1’ like ‘1結(jié)果返回為空。不存在注入。我們將斷點斷在PreparedStatementLogger的invoke方法上面,其實這里就是一個代理方法。這里我們看到完整的sql語句。
同樣我們將斷點斷在:ClientPreparedQueryBindings.setString同樣會進去
Hibernate和Mybatis的預編譯機制是一樣的。
4.3使用${}的方式
${}的方式也就是mybatis的字符串連接方式。
使用sqlmap很容易就能跑出數(shù)據(jù)
4.4 關于orderBy
之前有聽人說order by后面的語句是不會參與預編譯?這句話是錯誤的。Order by也是會參與預編譯的。從我們上面的jdbc的setString算法可以看到,是因為setString會在參數(shù)的前后加上’’,變成字符串。導致order by失去了原本的意義。只能說是預編譯方式的order by不適用而已。所以對于這種order by的防御的話建議是直接寫死在代碼里面。對于order by方式的注入我們可以通過返回數(shù)據(jù)的順序的不同來獲取數(shù)據(jù)。
關于useServerPrepStmts其實在只有jdbc在開啟了useServerPrepStmts=true的情況下才算是真正的預編譯。但是如果是字符串的拼接方式,預編譯是沒有效果的。從mysql的查詢?nèi)罩揪涂梢蚤_看到。可以看到Prepare的語句。一樣是存在sql注入的。
我們使用占位符的方式:
上面的語句就不存在sql注入了。我想這就是jdbc默認為啥不開啟useServerPrepStmts=true的原因吧。
4.5 關于慢查詢
比如說我們我們有如下語句select from user_tbl like ‘%’+subsql+’%’,如果前端提交%或者%25(不同控制器處理不同)時候會出現(xiàn)select from user_tbl like ‘%%%’ 會查詢所有字段,導致慢查詢。我們可以在上面看到jdbc并不會處理%的情況,在做模糊查詢時,在沒有必要使用%的情況下,可以建議也屏蔽掉此符號。
總結(jié):
在能使用預編譯的情況下我們應該要使用預編譯。在不能使用預編譯的情況下,可以對特定類型做規(guī)范,比如傳數(shù)字的需要規(guī)范為Integer,Long等。這樣會在進入數(shù)據(jù)庫前會提前拋出異常。或者使用Spring的AOP機制,添加一個前置的fitler,對有害的字符清洗或者過濾。但是這樣有點籠統(tǒng),會對全局參數(shù)進行清洗。還有一種比較好的方式是,通過注解的方式,這樣會比較方便,可復用性也很好。對不能進行預編譯的參數(shù)加上過濾有害字符的注解。我們就不在這里做代碼的實現(xiàn),網(wǎng)上有很多可以參考的教程。可以使用Apache Jakarta Commons提供的很多方便的方法來過濾有害字符。
本文涉及的源碼均在https://github.com/langligelang/dragonfly
歡迎登錄安全客 -有思想的安全新媒體www.anquanke.com/加入交流群113129131 獲取更多最新資訊
原文鏈接:https://www.anquanke.com/post/id/212897