golang的一些安全问题
寒假主要是先出完了之前心心念念的typescript 题目，之后主要是抽点时间学golang.同学推荐的仓库讲的还是很不错的
https://github.com/unknwon/the-way-to-go_ZH_CN
从简单的开发与学习过程中可以感觉到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我们可以看到整型安全的检查也出现在了gosec中，一个比较经典的例子就是：kubectl命令行中出现了一个strconv.Atoi导致的截断问题。当我们传入port参数的对应字符串后,容器启动的端口这一参数会将经Atoi处理后的字符串进行int32的类型转换。由于64位系统的int是int64类型。转int32的话会出现明显截断
可以简化成以下代码：
v , _ := strconv.Atoi("4294967377")
s := int32(v)
fmt.Println(s)
// 81这样就有可能导致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
}可以看到,这些随机数函数的seed默认为1.也就是说如果不使用rand.Seed()确认种子的话，生成的只是所谓的伪随机数。
这种问题可能会出现在开发者直接用rand生成的字符串作为密钥的场景，比如gin的cookie的key.从而导致本地复现，直接鉴权。
go net/http
net/http < 1.11 CRLF
低版本的http库会导致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就在其提供文件服务的文件夹下，但是，出题人加上了web服务的flag路由,从而使得我们没法通过直接访问/flag来获取文件。而是得到/flag路由的回显。
出题人的意图是利用其挖掘到的这个漏洞，造成错误的文件读取范围。通过访问其他文件越界读到flag.(http的Fileserver在我们访问时，会先根据我们访问的url进行一系列处理，杜绝路径穿越的url,之后进行文件读取返回给用户)
但是比较有意思的时，比赛中出现了一个非预期读flag的方式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]按照直觉来说，b这里应该是[1,2,3,4],但实际上却是[1,2,3,5]
这就与golang的slice也就是切片的结构相关了
type slice struct {
array unsafe.Pointer // ptr
len int
cap int
}
slice结构中的cap是按2的倍数扩容的。所以说当我们append(3)时会发生第一次扩容，此时len为3，cap为2*2=4.
执行b := append(a, 4)时，我们的4会被放在指针ptr的第四个位置。然后返回ptr len=4 cap=4给b。不过这并没有改变a的结构（slice只是指向内存的指针）之后进行c := append(a, 5)时，由于a没变，新元素只会覆盖之前b那放上的4.
那一道题目就是利用这点，可以通过先beg三次构造出len=3,cap=4的切片，通过题目中一个append超大随机数的机会，在下一次beg时达成元素覆盖。
这个可以算是slice的feature,还是很有意思的。
reDOS
原本是以为golang不存在reDOS的问题的。当初阅读lmt-swallow的文章时也看到他提到golang有linear time matching。 不过后来发现还是有途径的。
当然，reDOS主要还是在js里影响比较大，因为其事件队列阻塞对于web服务的影响是巨大的。相比之下其他的DOS影响可能就较小。用nginx做个处理基本就没有影响。不过，如果是以Blind regex injection为目的考虑reDOS的话，就另当别论了。
回到golang上。golang使用的正则引擎是re2。但是用的是无回溯机制(DFA)。
所以之前的payload如^(?=(PAYLOAD))((.*)*)*salt$就无效了
但是,通过其他方法制造延时仍然是可行的。比如re2对于{n}这样的正则，n存在有上限1000，且对于DFA状态数没有限制.我们可以通过不断重复(.?){1000}来制造足够的DFA状态进行一定程度上的延时
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)golang的template跟很多模板引擎的语法差不多，比如双花括号指定可解析的对象。.xxx表示一个对象的xxx属性。.就是当前作用域的当前对象，基本就跟handlebars里的this差不多。
假如我们传入的参数是可解析的,就有可能泄露template在执行过程中引入的对象内容(执行的本质就是合并替换)
简单的demo可以参考这里 https://blog.takemyhand.xyz/2020/05/ssti-breaking-gos-template-engine-to.html
如果传入的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
博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
