Golang

2589 readers
1 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

founded 2 years ago
MODERATORS
26
 
 

I'm dispensing with the thorns for this post.

BLUF

I know of no static code analysis tools which audit for malicious code. I'm aware of gosec, but it seems focused on preventing footguns rather than searching for malicious code injection. What I need is a tool which is focused on the security of a project's dependencies, and specifically looking for obfuscated, intentionally malicious code.

The problem I want to address is: as a developer, I want to ensure any dependencies I import are free of malicious, potentially obfuscated, supply chain attacks.

Background

I am not a security expert, but I do have both substantial development experience and time to work on a project; I'm looking for either someone to say, "this tool already exists, here's the URL", or someone who's a security expert who has time and interest to collaborate on development of such a tool. "Collaborate" could be as limited as exchanging emails in a mailing list with guidance for the sorts of things to look for.

As a developer, I seem to have three choices regarding supply chain attacks: ignore them; manually audit every dependency I use, re-auditing every new version bump of each dependency, recursively; or never depend on any other libraries. The last is fine for tightly constrained projects, but is restricting. The first is irresponsible, and since most FOSS projects are scratching an itch, scary. The middle option drastically increases the amount of effort needed to develop, and especially maintain, a project, since a project might need updating simply because of a dependency version bump.

As a lay security person, I imagine that it's not possible to build a tool which provides automatic assurance of security, so I suspect the best that can be done is identifying potentially suspicious code. This isolation (identification?) of code blocks would reduce the amount of effort required to audit dependencies: it wouldn't provide a guarantee, but would be better than cold-auditing every dependency. If I had to do this with my current knowledge, I'd start by reporting out any code block that uses os, net, or io. That's my imagination of a bare-minimum, but I suspect a tool could eliminate (mark as clean) some uses, and also identify particularly suspicious patterns -- for example, calling Exec or mucking around with hard-coded arrays of bytes, or hard-coded or calculating network addresses (k := 0xC0A800 ; xyz := strings.ReplaceAll(fmt.Sprintf("%d %d 0 1", k >> 16, (k&0xffff)>>8), " ", ".") + ":80"; net.Dial("tcp", xyz) or some such. Although the "Dial" alone might be sufficient as a flag.).

I keep waiting to see a tool like this pop up, and it keeps not popping up, so I'm seeking collaboration to scratch the itch. The threat of supply chain attacks in dependency libraries has really put a damper on my enthusiasm for working on projects: I'd rather not spend all of my time auditing every version of every dependency in the entire dependency tree -- and neither am I competent to. I want a tool which makes it easier to sincerely claim: "I'm pretty sure, to the best of my ability, that I'm not shipping hostile code to my users."

27
28
29
30
31
32
33
34
35
36
37
38
39
 
 

Marshaling the field is fine, so using the tag json:"-" won't work. I could use the UnmarshalJSON method on the struct, but I have no idea how to implement it.

I'd rather not make a duplicate of the struct with that field removed, as it causes quite a bit of code duplication, and it's pretty chaotic.

40
41
42
 
 

Hi, what's the best way for testing a gin route?

I currently have one function where the routes are defined. Here it is:

package router

import (
	"github.com/gin-gonic/gin"
	"github.com/gragorther/epigo/handlers"
	"github.com/gragorther/epigo/middlewares"
)

func Setup(userUserStore handlers.UserUserStore, groupGroupStore handlers.GroupGroupStore, groupAuthStore handlers.GroupAuthStore, messageAuthStore handlers.MessageAuthStore, messageMessageStore handlers.MessageMessageStore, middlewareUserStore middlewares.UserStore) *gin.Engine {
	r := gin.Default()
	r.Use(middlewares.ErrorHandler())

	userHandler := handlers.NewUserHandler(userUserStore)
	authHandler := middlewares.NewAuthMiddleware(middlewareUserStore)
	groupHandler := handlers.NewGroupHandler(groupGroupStore, groupAuthStore)
	messageHandler := handlers.NewMessageHandler(messageMessageStore, messageAuthStore)

	// user stuff
	r.POST("/user/register", userHandler.RegisterUser)
	r.POST("/user/login", userHandler.LoginUser)
	r.GET("/user/profile", authHandler.CheckAuth, userHandler.GetUserProfile)
	r.PUT("/user/setEmailInterval", authHandler.CheckAuth, userHandler.SetEmailInterval)

	// groups
	r.DELETE("/user/groups/delete/:id", authHandler.CheckAuth, groupHandler.DeleteGroup)
	r.POST("/user/groups/add", authHandler.CheckAuth, groupHandler.AddGroup)
	r.GET("/user/groups", authHandler.CheckAuth, groupHandler.ListGroups) // list groups
	r.PATCH("/user/groups/edit/:id", authHandler.CheckAuth, groupHandler.EditGroup)

	// lastMessages
	r.POST("/user/lastMessages/add", authHandler.CheckAuth, messageHandler.AddLastMessage)
	r.GET("/user/lastMessages", authHandler.CheckAuth, messageHandler.ListLastMessages)
	r.PATCH("/user/lastMessages/edit/:id", authHandler.CheckAuth, messageHandler.EditLastMessage)
	r.DELETE("/user/lastMessages/delete/:id", authHandler.CheckAuth, messageHandler.DeleteLastMessage)
	return r
}

so, my question is, how can I test just one route? should I run this function in every test and send a request to a route with httptest? Or should I set up my handlers like it's described at https://gin-gonic.com/en/docs/testing/

(like this)

func postUser(router *gin.Engine) *gin.Engine {
  router.POST("/user/add", func(c *gin.Context) {
    var user User
    c.BindJSON(&user)
    c.JSON(200, user)
  })
  return router
}

let me know if you have any other questions about my code.

It's available on github: https://github.com/gragorther/epigo

43
44
45
46
47
48
49
50
view more: ‹ prev next ›