golang 的一些安全问题

寒假主要是先出完了之前心心念念的typescript 题目，之后主要是抽点时间学golang.同学推荐的仓库讲的还是很不错的

从简单的开发与学习过程中可以感觉到golang的确非常安全，很多问题由于作为强类型的静态语言，从编译过程就能防止不安全的操作。因此大部分漏洞产生还是归结于依赖库（通常已经发展为CVE或者issue）以及开发者自身的操作漏洞。这里就作为小结,简单谈一谈

interger overflow/truncation

golang 存在非常经典的整数反转/溢出问题

对无符号数的反转

func main() {
    var a uint32 = 2147483648
    var b uint32 = 2147483648
    var sum  =  a + b
    fmt.Println(reflect.TypeOf(sum))
    fmt.Printf("Sum is : %d",sum)
}
//uint32
//Sum is : 0

象要直接声明一个大小已经溢出的数自然不会通过编译，因此出现反转的话，主要是在变量的相加这样的计算才会会导致标志CF位反转

有符号数的溢出

var a int8 = 127
var b int8 = 1
var sum int8 =  a + b
fmt.Println(reflect.TypeOf(sum))
fmt.Printf("Sum is : %d",sum)
//int8
//-128

具体的值可以看到math包中的常量定义。

在类型转换中,也会出现较大整型向较小整型转换的截断问题

var a int16 = 256
var b  = int8(a)
fmt.Println(b)
// 0 
// high-order byte is truncated

kubectlstrconv.Atoi

v , _ := strconv.Atoi("4294967377")
s  := int32(v)
fmt.Println(s)
// 81

ParseInt ,ParseUInt

CTF中出现整数溢出的scenario 一般都是 xx shop之类的。通过重复的加数进行溢出然后鉴权。

pseudo-rand

golang 的math/rand 包中，我们可以看到随机数生成的函数形式

跟进一下函数与结构体

var globalRand = New(&lockedSource{src: NewSource(1).(*rngSource)})

......

func NewSource(seed int64) Source {
    var rng rngSource
    rng.Seed(seed)
    return &rng
}

rand.Seed()

这种问题可能会出现在开发者直接用rand生成的字符串作为密钥的场景，比如gin的cookie的key.从而导致本地复现，直接鉴权。

go net/http

net/http < 1.11 CRLF

http.NewRequest()

\r\n

WMCTF中的gogogo出现过这一漏洞，利用自然是通过CRLF发送POST请求进行绕过与上传。

weird stuff

在之前的justCTF中，出现了一道go题。题目原本的漏洞是由出题人发现的一个issuehttps://github.com/golang/go/issues/40940 加上其对fileServer一些代码的魔改组合的。

简单陈述下的话，题目提供了一个go http起的FileServer

http.Handle("/", http.FileServer(http.Dir("/tmp")))

/flag/flag

出题人的意图是利用其挖掘到的这个漏洞，造成错误的文件读取范围。通过访问其他文件越界读到flag.(http的Fileserver在我们访问时，会先根据我们访问的url进行一系列处理，杜绝路径穿越的url,之后进行文件读取返回给用户)

curl --path-as-is -X CONNECT http://gofs.web.jctf.pro/../flag

简单说就是用CONNECT请求+路径穿越的url读取到了文件。我们看看源码是怎么处理的

如果是CONNECT方式请求，就不会处理url中的特殊字符。导致直接读取flag.其他的请求方法都会在

cleanPath

中被处理url

算是一个很有意思的问题。不过golang1.16似乎已经处理了。但是包括我在内的大部分应该还是使用的go1.15及以下版本，所以还是值得注意的

feature of slice

之前在做buu上的roarCTF时遇到一道go题，其中一个利用点来自Confidence CTF,其中用到了golang slice的一个feature

a := make([]uint64, 0)
a = append(a, 1)
a = append(a, 2)
a = append(a, 3)
b := append(a, 4)
c := append(a, 5)

fmt.Println(a)
fmt.Println(b)
fmt.Println(c)

//result:
//[1 2 3]
//[1 2 3 5]
//[1 2 3 5]

[1,2,3,4][1,2,3,5]

type slice struct {
    array unsafe.Pointer // ptr
    len   int
    cap   int
}

append(3)2*2=4b := append(a, 4)c := append(a, 5)

那一道题目就是利用这点，可以通过先beg三次构造出len=3,cap=4的切片，通过题目中一个append超大随机数的机会，在下一次beg时达成元素覆盖。

这个可以算是slice的feature,还是很有意思的。

reDOS

原本是以为golang不存在reDOS的问题的。当初阅读lmt-swallow的文章时也看到他提到golang有linear time matching。不过后来发现还是有途径的。

Blind regex injection

^(?=(PAYLOAD))((.*)*)*salt$

{n}(.?){1000}

reDOS其实一直是一个很有意思的点,除了喜闻乐见的nodejs,前端中xss也可以导致这个问题，从而xsleak ,ruby中也有类似问题。当然，如果是从reDOS引申到正则盲注的话，sql注入中倒也有类似的情况。总之就是利用差异性进行数据提取。可惜因为太容易坏环境了，所以很难出道题到比赛中 :(

SSTI

最后一个就简单提一下ssti.要说golang这种静态编译还会出ssti还是挺难的( 除非源码中用sprintf 或者说拼接来构建template的参数

var tmpl = fmt.Sprintf(`<h2>No search results for %s</h2>`, xxx)

{{}}{{.xxx}}.

假如我们传入的参数是可解析的,就有可能泄露template在执行过程中引入的对象内容(执行的本质就是合并替换)

如果传入的struct属性含有指针的话(非常常见，因为用指针可以节省很很多空间),我们ssti的回显就只是一个地址。需要我们手动去访问属性才会解引

Summary && Reference

简单的梳理下自己见过的golang安全问题(CTF-based web go)。其实像之前dasCTF中也有golang的题目，用gob序列化存内容到cookie，不过利用点与go的关系为0，所以不谈。

自己golang的开发还有很多值得去学的，这门语言确实有其优越之处以及一些可能存在并被挖掘的安全问题

https://github.com/tsg-ut/tsgctf2020
https://annevi.cn/2020/08/14/wmctf2020-gogogo-writeup/
https://github.com/golang/go/issues/30794
https://github.com/golang/go/issues/40940
https://github.com/mwarzynski/confidence2019_teaser_lottery