Skip to main content

Insecure object reference - Data

Need

Secure object reference and data access control

Context

  • Usage of Go 1.16 for building high-performance and scalable applications
  • Usage of gin-gonic/gin for building web applications in Go

Description

Non compliant code

package main

import (
"github.com/gin-gonic/gin"
)

type Store struct {
ID string
Members []string
}

var stores = []Store{
{"store1", []string{"member1", "member2", "member3"}},
{"store2", []string{"member4", "member5", "member6"}},
}

func main() {
r := gin.Default()

r.GET("/store/:id", func(c *gin.Context) {
id := c.Param("id")
for _, store := range stores {
if store.ID == id {
c.JSON(200, store)
return
}
}
c.JSON(404, gin.H{"message": "store not found"})
})

r.Run()
}

In the code above, an array of stores is defined, each with an ID and a list of Members. The Gin framework is used to set up a simple HTTP server with a single route /store/:id which returns the details of a store when given its ID as a parameter.

The vulnerability lies in the fact that there is no validation of the user's permissions when accessing the details of a store. By simply knowing the ID of a store, anyone can access its details, including the list of members, by making a GET request to /store/:id. This is an example of an Insecure Direct Object Reference (IDOR) vulnerability, as the application is directly using user-supplied input (id) to fetch an object (store) without any authorization checks.

This vulnerability could allow an attacker to access sensitive information about other stores and their members that they should not have access to, potentially leading to unauthorized actions such as modifying members or adding members from other stores.

Steps

  • Implement proper authorization and authentication mechanisms to ensure that only authorized users can access the store information.
  • Validate the user's permissions before allowing access to store information.
  • Use a session management system to track and validate user sessions.
  • Implement access control checks to ensure that a user can only access the stores they are assigned to.
  • Consider using role-based access control (RBAC) to manage user permissions.
  • Regularly review and update the access control mechanisms to address any potential vulnerabilities.

Compliant code

package main

import (
"github.com/gin-gonic/gin"
)

type Store struct {
ID string
Members []string
}

type User struct {
ID string
Stores []string
}

var stores = []Store{
{"store1", []string{"member1", "member2", "member3"}},
{"store2", []string{"member4", "member5", "member6"}},
}

var users = []User{
{"user1", []string{"store1"}},
{"user2", []string{"store2"}},
}

func main() {
r := gin.Default()

r.Use(AuthMiddleware())

r.GET("/store/:id", func(c *gin.Context) {
id := c.Param("id")
user := c.MustGet("user").(User)
if !user.HasAccessToStore(id) {
c.JSON(403, gin.H{"message": "access denied"})
return
}
for _, store := range stores {
if store.ID == id {
c.JSON(200, store)
return
}
}
c.JSON(404, gin.H{"message": "store not found"})
})

r.Run()
}

func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
// Here should be the logic to authenticate the user and set it in the context
// For simplicity, we are just setting a hardcoded user
c.Set("user", users[0])
c.Next()
}
}

func (u User) HasAccessToStore(storeID string) bool {
for _, store := range u.Stores {
if store == storeID {
return true
}
}
return false
}

The updated code includes an AuthMiddleware function that authenticates the user and sets it in the context. This middleware is used in the main function to ensure that all requests are authenticated.

The User struct has been added to represent a user in the system. Each user has an ID and a list of stores they have access to.

The HasAccessToStore function is a method on the User struct that checks if the user has access to a given store. This function is used in the GET handler for /store/:id to ensure that the user can only access the stores they are assigned to.

If the user tries to access a store they do not have access to, the server responds with a 403 status code and a message of "access denied". If the store does not exist, the server responds with a 404 status code and a message of "store not found".

This code ensures that only authorized users can access the store information, and that they can only access the stores they are assigned to. This fixes the insecure object reference vulnerability in the original code.

References